C type casting

[perasperaadastra]

Подскажите пожалуйста, как компилятор отнесется к следующему куску кода?

Code: Select all

uint8_t varX = 0;
uint16_t varY = 4 * (99225000 + (2*varX-1)*100000) / 32768;

Конкретно, меня интересует то, как компилятор посчитает (2*varX-1).
varX и varY обе беззнаковые переменные. Если не делать кастинг вручную, сочтет ли компилятор, что (2*varX-1) это тоже беззнаковый результат? Или же он автоматически сделает промежуточный кастинг? В первом случае, как я понимаю, 2*0-1 = 255, а во втором, 2*0-1= -1

Если я хочу убедиться, что всё будет нормально, правильно ли я понимаю, что нужно сделать так:

Code: Select all

(2*(int8_t)varX-1)

PS Наверно пример неудачный. Даже если 2*0-1 = 255, конечный результат все равно будет правильным из-за того, что добавляется число, которое сделает результат положительным...

[Flash-04]

Если склероз мне не изменяет, компилятор вначале приводит все переменные к одному типу (самому "широкому") потом считает, а потом впихивает в ожидаемый output.

[Flash-04]

Кстати тип констант зависит от платформы. Раньше это были 16 битовые числа (а не 8!),потом стали 32.

[DVK]

Если склероз мне не изменяет, компилятор вначале приводит все переменные к одному типу (самому "широкому") потом считает, а потом впихивает в ожидаемый output.

Какой тип "шире": signed char (от -128 до 127) или unsigned char (от 0 до 255)?

[DVK]

Подскажите пожалуйста, как компилятор отнесется к следующему куску кода?

Code: Select all

uint8_t varX = 0;
uint16_t varY = 4 * (99225000 + (2*varX-1)*100000) / 32768;

Конкретно, меня интересует то, как компилятор посчитает (2*varX-1).
varX и varY обе беззнаковые переменные. Если не делать кастинг вручную, сочтет ли компилятор, что (2*varX-1) это тоже беззнаковый результат? Или же он автоматически сделает промежуточный кастинг? В первом случае, как я понимаю, 2*0-1 = 255, а во втором, 2*0-1= -1

Если я хочу убедиться, что всё будет нормально, правильно ли я понимаю, что нужно сделать так:

Code: Select all

(2*(int8_t)varX-1)

PS Наверно пример неудачный. Даже если 2*0-1 = 255, конечный результат все равно будет правильным из-за того, что добавляется число, которое сделает результат положительным...

::std::is_unsigned<decltype((2*0U-1))>::value выдаёт true, а ::std::is_unsigned<decltype((2*0-1))>::value - false

[DVK]

Кстати тип констант зависит от платформы. Раньше это были 16 битовые числа (а не 8!),потом стали 32.

Для целочисленных литер (а не констант(!), как многие их называют), настоятельно советую использовать суффиксы. Облегчите жизнь себе сильно

[AndreyT]

Подскажите пожалуйста, как компилятор отнесется к следующему куску кода?

Code: Select all

uint8_t varX = 0;
uint16_t varY = 4 * (99225000 + (2*varX-1)*100000) / 32768;

Конкретно, меня интересует то, как компилятор посчитает (2*varX-1).

Переменная varX имеет "маленький" тип uint8_t. Это значит, что еще до начала каких-либо вычислений она будет безусловно подвергнута integral promotions, т.е. ее значение будет неявно приведено к типу int. Языки С и С++ никогда не выполняют арифметические вычисления в "маленьких" типах (за редким исключением), а всегда сначала неявно приводят "маленькие" типы к типу int (или, в экзотических случаях, к unsigned int). А константы 2 и 1 и так имеют тип int. То есть подвыражение (2*varX-1) будет вычисляться в домене знакового типа int и его результат будет иметь знаковый тип int.

То же относится и ко всему остальному выражению, если предполагать, что константа 99225000 помещается в тип int на данной платформе. (Если нет, то она получит тип long. Сложение 99225000 + выполнится в домене типа long и остаток выражения вычислится в домене long).

Только в самом конце результат вычисления (типа int или long) будет сконвертирован к типу uint16_t. Такая конверсия определена языком и сводится к приведению по модулю (UINT16_MAX + 1).

varX и varY обе беззнаковые переменные. Если не делать кастинг вручную, сочтет ли компилятор, что (2*varX-1) это тоже беззнаковый результат?

