volatile uint16_t* и volatile unsigned chort*, какие-то странности в avr-gcc (WinAVR 20090313) 4.3.2 Опции

[demiurg_spb]

Код

volatile uint16_t*       p1 = &OCR3A;
volatile unsigned short* p2 = &OCR3A;

На вторую строчку получаю:
warning: initialization from incompatible pointer type

Компилятор правильно проводит различие между unsigned int и unsigned short - это разные типы.

Есть определение в stdint.h: typedef unsigned int uint16_t;

а в нашем случае (avr-gcc) int реально эквивалентен short.

Макросы в sfr_defs.h во всю используют uint16_t.

Короче где-то не стыковка, или у меня в голове или не совсем корректно объявлен uint16_t (на мой взгляд, надо его объявлять через unsigned short).
Кто рассудит?

[zltigo]

В чём прикол?

Какой прикол? Типы разные, вот и работает контроль.

[AirDevil]

Код

volatile uint16_t*       p1 = &OCR3A;
volatile unsigned short* p2 = &OCR3A;

На вторую строчку получаю:
warning: initialization from incompatible pointer type

В чём прикол?

Попробуй так:

volatile unsigned long* p2 = &OCR3A;

Сообщение отредактировал AirDevil - Jul 12 2009, 16:03

[demiurg_spb]

2 Zltigo: я понимаю, что типы разные (Вы быстро ответили на мой вопрос, пока я его пытался переформулировать его более точно)...

volatile unsigned long* p2 = &OCR3A;

А зачем пробовать? Тем более тыкать пальцем в небо? Лучше водку пробовать с борщиком
Тут вопрос не что попробовать, а почему так нестрого объявлен uint16_t?
Ведь здесь не требуется привязка к типу int, который самый нативный для большинства архитектур.
Тут требуется лишь строго лимитировать тип 16-ю битами и всё, а этого как раз и не происходит!
Не понимаю я чего-то в этой жизни...

[Сергей Борщ]

Тут требуется лишь строго лимитировать тип 16-ю битами и всё, а этого как раз и не происходит!

short лимитирован так же нестрого. Поэтому принципиальной разницы нет никакой.

[demiurg_spb]

short лимитирован так же нестрого. Поэтому принципиальной разницы нет никакой.

Интересно... Надо заглянуть в стандарт. Но как по мне, так short наиболее близок uint16_t. Уже даже не могу сказать почему, так было всегда в моей голове. Аминь

Посмотрел, там сказано: short int <= int <= long int

Ещё почитал такой документ "WG14/N1124 Committee Draft — May 6, 2005 ISO/IEC 9899:TC2"
и нашёл следующее.

Sizes of integer types <limits.h>
maximum value for an object of type unsigned short int USHRT_MAX 65535 // 2^16 − 1
maximum value for an object of type unsigned int UINT_MAX 65535 // 2^16 − 1

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

[rezident]

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

Проще использовать свои типы, переопределяя их под конкретную платформу.

[Сергей Борщ]

Проще использовать свои типы, переопределяя их под конкретную платформу.

Все уже украдено до нас (С)! stdint.h как раз и делает это, причем единообразно для любого компилятора, поддерживающего С99.

[zltigo]

Все уже украдено до нас (С)! stdint.h как раз и делает это...

Отнюдь не всегда, ибо правильные компиляторы имеют свои внутренние типы и переопределение в некоторых случаях происходит именно в них а не в типовые int и иже с ним. Проблема в том, что поведение определенных таким образом заковыристых типов ...fast..,...least... отличается умом и сообразительностью. Иногда излишней и вгоняющей у недоумение. Посему я тоже стал пользоватся только собственными типами из канонических byte,short,int....

[Сергей Борщ]

"WG14/N1124 Committee Draft — May 6, 2005 ISO/IEC 9899:TC2"
и нашёл следующее.

Ну да. " Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign"

Отнюдь не всегда, ибо правильные компиляторы имеют свои внутренние типы и переопределение в некоторых случаях происходит именно в них а не в типовые int и иже с ним.

Что лишь добавляет эффективности.

Проблема в том, что поведение определенных таким образом заковыристых типов ...fast..,...least... отличается умом и сообразительностью. Иногда излишней и вгоняющей у недоумение.

Пока нарывался на то, что тип uint_fast8_t при увеличении на 1 значения 255 получает значение 256, но, как говорится, сам себе злобный Буратина, просил не менее 8 бит, про "не более" речи не было.

Посему я тоже стал пользоватся только собственными типами из канонических byte,short,int....

Не вижу необходимости. Лишняя писанина, несовместимость со сторонними разработчиками.

[zltigo]

Что лишь добавляет эффективности.

Во многих случаях, если пользоваться более-менее бездумно, то это несомненно безмерно лучше всюду натыканных byte и прочих.... Но если прикладывать руки.... то я от них ушел.

Лишняя писанина

