Review how alias data-types are used

[jougs]

Currently, we have a lot of alias datatypes that make the code less readable to normal C++ programmers and only help little for NEST experts. Because the aliases are just typedefs, they do not provide any additional type safety.

The following list of aliases is defined in nest_types.h:

index -> size_t
tic_t -> longlong or long (longest integer type available)
syn_index -> unsigned char
targetindex -> unsigned short
thread -> int_t
rport -> long_t
port -> long_t
weight -> double_t
delay -> long_t 

The task is to review these types and replace them with standard types where they don't make sense.

This was known as trac90. See also #343.

[heplesser]

These type aliases are informative, but since they are just aliases of plain C++ datatypes, the compiler performs no type checking. So they can create a false sense of safety on the part of the programmer.

[heplesser]

In the Open NEST Developer VC today, we concluded that replacing the alias types with proper classes with explicit constructors would will not incur run-time penalties and increase type safety.
We will do a check to see how many changes in NEST code this would require and return to the issue in the next Developer VC.

[apeyser]

I've looked at it and thought about it:

To add type-safety without too many problems (such as handling constexpr's, explicit cast expressions, ..) would require c++11.

On the other hand, with c++ 11, we could simply require curly-braced construction/initialization {} to solve all the problems of implicit narrowing, and if we wanted further safety it would be fairly trivial to construct these classes.

So this is essentially a pre-11 problem that is not solvable without producing more problems than are solved currently. +1 to moving onto c++ 11.

[heplesser]

@apeyser Thanks for the quick check! Based on that and the arguments raised during the discussion today, I would then suggest to leave things as they are.

Would you open a new issue concerning a potential transition to C++11? The main issue here is compiler support, given that cutting-edge HPC hardware typically seems to be anything but cutting edge when it comes to compilers ...