Нет. Integral promotions неявно приведут малый беззнаковый uint8_t к знаковому типу int. Вычисления будут делаться в знаковом типе и результат будет знаковым.

Если я хочу убедиться, что всё будет нормально, правильно ли я понимаю, что нужно сделать так: (2*(int8_t)varX-1)

Зависит от того, что имеется в виду под "нормально". Выбор типа int8_t - странен, ибо его диапазон не покрывает диапазон исходного типа uint8_t. Если хочется знаковых вычислений, то лучше уж взять тип int для явного приведения, особенно если учесть, что константы 1 и 2 имеют тип int. Но необходимости в явном приведении нет.

Если же хочется все вычислять в беззнаковом домене, то надо просто сделать так, чтобы все операнды были беззнаковыми

Code: Select all

uint16_t varY = 4u * (99225000u + (2u*varX-1u)*100000u) / 32768u;

[perasperaadastra]

Если склероз мне не изменяет, компилятор вначале приводит все переменные к одному типу (самому "широкому") потом считает, а потом впихивает в ожидаемый output.

Вот, я тоже подумал, что это логичное поведение, когда мешаются типы разного разного размера. Но если есть последовательность нескольких арифметических действий, можно ли доверять компилятору делать "расширение" типа только тогда, когда без него не обойтись, или же он тупо сразу возьмет все переменные и приведет к самому широкому типу? Вопрос не праздный — у меня 8-битные регистры, и когда я складываю 8-битную переменную с 32-битной, хотелось бы избежать ситуации, когда 8-битная переменная превращается в 32-битную, а потом складываются ненужные старшие байты. Возможно, оптимизатор это ловит, а может быть и нет — хотелось бы знать, что происходит, не заглядывая в ассембли вывод.

Кстати тип констант зависит от платформы. Раньше это были 16 битовые числа (а не 8!),потом стали 32.

Для целочисленных литер (а не констант(!), как многие их называют), настоятельно советую использовать суффиксы. Облегчите жизнь себе сильно

Но они какие-то "неопределенные". К примеру, 10u это unsigned int. Но, как я понимаю, определение int разнится от платформы к платформе... Как я могу указать, что 10 это строго 8 бит, а не какие-нибудь 16?

UPD: AndreyT уже ответил, пока я писал эти вопросы.

[perasperaadastra]

Переменная varX имеет "маленький" тип uint8_t. Это значит, что еще до начала каких-либо вычислений она будет безусловно подвергнута integral promotions, т.е. ее значение будет неявно приведено к типу int. Языки С и С++ никогда не выполняют арифметические вычисления в "маленьких" типах (за редким исключением), а всегда сначала неявно приводят "маленькие" типы к типу int (или, в экзотических случаях, к unsigned int). А константы 2 и 1 и так имеют тип int. То есть подвыражение (2*varX-1) будет вычисляться в домене знакового типа int и его результат будет иметь знаковый тип int.
...

Спасибо за подробный ответ! Загвоздка в том, что у меня 8-битный контроллер, поэтому integer promotion имеет неприятные последствия для производительности. Буду читать документацию, как избежать лишние вычисления без использования ассембли. Мне кажется, что avr-gcc должен иметь способность работать с 8-битными типами.

PS "Integer promotion" — знакомые ключевые слова. У меня такое ощущение, что я уже задавал подобный вопрос, и я раньше узнал про integer promotion тоже из вашего ответа. Дежа вю? Или я теряю память? Надеюсь, что не последнее.

[AndreyT]

Для целочисленных литер (а не констант(!), как многие их называют), настоятельно советую использовать суффиксы. Облегчите жизнь себе сильно

В терминологии языка С (а речь пока идет именно о С) буквальные значения называется именно константами, а не литералами. В языке С литералами называются только строковые литералы (string literals) и составные литералы (compound literals). Буквальные скалярные значения - это именно константы (constants).

Называть все буквальные значения литералами стали только в С++. Это разделение терминологии С и С++ по-прежнему строго соблюдается.

[AndreyT]

Загвоздка в том, что у меня 8-битный контроллер, поэтому integer promotion имеет неприятные последствия для производительности. Буду читать документацию, как избежать лишние вычисления без использования ассембли. Мне кажется, что avr-gcc должен иметь способность работать с 8-битными типами.

С требует чтобы арифметические вычисления производились в типе [signed/unsigned] int или большем. И при этом требует, чтобы диапазон int был как минимум -32767..+32767. Это автоматически означает, что в рамках языка С компилятор будет вынужден выполнять promotions как минимум до 16-битного типа. Разумеется, это концептуальные promotions. Если компилятор видит, что результат будет правильным и без них, то оно имеет право не выполнять эти promotions физически.