Пару-тройку typedef трудно назвать писаниной а потом даже короче, ибо C99 типы уж больно длинны для глаз.

, несовместимость со сторонними разработчиками.

100% совместимость - один хидер и все.

Пока нарывался на то, что тип uint_fast8_t при увеличении на 1 значения 255 получает значение 256...

А я встречал, что тот-же uint_least8_t на 32bit платформе имеет размер в зависимости от своей логики, причем соответственно тот-же эффект 255->256 при этом будет, то прояляется, то нет. Мне такие фокусы пришлись не по душе.

[Petka]

А я встречал, что тот-же uint_least8_t на 32bit платформе имеет размер в зависимости от своей логики, причем соответственно тот-же эффект 255->256 при этом будет, то прояляется, то нет. Мне такие фокусы пришлись не по душе.

Примеры в студию. Желательно с комментариями "хотел того-то, получил то и то, а в стандарте так-то".
Какие у вас собственные типы?

[rezident]

Пару-тройку typedef трудно назвать писаниной а потом даже короче, ибо C99 типы уж больно длинны для глаз.

100% совместимость - один хидер и все.

+100! Написать один заголовочный файл, который включить в файлы проекта, затраты настолько мизерные, что даже вопросов не вызывают. А при передаче проекта на другую платформу или под другой компилятор (что тоже бывает) опять же всего один хедер отредактировать нужно.

[Сергей Борщ]

А я встречал, что тот-же uint_least8_t на 32bit платформе имеет размер в зависимости от своей логики

Вот-вот. Компилятору виднее, какой тип в данном конкретном случае лучше. В следующей версии он станет еще умнее и тип может поменяться, ваш тип - нет. Во всяком случае надо будет проделать некоторую исследовательскую работу.

, причем соответственно тот-же эффект 255->256 при этом будет, то прояляется, то нет.

О том и речь. Если уж заложился на least, то при написании нельзя полагаться на какое-либо конкретное поведение 255->256, точнее эта ситуация вообще не должна возникать. Ну а если положился - сам себе Буратина, и никто другой. Если требуется конкретное поведение - нельзя использовать least или в конкретном месте делать приведение к типу фиксированной ширины.

Написать один заголовочный файл, который включить в файлы проекта, затраты настолько мизерные, что даже вопросов не вызывают.

Но зачем, если он уже написан? И для другой платформы тоже написан. Уже.

[demiurg_spb]

...правильные компиляторы имеют свои внутренние типы и переопределение в некоторых случаях происходит именно в них а не в типовые int и иже с ним.

А вот мне интересно тогда стало, что за базовый тип скрывается в таких определения?
Интересно uint16_t - будет родственником unsigned int (а не unsigned short), как в приведённом мной ранее примере.
Да и мне тоже не нравится как выглядят длинные названия типов со всякими там least и fast.
И при всё этом изобретать велосипед, придумывая свои типы, тоже не хочется.
Тупиковая ситуация однако...
Можно конечно изобрести что-то на базе stdint.h:

Код

altint.h:
//base   least    fast
u08_t   u08l_t   u08f_t
s08_t   s08l_t   s08f_t

u16_t   u16l_t   u16f_t
s16_t   s16l_t   s16f_t

u32_t   u32l_t   u32f_t
s32_t   s32l_t   s32f_t

или только переименовать все:
uintXX_least_t в uintXXl_t
uintXX_fast_t в uintXXf_t

но что-то я очкую
Предлагайте идеи!

[zltigo]

Примеры в студию. Желательно с комментариями "хотел того-то, получил то и то, а в стандарте так-то".

Хотел одно, получил другое, а в стандарте, по этому поводу ПРОСТО НИЧЕГО - все на откуп разработчикам компиляторов. Посему и пользую "свои".

Если уж заложился на least, то при написании нельзя полагаться на какое-либо конкретное поведение 255->256.....

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

[alx2]

Хотел одно, получил другое, а в стандарте, по этому поводу ПРОСТО НИЧЕГО - все на откуп разработчикам компиляторов.

Ну уж это неправда.

7.18.1.1 Exact-width integer types
1 The typedef name intN_t designates a signed integer type with width N, no padding
bits, and a two’s complement representation. Thus, int8_t denotes a signed integer
type with a width of exactly 8 bits.

7.18.1.2 Minimum-width integer types
2
The typedef name uint_leastN_t designates an unsigned integer type with a width
of at least N , such that no unsigned integer type with lesser size has at least the specified
width. Thus, uint_least16_t denotes an unsigned integer type with a width of at
least 16 bits.

Угу на это нельзя полагаться, на занимаемый размер в памяти нельзя полагаться.....

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

[zltigo]

Ну уж это неправда.

Да ну . Вы полагаете, что Вам издалека сейчас типа "виднее" .

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

Повторяю - в стандарте написано столь МАЛО и это настолько НИЧТОЖНО регламентирует поведение компиляторов, что лично меня это не очень устраивает.

