Я много занимаюсь этой проблемой, работая со сторонними библиотеками, где все хотят иметь свой собственный псевдоним типа для целых чисел, чисел с плавающей запятой, длинных, коротких, псевдонимов байтов вместо символов и т. Д.
Это очень раздражает.Это часто делается для обеспечения мобильности, но в конечном итоге дает каждой библиотеке свои собственные стандарты.
Что мне больше всего не нравится здесь, так это с точки зрения связи.У меня мог бы быть общий интерфейс сетки, который должен быть отделен от любых проблем рендеринга.Тем не менее, некоторые из его данных могут быть переданы непосредственно в функцию OpenGL, которая хочет предположить, что размер передаваемых нами целых чисел будет соответствовать sizeof(GLint).
В некоторых случаях это не просто эстетично.Возможно, даже нецелесообразно включать заголовки GL в этот заголовок сетки, поскольку он может быть частью широко используемого комплекта разработки программного обеспечения, который не должен требовать таких зависимостей времени компиляции от сторонних разработчиков плагинов, которые его используют.
И все же переносимость - это проблема.Мне удалось пережить кошмарный сценарий в очень крупномасштабной устаревшей кодовой базе C, где неявное предположение было сделано по всей кодовой базе, что sizeof(int) == sizeof(void*).Потребовались годы поиска игл в стоге сена, чтобы портировать эту кодовую базу на 64-битную.
Я лично остановился на том, чтобы с годами отдавать предпочтение простым старым несвязанным типам данных.Мне также нравилось просто использовать целые числа со знаком, например, я находил это неудобным в прошлом, даже избегая предупреждений в основных циклах через контейнеры, где некоторые будут использовать int, другие unsigned int, другие size_t и т. Д.., чтобы указать количество элементов, содержащихся.По крайней мере, лично я обнаружил, что мое время на обслуживание сократилось, просто отдав предпочтение int без очень веской причины не делать этого.
Чтобы попытаться смягчить потенциальный наихудший сценарий на некоторой платформе, где sizeof(int) != sizeof(GLint),например, я склонен свободно распространять утверждения вокруг кода, который предполагает, что эти два значения равны: assert(sizeof(int) == sizeof(GLint));.Это должно значительно уменьшить боль, связанную с таким кошмарным сценарием, с которым я сталкивался ранее при переносе с 32-разрядного на 64-разрядный режим.Это также явно выражает эти предположения.
Я нашел это, чтобы установить удобный баланс для моего случая.Конечно, все это субъективно и может значительно варьироваться в зависимости от ваших вариантов использования.Но это одно из возможных решений, которое может позволить вам все больше отдавать предпочтение простым старым несвязанным типам данных, несмотря на все эти сторонние библиотеки, и не сталкиваться с наихудшим сценарием, если ваши предположения перестанут быть верными на какой-либо платформе.