Здравствуйте, StevenIvanov, Вы писали:

SI>Однако, скажем так, не всегда удобно иметь дело с кодом, в котором россыпью "int8, uint32, int16" и на другой платформе компилятор плюется пачками ворнингов.

Вы не могли бы пояснить этот момент? Лично я в последнее время вместо char\short\int использую intX_t и int_fastX_t. Мне представляется это более переносимым, если завтра я переползу на другую платформу. Разве нет?

Или вы имели в виду что-то другое?

Здравствуйте, Непомнящий Евгений, Вы писали:

НЕ>Здравствуйте, StevenIvanov, Вы писали:

SI>>Однако, скажем так, не всегда удобно иметь дело с кодом, в котором россыпью "int8, uint32, int16" и на другой платформе компилятор плюется пачками ворнингов.

НЕ>Вы не могли бы пояснить этот момент? Лично я в последнее время вместо char\short\int использую intX_t и int_fastX_t. Мне представляется это более переносимым, если завтра я переползу на другую платформу. Разве нет?

НЕ>Или вы имели в виду что-то другое?

Подразумевалось явное злоупотребление такими типами. Например использовать везде вместо size_t — uint32.
По моему мнению использование таких типов оправдано лишь при работе с разного рода Portable Data Unit'ами, и там где гарантированно надо
обеспечить разрядность данных не меньше требуемой.

Здравствуйте, StevenIvanov, Вы писали:

SI>По моему мнению использование таких типов оправдано лишь при работе с разного рода Portable Data Unit'ами, и там где гарантированно надо
SI>обеспечить разрядность данных не меньше требуемой.

Я сейчас пишу для 8-битников, размер int у них 2 байта. Соответственно с точки зрения быстродействия большинство переменных желательно делать char / unsigned char. Однако если завтра платформа изменится, то такие переменные станут источниками тормозов; собственно поэтому я повсеместно использую (u)int_fast8_t.

На декстопах это наверное не так актуально, но все же, имхо, вторая строка значительно информативнее первой...

int myVar;
int_fast16_t myVar;

НЕ>Я сейчас пишу для 8-битников, размер int у них 2 байта. Соответственно с точки зрения быстродействия большинство переменных желательно делать char / unsigned char. Однако если завтра платформа изменится, то такие переменные станут источниками тормозов; собственно поэтому я повсеместно использую (u)int_fast8_t.

НЕ>На декстопах это наверное не так актуально, но все же, имхо, вторая строка значительно информативнее первой...
НЕ>

НЕ>int myVar;
НЕ>int_fast16_t myVar;
НЕ>

Угу. Вот только тесты показывают, что работа с int16_t оказывается медленнее, чем с int.
Несмотря на то, что в кэш любого уровня int16_t помещается вдвое больше.
Так что int_fast16_t в работе _медленнее_ чем незатейливый int, и явное указание разрядности имеет смысл только в огромных массивах и полях структур, предназначенных для "внешнего мира" либо АПИ.

Здравствуйте, K13, Вы писали:

K13>Угу. Вот только тесты показывают, что работа с int16_t оказывается медленнее, чем с int. Несмотря на то, что в кэш любого уровня int16_t помещается вдвое больше.
Ну так intX_t ИМХО, и следует использовать только там, где надо РОВНО X бит — что вы ниже и говорите.
K13>Так что int_fast16_t в работе _медленнее_ чем незатейливый int,
А насчет этого не понял. int_fast16_t это на большинстве платформ как раз и есть int, почему он должен работать медленнее?

Здравствуйте, Непомнящий Евгений, Вы писали:

НЕ>Здравствуйте, K13, Вы писали:

K13>>Угу. Вот только тесты показывают, что работа с int16_t оказывается медленнее, чем с int. Несмотря на то, что в кэш любого уровня int16_t помещается вдвое больше.
НЕ>Ну так intX_t ИМХО, и следует использовать только там, где надо РОВНО X бит — что вы ниже и говорите.
K13>>Так что int_fast16_t в работе _медленнее_ чем незатейливый int,
НЕ>А насчет этого не понял. int_fast16_t это на большинстве платформ как раз и есть int, почему он должен работать медленнее?

на большинстве платформ int_fast16_t это short.
А на 32-битных машинах целесообразнее использовать обычный int (он 32-битный, а не 16-и битный).
Возможно в вашем случае int_fast16_t было бы проще обозначить просто fast_int, не фиксируя разряность.

Здравствуйте, Непомнящий Евгений, Вы писали:

НЕ>Здравствуйте, StevenIvanov, Вы писали:

SI>>Однако, скажем так, не всегда удобно иметь дело с кодом, в котором россыпью "int8, uint32, int16" и на другой платформе компилятор плюется пачками ворнингов.

НЕ>Вы не могли бы пояснить этот момент? Лично я в последнее время вместо char\short\int использую intX_t и int_fastX_t. Мне представляется это более переносимым, если завтра я переползу на другую платформу. Разве нет?

НЕ>Или вы имели в виду что-то другое?

Вставлю свои пять копеек.
Я делаю так:

typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;

typedef signed char s8;
typedef signed short s16;
typedef signed int s32;

Ну или через #define.
Имхо, это и понятнее (сразу видно разрядность), и достаточно удобно: в новом проекте достаточно просто поменять эти typedef.

Здравствуйте, StevenIvanov, Вы писали:

SI>на большинстве платформ int_fast16_t это short.
Если это так, то ИМХО, неправильно сделали. int_fastX_t — это именно максимально быстрый int, в котором не меньше 16 бит, т.е. на 32-битных платформах это 4 байта.

Вот int_least16_t — это хороший кандидат для short.

Впрочем, вместо "стандартных" int*_t типов можно использовать аналогичные собственные int_fastX_m, определямые в зависимости от платформы и компилятора.

SI>Возможно в вашем случае int_fast16_t было бы проще обозначить просто fast_int, не фиксируя разряность.

Да нет, самый быстрый int у меня — 1 байт, а этого часто не хватает. Поэтому я предпочитаю писать int_fastX_t, явно указывая размерность.

ИМХО, стандартные типы — short, int, long — вообще какие-то "малополезные". Обычно задача такая: есть переменная, принимающая значения из некоторого диапазона. Затем мне надо подобрать (переносимый) тип для этой переменной. А так как практически никаких гарантий насчет short\int\long не дается — то как можно выбрать? Например, пусть диапазон -1<=x<=40000. Это short или int или long? А если я хочу оптимизировать по размеру памяти\скорости обработки?

int(_fast/_least)X_t — это по-моему, просто идеальное решение.