Question

What are the purpose of api specific typedefs such as GLsizei GLint GLvoid?

I see this everywhere in c and c++ code. Basic types are often typdefed with the libraries prefix/suffix. What’s the reasoning behind this? Is this good practice? Should my programs be doing something similar themselves?

At first glance it seems to make the code a little bit less readable. You have to take an instant to translate GLint into int in your head, and that’s an easy example.

Something like UINT makes more since to me, at least this is shortening unsigned int into four lettters.

Answer 1

It’s not about shortening the names, but about portability. Different platforms will need to typedef those things differently.

In Std-C, long may be 32 or 64 bits, depending on your compiler/target, so it can’t be safely assumed to be a certain size. A library author will thus typedef his own type, guaranteeing a certain size, with the knowledge of the target platform.

E.g.

#ifdef _WIN32
typedef __int64 INT64;  // long will not be 64 bit on Windows/VC.
#elif __GNU_C__
typedef long INT64;  // gcc typically uses 64 bit longs.
#elif // ... other platforms ...
...
#endif

And if compilers change type properties in future versions, the types can be edited in one place.

In the past you also had a typical case where int might be 16 or 32 bits in size, so you couldn’t simply use the raw int type in code where you needed a DWORD-sized argument.

Hence why you have things like LPARAM and WPARAM.

It’s also used as a form of abstraction. Which is why you see typedefs like

typedef int Handle;

Because while it’s an int now, the library author reserves the ability to change it later down the track to anything else, say a void *, or any other type they deem necessary.

But the client code doesn’t need to know it’s an int specifically, since that’s just what it currently happens to be. All the client needs to know is to pass it along to functions accepting a Handle type.

Typedefs also allow configuration at compile time. E.g. some libraries may have a Real type for real numbers. It could be defined in a way such as

#ifdef USE_DOUBLE_PREC
typedef double Real;
#else
typedef float Real;
#endif

And the user of the library can optionally set /DUSE_DOUBLE_PREC when compiling to get double precision float support, but the important thing is that no library code needs to change for this to work, since it’s been abstracted.