А если надежды на такую оптимизацию нет, то чтобы выполнять вычисления в рамках 8-битного типа придется выходить за рамки языка, т.е. пользоваться нестандартными средствами компилятора.

[DVK]

Для целочисленных литер (а не констант(!), как многие их называют), настоятельно советую использовать суффиксы. Облегчите жизнь себе сильно

В терминологии языка С (а речь пока идет именно о С) буквальные значения называется именно константами, а не литералами. В языке С литералами называются только строковые литералы (string literals) и составные литералы (compound literals). Буквальные скалярные значения - это именно константы (constants).

Называть все буквальные значения литералами стали только в С++. Это разделение терминологии С и С++ по-прежнему строго соблюдается.

Good point. Тем не менее, суффиксы все равно советую использовать, что в С, что в С++

[thinker]

Но они какие-то "неопределенные". К примеру, 10u это unsigned int. Но, как я понимаю, определение int разнится от платформы к платформе... Как я могу указать, что 10 это строго 8 бит, а не какие-нибудь 16?

По этой причине у нас integer вообще не использутся. А вместо него основные типы определены так. Потом их легко переопределить под другой компилятор если потребуется.

Code: Select all

typedef unsigned char   u8_t;   // 8 bit unsigned
typedef unsigned short  u16_t;  // 16 bit unsigned
typedef unsigned long   u32_t;  // 32 bit unsigned
typedef signed char     s8_t;   // 8 bit signed
typedef signed short    s16_t;  // 16 bit signed
typedef signed long     s32_t;  // 32 bit signed

[M. Ridcully]

Но они какие-то "неопределенные". К примеру, 10u это unsigned int. Но, как я понимаю, определение int разнится от платформы к платформе... Как я могу указать, что 10 это строго 8 бит, а не какие-нибудь 16?

По этой причине у нас integer вообще не использутся. А вместо него основные типы определены так. Потом их легко переопределить под другой компилятор если потребуется.

Code: Select all

typedef unsigned char   u8_t;   // 8 bit unsigned
typedef unsigned short  u16_t;  // 16 bit unsigned
typedef unsigned long   u32_t;  // 32 bit unsigned
typedef signed char     s8_t;   // 8 bit signed
typedef signed short    s16_t;  // 16 bit signed
typedef signed long     s32_t;  // 32 bit signed

Какие-то экзотические компиляторы нужно поддерживать, где stdint.h отсутствует?
Или код старый?

[thinker]

Какие-то экзотические компиляторы нужно поддерживать, где stdint.h отсутствует?
Или код старый?

stdint.h есть, но у нас свои стандарты на типы данных. Насколько я понял это сделано чтобы независеть от компилятора и "make code more portable".

[DVK]

Но они какие-то "неопределенные". К примеру, 10u это unsigned int. Но, как я понимаю, определение int разнится от платформы к платформе... Как я могу указать, что 10 это строго 8 бит, а не какие-нибудь 16?

По этой причине у нас integer вообще не использутся. А вместо него основные типы определены так. Потом их легко переопределить под другой компилятор если потребуется.

Code: Select all

typedef unsigned char   u8_t;   // 8 bit unsigned
typedef unsigned short  u16_t;  // 16 bit unsigned
typedef unsigned long   u32_t;  // 32 bit unsigned
typedef signed char     s8_t;   // 8 bit signed
typedef signed short    s16_t;  // 16 bit signed
typedef signed long     s32_t;  // 32 bit signed

Ваши typedefs не гарантируют ширины указанных в комментариях. Стандарт лишь дает гарантию что sizeof(char)==1, сколько там бит, не известно, может 8, может 64, а может 9

[AndreyT]

Code: Select all

typedef unsigned char   u8_t;   // 8 bit unsigned
typedef unsigned short  u16_t;  // 16 bit unsigned
typedef unsigned long   u32_t;  // 32 bit unsigned
typedef signed char     s8_t;   // 8 bit signed
typedef signed short    s16_t;  // 16 bit signed
typedef signed long     s32_t;  // 32 bit signed

Ваши typedefs не гарантируют ширины указанных в комментариях. Стандарт лишь дает гарантию что sizeof(char)==1, сколько там бит, не известно, может 8, может 64, а может 9

