Должно ли встроенное приложение C ++ использовать общий заголовок с typedefs для встроенных типов C ++? - PullRequest
4 голосов
/ 19 августа 2010

Это обычная практика, когда я работаю, чтобы избегать непосредственного использования встроенных типов и вместо этого включить файл standardtypes.h, в котором есть такие элементы, как:

// \Common\standardtypes.h
typedef double             Float64_T;
typedef int                SInt32_T;

Почти все компоненты и исходные файлы становятся зависимыми от этого заголовка, но некоторые люди утверждают, что необходимо абстрагировать размер типов (на практике это не было необходимо).

Является ли это хорошей практикой (особенно в системах с большими компонентами)? Есть ли лучшие альтернативы? Или встроенные типы должны использоваться напрямую?

Ответы [ 7 ]

9 голосов
/ 19 августа 2010

Вы можете использовать стандартизированные версии, доступные в современных реализациях C и C ++, в заголовочном файле: stdint.h

Имеет такие типы: uint8_t, int32_t и т. Д.

В общем, это хороший способ защитить код от зависимости от платформы. Даже если вы до сих пор не испытывали в этом необходимости, это, безусловно, облегчает интерпретацию кода, поскольку не нужно угадывать размер хранилища, как для «int» или «long», размер которого будет изменяться с платформы.

3 голосов
/ 19 августа 2010

Вероятно, было бы лучше использовать стандартные типы POSIX, определенные в stdint.h и др. , например, uint8_t, int32_t и т. Д. Я не уверен, есть ли часть C ++но пока они в C99.

2 голосов
/ 24 августа 2010

Так как это еще не было сказано, и даже если вы уже приняли ответ:

Используются только типы с конкретным размером, когда вам необходимо типы с конкретным размером.В основном это означает, что когда вы сохраняете данные, если вы напрямую взаимодействуете с оборудованием, или используете какой-то другой код (например, сетевой стек), который ожидает типы определенного размера.В большинстве случаев вам следует просто использовать типы абстрактного размера, чтобы ваш компилятор мог более разумно оптимизировать и чтобы будущие читатели вашего кода не были обременены бесполезными деталями (такими как размер и подпись счетчика цикла).

(Как уже говорилось в нескольких других ответах, используйте stdint.h, а не что-то домашнее, когда пишете новый код и не взаимодействует со старым.)

1 голос
/ 19 августа 2010

Самая большая проблема с этим подходом состоит в том, что так много разработчиков делают это, что, если вы используете стороннюю библиотеку, вы, скорее всего, столкнетесь с конфликтом имен символов или несколькими именами для одних и тех же типов.В случае необходимости было бы целесообразно придерживаться стандартной реализации, предоставляемой C99 stdint.h.

Если ваш компилятор не предоставляет этот заголовок (как, например, VC ++), тогда создайте тот, который соответствует этому стандарту.Например, один для VC ++ можно найти по адресу http://msinttypes.googlecode.com/svn/trunk/stdint.h

. В вашем примере я не вижу особого смысла для определения типов с плавающей запятой, зависящих от размера, поскольку они обычно тесно связаны с аппаратным обеспечением FP цели ипредставление используется.Кроме того, диапазон и точность значения с плавающей запятой определяется сочетанием ширины экспоненты и значительной ширины, поэтому одна только общая ширина мало что говорит вам или гарантирует совместимость между платформами.Что касается одинарной и двойной точности, то между платформами гораздо меньше вариаций, большинство из которых используют представления IEEE-754.На некоторых 8-битных компиляторах float и double являются 32-битными, тогда как long double на x86 GCC составляет 80 бит, но только 64-битные в VC ++.Аппаратный модуль x86 поддерживает 80-битное аппаратное обеспечение (2) .

1 голос
/ 19 августа 2010

Может иметь значение, если вы создаете кроссплатформенный код, где размер нативных типов может варьироваться от системы к системе.Например, тип wchar_t может варьироваться от 8 до 32 бит, в зависимости от системы.

Лично я не думаю, что описанный вами подход настолько практичен, насколько могут предположить его сторонники.Я бы не стал использовать этот подход даже для кроссплатформенной системы.Например, я бы предпочел собрать свою систему для непосредственного использования wchar_t и просто написать код, осознавая, что размер wchar_t будет варьироваться в зависимости от платформы.Я считаю, что это гораздо ценнее.

1 голос
/ 19 августа 2010

Я думаю, что это не очень хорошая практика. Хорошая практика - использовать что-то вроде uint32_t , где вам действительно нужно 32-разрядное целое число без знака, а если вам не нужен конкретный диапазон, используйте просто unsigned .

0 голосов
/ 27 августа 2010

Как уже говорили другие, используйте стандартные типы, определенные в stdint.h.Я не согласен с теми, кто говорит использовать их только в некоторых местах.Это работает нормально, когда вы работаете с одним процессором.Но когда у вас есть проект, который использует несколько типов процессоров (например, ARM, PIC, 8051, DSP) (что не редкость во встроенных проектах), отслеживание того, что означает int, или возможность копировать код из одного процессора в другой почтитребует, чтобы вы использовали определения типа фиксированного размера.

По крайней мере, это необходимо для меня, так как в течение последних шести месяцев я работал над кодом 8051, PIC18, PIC32, ARM и x86 для различных проектов, и я не могу отслеживать все различия, не привинчиваягде-то

...