В случае того же uint_least8_t можно быть уверенным, что его размер будет не меньше 8 бит....

Потрасающее "уточнение" стандарнта - неужели кто-то мог подумать, что размер такого типа будет меньше 8bit??? Нет? Так чего там такого в стандарте написано? Ничего на самом деле НИЧЕГО вразумительного кроме абсолютной банальности не написано. Посему в подавляющем большинстве случаев я предпочитаю четко выражать свои требования через менее размыто определенные для конкретной платформы типы.

[Petka]

Потрасающее "уточнение" стандарнта - неужели кто-то мог подумать, что размер такого типа будет меньше 8bit??? Нет? Так чего там такого в стандарте написано? Ничего на самом деле НИЧЕГО вразумительного кроме абсолютной банальности не написано. Посему в подавляющем большинстве случаев я предпочитаю четко выражать свои требования через менее размыто определенные для конкретной платформы типы.

Одного понять не могу: откуда такая неприязнь к с99 типам? Я вижу только одну причину - очень длинное написание.

[zltigo]

Одного понять не могу: откуда такая неприязнь к с99 типам?

Я достаточно подробно объяснял. Если это находится за пределами Вашего понимания, то.... это не мои проблемы. Кроме того, никакой неприязни нет - это много много много лучшее решение нежели использование, напимер, где ни попадя всяких byte. Просто есть еще лучшие, решения, если подумать .

[aesok]

>> В случае того же uint_least8_t можно быть уверенным, что его размер будет не меньше 8 бит....

Потрасающее "уточнение" стандарнта - неужели кто-то мог подумать, что размер такого типа будет меньше 8bit??? Нет? Так чего там такого в стандарте написано? Ничего на самом деле НИЧЕГО вразумительного кроме абсолютной банальности не написано. Посему в подавляющем большинстве случаев я предпочитаю четко выражать свои требования через менее размыто определенные для конкретной платформы типы.

Да в стандарте написана потрясающая банальность - "что размер будет uint_least16_t не меньше 16 бит" и это значит что размер этого типа может быть 16, 32, 64 бита, но не может быть 8 бит. Банальность.

Так для чего нужны типы uint_leastXX_t?, для написания переносимых програм. Например некоторые DSP не поддерживают 8-битные данные, и тип uint8_t для этого процессора не будет определен. Если надо написать программу (библиотеку) которая будет должна компилировать для процессора который поддерживае 8-битные данные и для такого который не поддерживает, и в этой пограмме нужно использовать переменную для которой известно что достаточно если ее размер 8-бит, и надо добиться макимально возможной эффективности, то эта переменая объявляеться uint_least8_t типа. Когда програма будет компилироваться для процесора без поддержки 8-битных данных то переменая будет 16-битной, а когра например для AVR то 8-битной.

Анатолий.

Сообщение отредактировал aesok - Jul 17 2009, 19:20

[Petka]

Я достаточно подробно объяснял. Если это находится за пределами Вашего понимания, то.... это не мои проблемы. Кроме того, никакой неприязни нет - это много много много лучшее решение нежели использование, например, где ни попадя всяких byte. Просто есть еще лучшие, решения, если подумать .

Никаких подробных объяснений не было. (Если я их проглядел, киньте ссылочку на них)
Если есть решения лучше, подумайте и огласите их. Мне, например, будет очень интересно.

[zltigo]

Никаких....
Если...

Перечитайте топик.

[alx2]

Да ну . Вы полагаете, что Вам издалека сейчас типа "виднее" .

По крайней мере, я с расстояния 30 см увидел. И привел цитату.

Повторяю - в стандарте написано столь МАЛО и это настолько НИЧТОЖНО регламентирует поведение компиляторов, что лично меня это не очень устраивает.

"Мало" - это уже другое дело. Это Ваша количественная оценка, и возражать я тут не буду. Я возразил на "Просто ничего".

Потрасающее "уточнение" стандарнта - неужели кто-то мог подумать, что размер такого типа будет меньше 8bit??? Нет? Так чего там такого в стандарте написано? Ничего

Во-первых, 8 бит - не единственный размер, определенный в стандарте. Есть, к примеру, int_least32_t.
Во-вторых, кроме требования "не меньше" в стандарте говорится, что это должен быть тип минимального размера, не меньшего заданного, то есть, например, тот же int_least8_t не может быть 64-битным, если существуют типы меньшего размера. По-моему, вполне существенное уточнение. Непонятно, почему Вы это игнорируете.
Если у компилятора есть 8-битный тип, то int_least8_t будет именно 8-битным и никаким другим. Если же у компилятора 8-битного целого нет (см. что написал aesok) - тогда да, int_least8_t будет иметь размер больше 8 бит, но в этом случае Вы можете сколько угодно писать свои собственные макросы, 8-битный тип у компилятора от этого не появится...

Сообщение отредактировал alx2 - Jul 20 2009, 14:09