Дело не в сокращении имен, а в переносимости. Разные платформы должны будут по-разному определять эти вещи.
В Std-C long
может быть 32 или 64 бита, в зависимости от вашего компилятора / цели, поэтому нельзя с уверенностью предположить, что он имеет определенный размер. Таким образом, автор библиотеки будет печатать свой собственный тип, гарантируя определенный размер, со знанием целевой платформы.
* 1006 Е.Г. *
#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
И если компиляторы изменят свойства типов в будущих версиях, типы можно редактировать в одном месте.
В прошлом у вас также был типичный случай, когда int
мог бы иметь размер 16 или 32 бита, поэтому вы не могли просто использовать необработанный тип int
в коде, где вам требовался аргумент размером DWORD
. .
Следовательно, почему у вас есть такие вещи, как LPARAM
и WPARAM
.
Он также используется как форма абстракции. Вот почему вы видите typedefs вроде
typedef int Handle;
Поскольку сейчас это int
, автор библиотеки оставляет за собой возможность изменить его позже на дорожку на что-либо другое, например, void *
или любой другой тип, который он сочтет необходимым.
Но клиентскому коду не нужно знать, что это конкретно int
, так как это именно то, чем он сейчас является. Все, что нужно знать клиенту, - это передать его функциям, принимающим тип Handle
.
Typedefs также позволяют конфигурировать во время компиляции. Например. некоторые библиотеки могут иметь тип Real
для действительных чисел. Это может быть определено таким образом, как
#ifdef USE_DOUBLE_PREC
typedef double Real;
#else
typedef float Real;
#endif
И пользователь библиотеки может при желании установить /DUSE_DOUBLE_PREC
при компиляции, чтобы получить поддержку с плавающей запятой двойной точности, но важно то, что никакой код библиотеки не нужно менять, чтобы это работало, так как он абстрагирован.