Каморка

такая фишка
gcc-specific или все-таки standard ?

такое даже по самым вольным правилам откомпилировать трудно

Да это стандарт Х++.
Хотели псевдокодом написать

int f(int a)
{
int b = (a)? a+1: -1;
return b+1;
}

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

Я стараюсь избегать не то, что сомнительных выражений, но и вообще сложных.

Гуру, ты считаешь что это сомнительный или сложный код?
int b = (a)? a+1: -1;

2. Во время отладки я вижу промежуточные значения, а исполняемый код тот-же самый (зачастую).

А это причём? Отладчики VC++, да и Borland C++ Bulder, позволяют смотреть что угодно и когда угодно.

3. Когда смотрю на программу через некоторое время -- не надо больших усилий, чтобы понять что написано. Для меня это очень существенно.

Ну а это здесь причём? Пост-то был конкретный. b = (a)? a+1: -1;!!!
Через год забушь Кёригана энд Ричи?

PS. Да ты не сердись. Коммунист я. У нас все в Совке такие суровые.

Kроме VC и Борланда есть Keil, Cosmic, IAR, MPLAB C etc.
Во-первых в первом постинге было нечто другое чем Вы продемонстрировали,
во-вторых оператор (condition)? Х:У;
я не люблю, т.к. при пошаговой отладке я не вижу куда ответвилась программа, приходится отвлекаться на окно с параметрами, что лично мне неудобно.

Для чего нужны извращения, чтобы показать как много финтов знаешь?
Надо оставить силы и энергию на действительно интересные вещи, а формализовать мысли в виде программы надо проще!

int f(int a)
{
int b = ({ if (a) a+1; else -1; });
return b+1;
}

Вот как бы я написал:

int f(int a)
{
if (a)
return a+2;
else
return 0;
}


Кстати на одну автоматическую переменную потратил меньше. Для системы с маленьким размером памяти это может оказаться критично.
И код короче и быстрее работать будет.

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

Справка:
В real-time если не успел чуть-чуть означает полный провал.

Для чего нужны извращения, чтобы показать как много финтов знаешь?
Надо оставить силы и энергию на действительно интересные вещи, а формализовать мысли в виде программы надо проще!

int f(int a)
{
int b = ({ if (a) a+1; else -1; });
return b+1;
}

Это не финт. Это не работает.

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

Даааааааааа-с. Рекурсивный (с глубиной 10...00000) ты наш.
Впрочем, возьму слова обратно, если ты пишешь прогу для наладошников, например, для некого Win98ххх для некого BellMobbile, который умещается в заколке для некоего галстука.

Сразу говорю. Только про эффективность мне не рассказывай, т.к. (...)? всегда компилировался в более быстрый код, чем if (...). Так говорят проотцы. Сам я ассемблер не знаю.

vg писал(а):Сам я ассемблер не знаю.

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

Я написал FSK модем 1200/2200 на следующей системе:
8 бит
1 MHz
23 байта RAM
1.5 килобайт программа (это параметр системы, реально программа гораздо меньше)

vg писал(а):Сразу говорю. Только про эффективность мне не рассказывай, т.к. (...)? всегда компилировался в более быстрый код, чем if (...).

Неужели лень подумать, чтобы не говорить того, что не соответствует действительности?

Строго говоря ()? или if, один и тот же условный переход. Правильно, Akrav, высказывание vg не соответствует действительности.

У многих современных процессоров условный переход прерывает конвейерную обработку вычислений. Бывает, это актуально для какой-нить поточной компрессии или вроде того.

Один из любимых тестов MS, что они задают кандидатам у них работать: написать код для деления числа на число, без условного перехода (явного или неявного), что в состоянии избегать ошибку деления на ноль.

глюк

Один гуру и другой гуру. Я постил, что не знаю ассемблер. Вам, если вы на самом деле одна сплошная крутость (т.е. ассемблер и т.д), -виднее. Не буду спорить о чём не знаю. Что до "процессорной обработки" в прикладной проге для "побазёнок" (это про твой пост, Woozy), то мне на это глубоко наплевать. Если ещё и про это задумываться, делая реальную прикладную прогу, то до конца проекта не доедешь. Хотя, конечно извращенцам или за хорошие бабки можно и на ассемблере пальцы шлифовать об клаву.

to Akrav

А я знаю ассемблер.

А я знаю бывших ассемберщиков в России, которые не могут здесь найти работу. У нас программируют на Delphi. Это не так престижно, как на ассемблере, но приложения делаются быстро, да и бабки хорошие. Так, что переходи на Delphi. Как выучишь, приезжай.
Шучу.

vg писал(а): если вы на самом деле одна сплошная крутость (т.е. ассемблер и т.д), -виднее.

Программисты (бывает, и люди, ) часто интересуются тем, что выходит за пределы их повседневной работы.

Кроме знания Делфи надо еще быть внимательным и читать, что пишут другие. Иначе реакция получается неадекватной. Если прочитано начало фразы, то не надо отгадывать что будет в конце и прекращать читать. Нужно просто дочитать фразу до конца.
Вот например один из проектов с моим значительным вкладом (в т.ч. и на ассемблере)
http://www.lauderdalebmw.com/ps/celphone.html

куда мне засунуть Дельфи?
Господа офицеры - молчать!