Так ни о каком универсальном гарантировании ширины для данного набора определений речи и не шло.

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

Какие-то экзотические компиляторы нужно поддерживать, где stdint.h отсутствует?

С формально-педантичной точки зрения stdint.h - тоже не панацея. stdint.h гарантирует ширину таких типов, как int8_t, но не гарантирует их существования.

[thinker]

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

Да, у нас все типы определены в одном файле настроек проекта, который настраивается под конкретный micro и компилятор.

Какие-то экзотические компиляторы нужно поддерживать, где stdint.h отсутствует?

С формально-педантичной точки зрения stdint.h - тоже не панацея. stdint.h гарантирует ширину таких типов, как int8_t, но не гарантирует их существования.

Спасибо что объяснили.

[tau]

Вообще-то, хорошо было бы указать тип компилятора.
Я как-раз примерно такой баг недавно и вычёсывал, так выяснил, что некоторое компиляторы радостно всё это хозяйство скомпилируют с неожиданными (и даже разными) результатами. Майкрософтовский компилятор хотя бы выдаст предупреждение про narrowing, то же сделает и XCode. А вот с остальными как повезёт.

[DVK]

Code: Select all

typedef unsigned char   u8_t;   // 8 bit unsigned
typedef unsigned short  u16_t;  // 16 bit unsigned
typedef unsigned long   u32_t;  // 32 bit unsigned
typedef signed char     s8_t;   // 8 bit signed
typedef signed short    s16_t;  // 16 bit signed
typedef signed long     s32_t;  // 32 bit signed

Ваши typedefs не гарантируют ширины указанных в комментариях. Стандарт лишь дает гарантию что sizeof(char)==1, сколько там бит, не известно, может 8, может 64, а может 9

Так ни о каком универсальном гарантировании ширины для данного набора определений речи и не шло.

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

Креативненько Вы процитировали. Изначально, thinker писал про компилятор, а не платформу.

чтобы получить требуемые ширины типов. Т.е. typedef нужны просто для того, чтобы облегчить эту задачу - исправлять в одном централизованном месте.

Это одно централизованное место называется stdint.h, и исправлять там ничего не надо: любой C99-compliant компилятор предоставляет его под конкретную платформу. Думаю что у компилятора лучше получится чем подбирать значения этих typedef вручную.

Какие-то экзотические компиляторы нужно поддерживать, где stdint.h отсутствует?

С формально-педантичной точки зрения stdint.h - тоже не панацея. stdint.h гарантирует ширину таких типов, как int8_t, но не гарантирует их существования.

Если их не существует, то и подобрать значения этих typedef вручную тоже не получится.

[AndreyT]

Креативненько Вы процитировали. Изначально, thinker писал про компилятор, а не платформу.

Ничего "креативненького". В мире С компилятор - это и есть платформа. Концепция языка никоим образом не запрещает компиляторам реализовывать hardware- и OS-abstraction layers любой толщины. Понятно, что толстый слой абстракции - не в духе языка С, который разрабатывался для максимальной эффективности. Но я не вижу необходимости привносить это деление в дискуссию без необходимости.

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

Это одно централизованное место называется stdint.h, и исправлять там ничего не надо: любой C99-compliant компилятор предоставляет его под конкретную платформу. Думаю что у компилятора лучше получится чем подбирать значения этих typedef вручную.
...
Если их не существует, то и подобрать значения этих typedef вручную тоже не получится.

Если их не существует, то подбирать их придется "приблизительно", руководствуясь application-specific соображениями. Компилятор, разумеется, об этих соображениях не имеет ни малейшего представления.

[DVK]

Креативненько Вы процитировали. Изначально, thinker писал про компилятор, а не платформу.

Ничего "креативненького". В мире С компилятор - это и есть платформа.

Никогда и нигде компилятор != платформе, не надо путать. Понятие платформы, в том числе, включает в себя понятие data model, которая implementation and hardware dependent.

Концепция языка никоим образом не запрещает компиляторам реализовывать hardware- и OS-abstraction layers любой толщины. Понятно, что толстый слой абстракции - не в духе языка С, который разрабатывался для максимальной эффективности. Но я не вижу необходимости привносить это деление в дискуссию без необходимости.

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

Все слова правильные, а вот вывод не совсем. (см. выше)

Это одно централизованное место называется stdint.h, и исправлять там ничего не надо: любой C99-compliant компилятор предоставляет его под конкретную платформу. Думаю что у компилятора лучше получится чем подбирать значения этих typedef вручную.
...
Если их не существует, то и подобрать значения этих typedef вручную тоже не получится.

