Functions

Detailed Description

Typedef Documentation

C++ knows of ten distinct integer types that are normatively different types, even if they may sometimes coincide in width and signedness. We use `one word' abreviations for these to make the appearance of the code more readable: char, uchar, schar, short, ushort, int, uint, long, ulong and wchar_t.

This is also to avoid confusions from naming the same type differently, such as `long unsigned int' or `unsigned long'.

Warning:

char, uchar, schar are three distinct types.

wchar_t is a type of its own for C++ but a typedef for C.

If they exist, longlong and unsignedlonglong are also defined to be different types, test for their existence with the macro HAVE_LONG_LONG.

In most circumstances you should probably not use these, but use typedefs that are defined with a particular semantic instead, e.g POSIX size_t for object sizes, uintptr_t for an integer compatible with casts to void*, uintmax_t for the type of maximal width, or par::cntrl::proc_t for parXXL processes. Exceptions from this general rule are:

int as a return type of POSIX functions, error codes etc

char and wchar_t have precribed semantics, they are characters and wide characters respectively. You may use char* for strings, but also consider looking into par::sys::str. But don't use char for other purposes, in particular arithmetic on small integer types. Use int8_t or uint8_t instead.

template instatiations

In particular the later might be a bit tricky if you want to generate instatiations systematically. In such a case you should instantiate for the ten types above, and not for their sematic overloads like size_t etc.: size_t and uintptr_t might correspond to the same type and thus produce an error if you instantiate with them at different locations.

This is the type that the sizeof operator returns. It is an unsigned integer type that controls everything that the system could address with its capacities. This does not limit the size of objects that parXXL can handle, but merely poses a limit of what can be accessed simultaneously.

This is guaranteed to cast back and forth to any pointer to an object type without loss of information. It is very likely that this is the same as size_t on your system but you should not rely on that.

There is a subtle difficulty with pointers to functions. The norms (C as well as C++) explicitly don't want casts from function pointers to object pointers, in particular not to void*. This is to allow for systems to use composed objects as function pointers, e.g a usual pointer plus a segment specification. This was necessary in medivial times on 16bit architectures. Nowadays this restriction is probably mostly obsolete (but perhaps some embedded systems). In particular all computing platforms (e.g POSIX) we know of tacitely assume that both sorts of pointers have the same width.

In the current state parXXL only runs on such platforms where both widths are the same and it will not compile the file par_cpp_int.h if they are not. The reason is not very profound, we want to use uintptr_t as a generic integer type to handle par::cpp::id.