-
- stdint.h -- это не только фиксированные типы. Там есть int_fast8_t, который прекрасно получается 8-битным на PIC18, 16-битным на PIC24 и 32-битным на PIC32 (MIPS или ARM). Фиксированные типы нужны в основном, где нужно ограничить объём памяти. fk0(510 знак., 04.05.2018 13:59)
- А что там с uint_fast8_t в логических выражениях? Есть "обрезание" до 8 бит в логических выражениях? Слыхал, что вроде как есть, но ни разу не проверял (ни разу не было явной необходимости использовать). Если есть, то получается, компилятор должен Vit(52 знак., 04.05.2018 14:10)
- Ко всем вычислениям применяется правило integer promotion. Заключающееся в расширении до размера int всех типов меньших размеров перед началом вычисления. Поэтому что uint_fast8_t, что unsigned char, если размер uint_fast8_t меньше инта, оба fk0(1190 знак., 04.05.2018 14:24)
- Вроде бы для беззнаковых "a - b < c" будет вычисляться правильно, т.е. результат a-b будет знаковым, и сравнение будет знаковым. Разумеется при условии отсутствии переполнения при вычислениях и преобразованиях. - AlexBi(04.05.2018 16:27)
- Спасибо, можно было просто сказать, что слухам верить не нужно:) Но как доберусь до Кайла для 51-х, посмотрю. Слухи были, что там это маскирование встроено (настройкой) - Vit(04.05.2018 14:40)
- В ряде компиляторов "недо-C" для embedded включалось отключение integer promotion. Потому, что в целом это повышает эффективность кода. В SDCC точно, в Keil C51, в CCS для пиков. Проблема в том, что это капитально ломает совместимость с C и код fk0(254 знак., 04.05.2018 14:45)
- ага - Vit(04.05.2018 14:49)
- В ряде компиляторов "недо-C" для embedded включалось отключение integer promotion. Потому, что в целом это повышает эффективность кода. В SDCC точно, в Keil C51, в CCS для пиков. Проблема в том, что это капитально ломает совместимость с C и код fk0(254 знак., 04.05.2018 14:45)
- (u)int_(fast|least|)(8|16|32|64)_t - это просто синонимы типов для char/int/long/longlong, не больше и не меньше. - lloyd(04.05.2018 14:16)
- Зависит от компилятора и архитектуры. 32-битный int_fast8_t - крайне распространенная весчь, даже на x86 - LightElf(04.05.2018 15:56 - 16:50)
- Да, но не на MIPS, например, там он станет 32-битным. Ну нет у MIPS инструкций для эффективной работы с 8-битными величинами. - fk0(04.05.2018 16:25)
- Я говорю про то, что компилятору нет разницы _на_конкретной_платформе_ напишешь ли ты int32_t или int_fast8_t, если в stdint.h написано lloyd(57 знак., 04.05.2018 16:18)
- Наверно я чего-то не понял, но зачем тогда использовать типы из stdint.h? Собственно, конкретная реализация int_fast8_t может быть вообще экзотической и не совпадать ни с одним стандартным типом. - LightElf(04.05.2018 16:57)
- Эти типы _уже_ есть в языке. lloyd(247 знак., 04.05.2018 17:45)
- Можно полюбопытствовать, где явно написано, кроме префикса std в имени файла, что эти алиасы входят в состав языка, а не т.н. стандартной библиотеки? - Vit(04.05.2018 18:30)
- Можете у МЭКа купить бумажный/электронный текст стандарта языка, в свободном виде есть только будущий черновик lloyd(745 знак., 04.05.2018 18:59, ссылка)
- В этом документе на 10-м листе указано, что добавлены extended целые типы и библиотечные функции в <inttypes.h> и <stdint.h>. А в п. 6.2.5 явно перечислены стандартные целые типы. - Vit(04.05.2018 19:37)
- Стандартная библиотека входит в стандарт языка. Шах и мат! - SciFi(04.05.2018 19:40)
- Спасибо, Кэп. Сторонние (независимые) реализации не должны конфликтовать со стандартными библиотеками и хедерами. Особенно доставляет printf(), оформленный в виде макроса, а не библиотечной функции (которая как бы слабая), при этом перекрывает Vit(92 знак., 04.05.2018 20:16)
- Ежели вам попался говнокод, стандарт не виноват. Отрывайте руки и/или ноги собственно говнокодеру. - SciFi(04.05.2018 20:22)
- Тут, конечно, стандарт не виноват. Но имеем такое довольно часто - оно либо макрос(а так хотелось при тощем комплекте либ свой printf с плавучкой втиснуть), либо встроено так, что хрен его выгрызешь, но хоть можно подкрутить ретаргетинг... - Vit(04.05.2018 20:32)
- Если компилятор не заявляет поддержку С99 - то оно как бе уже ничего не сделаешь (хотя уже 7 лет как С11). lloyd(203 знак., 04.05.2018 20:37)
- Макросы как раз при ARM-GCC 4.8 и NanoLib:). Опции С99/GNU99 поддерживаются:) - Vit(04.05.2018 20:58)
- Уже GCC 7ой мажорной версии на дворе, вы где 4.8 нашли? - lloyd(04.05.2018 21:03)
- Вроде даже 5.4. А та либа зовется правильно NewLib Nano. Вопрос тут не в языке или компиляторе, а в тулчейне, и, в частности, в составе, опциях и оформлении предкомпилированных "стандартных" библиотек. Например, пока один раз пишем Hello World всё Vit(951 знак., 04.05.2018 22:08)
- Седьмой??? Да я только вчера восьмой уже ставил в дебиане. Потому как с седьмым уже не работает... (libasan4 и libc >= 2.27) О, я знаю места где 3.6 есть. А то и 3.3.3. - fk0(04.05.2018 21:29)
- Уже GCC 7ой мажорной версии на дворе, вы где 4.8 нашли? - lloyd(04.05.2018 21:03)
- Макросы как раз при ARM-GCC 4.8 и NanoLib:). Опции С99/GNU99 поддерживаются:) - Vit(04.05.2018 20:58)
- Если компилятор не заявляет поддержку С99 - то оно как бе уже ничего не сделаешь (хотя уже 7 лет как С11). lloyd(203 знак., 04.05.2018 20:37)
- Тут, конечно, стандарт не виноват. Но имеем такое довольно часто - оно либо макрос(а так хотелось при тощем комплекте либ свой printf с плавучкой втиснуть), либо встроено так, что хрен его выгрызешь, но хоть можно подкрутить ретаргетинг... - Vit(04.05.2018 20:32)
- Ежели вам попался говнокод, стандарт не виноват. Отрывайте руки и/или ноги собственно говнокодеру. - SciFi(04.05.2018 20:22)
- Спасибо, Кэп. Сторонние (независимые) реализации не должны конфликтовать со стандартными библиотеками и хедерами. Особенно доставляет printf(), оформленный в виде макроса, а не библиотечной функции (которая как бы слабая), при этом перекрывает Vit(92 знак., 04.05.2018 20:16)
- Стандартная библиотека входит в стандарт языка. Шах и мат! - SciFi(04.05.2018 19:40)
- В этом документе на 10-м листе указано, что добавлены extended целые типы и библиотечные функции в <inttypes.h> и <stdint.h>. А в п. 6.2.5 явно перечислены стандартные целые типы. - Vit(04.05.2018 19:37)
- Можете у МЭКа купить бумажный/электронный текст стандарта языка, в свободном виде есть только будущий черновик lloyd(745 знак., 04.05.2018 18:59, ссылка)
- Можно полюбопытствовать, где явно написано, кроме префикса std в имени файла, что эти алиасы входят в состав языка, а не т.н. стандартной библиотеки? - Vit(04.05.2018 18:30)
- Есть параноики, которым на 8-битном МК обязательно хочется счётчик цикла uint8_t. Теперь они могут написать там uint_fast8_t и гордо объявить это переносимым кодом. Хотя достижение сомнительное, конечно. Название типа "череззаборногузадерищенко" SciFi(4 знак., 04.05.2018 17:06)
- Эти типы _уже_ есть в языке. lloyd(247 знак., 04.05.2018 17:45)
- Наверно я чего-то не понял, но зачем тогда использовать типы из stdint.h? Собственно, конкретная реализация int_fast8_t может быть вообще экзотической и не совпадать ни с одним стандартным типом. - LightElf(04.05.2018 16:57)
- Зависит от компилятора и архитектуры. 32-битный int_fast8_t - крайне распространенная весчь, даже на x86 - LightElf(04.05.2018 15:56 - 16:50)
- Ко всем вычислениям применяется правило integer promotion. Заключающееся в расширении до размера int всех типов меньших размеров перед началом вычисления. Поэтому что uint_fast8_t, что unsigned char, если размер uint_fast8_t меньше инта, оба fk0(1190 знак., 04.05.2018 14:24)
- А что там с uint_fast8_t в логических выражениях? Есть "обрезание" до 8 бит в логических выражениях? Слыхал, что вроде как есть, но ни разу не проверял (ни разу не было явной необходимости использовать). Если есть, то получается, компилятор должен Vit(52 знак., 04.05.2018 14:10)
- stdint.h -- это не только фиксированные типы. Там есть int_fast8_t, который прекрасно получается 8-битным на PIC18, 16-битным на PIC24 и 32-битным на PIC32 (MIPS или ARM). Фиксированные типы нужны в основном, где нужно ограничить объём памяти. fk0(510 знак., 04.05.2018 13:59)