Если их не существует, то подбирать их придется "приблизительно", руководствуясь application-specific соображениями. Компилятор, разумеется, об этих соображениях не имеет ни малейшего представления.

Если их не существует, то не надо их аппроксимировать другими "похожими" типами. Используйте что есть под рукой.

[AndreyT]

Креативненько Вы процитировали. Изначально, thinker писал про компилятор, а не платформу.

Ничего "креативненького". В мире С компилятор - это и есть платформа.

Никогда и нигде компилятор != платформе, не надо путать. Понятие платформы, в том числе, включает в себя понятие data model, которая implementation and hardware dependent.

В формальном мире языка С нет "компилятора", "платформы", "hardware", "OS", а есть только понятие implementation, т.е. реализация компилятора в совокупности с реализацией стандартной библиотеки. Все. Никакой hardware dependency в С нет и никогда не было, по крайней мере с момента его стандартизации. Язык С "живет" в окружении абстрактной С-машины, предоставляемой данной реализацией. Любые особенности реализации (implementation-dependent behavior) - это особенности данной абстрактной С-машины. Ничего, кроме абстрактной С-машины, язык не знает и знать не должен.

В разговорной речи, когда речь идет о языке С, устоявшейся терминологией является использование терминов "компилятор", "платформы", "реализация" как синонимов.

Все слова правильные, а вот вывод не совсем. (см. выше)

Тут нет никакого "вывода", а есть банальная базовая аксиоматика языка. Я ее просто цитирую дословно, тут нет ничего моего лично.

Если их не существует, то подбирать их придется "приблизительно", руководствуясь application-specific соображениями. Компилятор, разумеется, об этих соображениях не имеет ни малейшего представления.

Если их не существует, то не надо их аппроксимировать другими "похожими" типами. Используйте что есть под рукой.

Мне не понятно противопоставление typedef-инга типов и идеи "использовать, что есть под рукой". Где связь?

[DVK]

Креативненько Вы процитировали. Изначально, thinker писал про компилятор, а не платформу.

Ничего "креативненького". В мире С компилятор - это и есть платформа.

Никогда и нигде компилятор != платформе, не надо путать. Понятие платформы, в том числе, включает в себя понятие data model, которая implementation and hardware dependent.

В формальном мире языка С нет "компилятора", "платформы", "hardware", "OS", а есть только понятие implementation, т.е. реализация компилятора в совокупности с реализацией стандартной библиотеки.

Странно: жопы нет, а слово есть... Есть 100500 (кросс)-компиляторов которые могут генерить код для разных платформ...

Все. Никакой hardware dependency в С нет и никогда не было, по крайней мере с момента его стандартизации. Язык С "живет" в окружении абстрактной С-машины, предоставляемой данной реализацией. Любые особенности реализации (implementation-dependent behavior) - это особенности данной абстрактной С-машины. Ничего, кроме абстрактной С-машины, язык не знает и знать не должен.

Читайте внимательно, что я написал: data model, которую компилятор реализует для платформы, есть штука, зависящая от железа. Так понятнее?

В разговорной речи, когда речь идет о языке С, устоявшейся терминологией является использование терминов "компилятор", "платформы", "реализация" как синонимов.

Пошло виляние филейной частью
Это как использовать слово объект вместо слова класс. В контексте может и можно понять, но просто кричит о невежестве так говорящего.

Все слова правильные, а вот вывод не совсем. (см. выше)

Тут нет никакого "вывода", а есть банальная базовая аксиоматика языка. Я ее просто цитирую дословно, тут нет ничего моего лично.

Цитаты принято оформлять соответствующим образом, чтобы чужое мнение за Ваше не приняли. А Вы приведите здесь ссылку, а мы подробно разберём, что там написано.

Если их не существует, то подбирать их придется "приблизительно", руководствуясь application-specific соображениями. Компилятор, разумеется, об этих соображениях не имеет ни малейшего представления.

Если их не существует, то не надо их аппроксимировать другими "похожими" типами. Используйте что есть под рукой.

Мне не понятно противопоставление typedef-инга типов и идеи "использовать, что есть под рукой". Где связь?

Надо находится, как Вы сами написали, в пределах абстрактной C машины, и не изобретать велосипед.

[M. Ridcully]

Во, полюбуйтесь, люди добрые - анальные черты характера буквоедство C++ программистов во всей красе!