точно не помню но нарывался уже на непонимание анонимного union, и вроде как даже не в одном месте. И это был С без плюсов.
zltigo: вам виднее,и спорить не хочется. мне лично две длинные переменные вместо одной короткой - лишняя сущность (по оккаму).
Тем не менее хочется отметить что вы везунчик - у вас есть выбор как минимум из 3х подходов реализации задачи

Но разве безымянные объединения не являются фичей исключительно C++?

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

только с безымянными объединениями нужно в любом случае быть очень аккуратными...

И раз уж зашла речь о безымянных обединениях и структурах, вот такой пример:
Чему будут равны A,B,C в конце main ?

Для начала эта мусорная структура не должна откомпилироваться.

во-первых многие компиляторы сожрут и не подавятся... я пробовал.
хотя согласен что я слегка перестарался...

а что скажут компиляторы на вот такую структуру:
?
только попробуйте сначала реально скомпилить прежде чем говорить что не скомпилит.

1. Multiple declaration for 'b'
2. "b" has already been declared in the current scope
3. Duplicate name 'b' not allowed in struct or union
Что было видно и без попыток скомпилировать сие тремя компиляторами. Начиная с самого древнего и кривого BCC.

 

живодеры!!
вот увидете - перестанет компилятор вам компилить вообще после этого - пожалеете

вот это:

VisualStudio 2005 прожевывает не поперхнувшись...

Ну фиг с ней - у меня по любому такое написать не получится. Хотя иногда достаточно, на первый взгляд, запутанные union-ы пишу.



Комментариии, правда,удалены .

Это просто было в качестве примера что неименнованные структуры и объединения нужно очень осторожно применять, можно случайно нарваться...

Структурки у Вас веселые...

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

А ты не пробовал объявлять ее вообще без volatile? Вообще-то это требуется крайне редко, например, в подобном коде:

int n = 10;
while(n--)
{}

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

Шикарный совет. "Как, вы еще не получали граблями в этом месте? Вот вам! " Вообще-то это требуется всегда, когда переменная изменяется неизвестным компилятору образом, например в прерывании, другом потоке или аппаратно отражает состояние внешних по отношению к ядру устройств. Зато _вы_ можете сделать предположение за компилятор. . Может он. Чтобы не мог - существует volatile. Если в конкретном случае без volatile вдруг не сделал, то при малейшем изменении исходника или версии компилятора сможет сделать и вот вам граблями в лоб - получите. Даже если чтения разнесены в разные функции и файлы - все больше компиляторов поддерживают многофайловую компиляцию. Хотите приключений - делайте, но не советуйте этого другим. Это примерно как "лазил я однажды в телевизор и нифига меня током не ударило. Так что незачем при ремонте его отключать от сети".

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

Без volatile цикл while просто повиснет, так как new_value просто не будет считываться - компилер, будучи уверенным, что она не изменяется (нет присваивания), выкинул операцию считывания из кода...