с++ cstdint

Чем значения fast отличаются от не fast? Чем значения least отличаются от не least? Когда нужно использовать значения intptr_t/uintptr_t?

http://en.cppreference.com/w/cpp/types/integer

Стоит ли использовать его типы всегда вместо обычных?

http://stackoverflow.com/q/6144682

При сериализации/десериализации нужно юзать cstdint типы. Во всех остальных случаях - обычные.

А в чем преимущество обычных типов, не из cstdint типов? Мне кажется правильней использовать везде cstdint, более конкретней код, или я не прав?

Преимущество в том, что не надо подключать <cstdint>, очевидно же.

правильней использовать везде cstdint

Если важен размер и диапазон значений — то да. Размер и диапазон обычно важен только когда в спецификации алгоритма/протокола написано, что надо использовать N байтов. Остальные случаи — это или внезапно обнаруживаемая казуистика из разряда «ну кто бы мог подумать, что может быть больше 4 294 967 295 %понятий предметной области%», или какой-нибудь тулчейн под бог знает что, где uint32_t нет, int == short, но двух байтов мало.

А в чем преимущество обычных типов

int по определению - наиболее эффективный для вычислений на конкретной машине. В отличие от того же int32_t, который и ним может не совпадать.

Plain ints have the natural size suggested by thearchitecture of the execution environment

А fast значение (из cstdint) эффективней int?

int по определению - наиболее эффективный для вычислений на конкретной машине.

Так было лет эдак 20 тому назад, а сейчас это ещё одни стандартный тип.

А в чем преимущество обычных типов, не из cstdint типов? Мне кажется правильней использовать везде cstdint, более конкретней код, или я не прав?

Стандартные типы это легаси, сейчас не имеют какой-либо смысловой нагрузки, быть может кроме char, и в общем виде заранее не возможно узнать какой из них тебе подойдёт. А подойти может далеко не любой...

Снизу битность ограничивается диапазоном возможных значений, а сверху - объёмом памяти который будут занимать данные. Например, если работаешь с несколькими значениями то всё равно какую битность использовать - можно выбрать самый быстрый тип. А если есть много однотипных данных, то вероятно придётся выбрать наименьшую подходящую битность чтобы эффективно использовать кеш CPU.

Стандартные типы дают только гаранитю на битнось снизу, причём наиболее востребованный сейчас тип имеет убоговатый литерал 'long long'. В общем, без аналога cstdint + {char, bool, size_t} уже давно никак не обойтись и если посмотришь в какой-нибудь зрелый c/c++ проект, то наверняка увидешь использование сstdint, либо свои подобные велосипеды.

Так было лет эдак 20 тому назад, а сейчас это ещё одни стандартный тип.

Так написано в стандарте. В любом из.

Для этого _fast и есть, не?

Так написано в стандарте. В любом из.

Нет, там так не написано.

Ок, меня проглючило. Я же сам привел цитату, как там написано.

А как это коррелирует с тем, что на x86_64 sizeof(int) == 4?

x86_64 sizeof(int) == 4?

Вопрос реализации компиляторов, а не платформы. Захотели больше обратной совместимости и оставили 4.

Так для x86_64 четырёхбайтовый инт оптимален?

Так для x86_64 четырёхбайтовый инт оптимален?

А что такое оптимален? Вмещает много, занимает в памяти мало, работать с ним легко.

64-х битные инструкции кушают больше кэша, это грозит кэш миссами -> замедлением работы

при чем тут инструкции, речь идет про данные

при чем тут кэш-миссы, длина кэш-линии сегодня обычно 64 бита

По скорости работы. Partial register writes, вот это всё.

По скорости работы. Partial register writes, вот это всё.

Слишком расплывчато.
Допустим есть большой вектор неких структур. Обработка таких структур производится в цикле. Уменьшение sizeof такой структуры позволит сократить количество cache-miss.

при чем тут инструкции, речь идет про данные

Ну так и данные тоже лежат в кеше. И чем чаще нужные данные попадают в кеш, тем быстрее с ними работа. Тем выше скорость обработки таких данных.

при чем тут кэш-миссы, длина кэш-линии сегодня обычно 64 бита

Это где размер кеш-лайна 64 бита? Если речь о x86, то кеш-лайн 64 байта.

Знчт использование везде типов из cstdint не плохо? Битность снизу - не меньше какого то значения? И вы упомянули char, не на всех платформах он будет 8битный, почему бы не использовать для хранения фиксированый тип?

В том, что размер «обычных типов» пропорционален машинному слову. Образно говоря это более производительно, в общем случае.

Знчт использование везде типов из cstdint не плохо?

да.

И вы упомянули char, не на всех платформах он будет 8битный, почему бы не использовать для хранения фиксированый тип?

В смысле, почему не везде использовать 8битные байты?

А что будет если какой нибудь длинючий тип cstdint не поддерживается платформой?

Технически не будет определён соответствующий тип и не будет дефайнов с лимитами по которым можно попробовать узнать об отсутствии типа. Что делать дальше уже вопрос к разработчику - можно не собираться на таких платформах или заменить тип на свою софтварную реализацию.