C type casting

[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++ программистов во всей красе!

[DVK]

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

А вы сами-то чьих будете?

[M. Ridcully]

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

А вы сами-то чьих будете?

Я по принуждению - меня деньгами принуждают на C++ кодить!
А в душе я совсем, совсем другой.

[DVK]

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

А вы сами-то чьих будете?

Я по принуждению - меня деньгами принуждают на C++ кодить!
А в душе я совсем, совсем другой.

Значит либо мало платят плохо принуждают, либо сравнительно недавно стали принуждать... У настоящих C/C++ погромистов буквоедство - профессиональная деформация...

[M. Ridcully]

Значит либо мало платят плохо принуждают, либо сравнительно недавно стали принуждать...

Да давненько уже - скоро лет 20 как...
Но платят мало, очень мало. Я вам чиркану email моего начальника, вы ему тоже об этом напишите, ок?

[DVK]

Значит либо мало платят плохо принуждают, либо сравнительно недавно стали принуждать...

Да давненько уже - скоро лет 20 как...
Но платят мало, очень мало.

Молодой ещё. Не расстраивайтесь - все ещё в переди!!!

Я вам чиркану email моего начальника, вы ему тоже об этом напишите, ок?

Конечно, давайте. Если ещё чего надо, вы не стесняйтесь, спрашивайте.