Тернарный оператор не для присваивания

отрицательно.

Если он односложный, почему бы и нет. Если каша из:

(some ()) ? (some_1()) ? ++a : ++b : (some_2()) ? --a : --b;

То в жопу такой Perl.

http://www.ioccc.org/2013/dlowe/dlowe.c

То в жопу такой Perl.

гениальная фраза.

Дурацкие операторы пост-,пре-инкремента имеют смысл если у тебя что вроде http://en.wikibooks.org/wiki/68000_Assembly#Indirect_addressing_with_postincr... например. А если у тебя х86 то они нахер не нужны. Не используй их вообще, кроме случаев, когда они перегружены как в дурацких стл итераторах.

Это как пример. Допустим, может быть вызов одного из методов.

И чем же они дурацкие?

Да, а ещё не нужно использовить if/else, как написано в соседнем треде =).

Ориентируюсь на читаемость кода.

someConditionChecked()
   ? doSomething()
   : doSomethingElse();

Вполне себе.

Как вы относитесь вот к такому

Так пишут только мудаки.

Профита, кроме усложнения читабельности, такая запись не принесет.

Считаешь, что лучше:

if (some())
{
    ++a;
}
else
{
    ++b;
}

?

Вкусовщина, но если нет затребованного code style'a, я пишу:

if (some())
    ++a;
else
    ++b;

++*(&a+(&b-&a)*!!some())

но «лучше»

(some()?a:b)+=1

а если уже не компиляеться то

++*(some()?&a:&b)

зы.http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html 3.0 values and Lvalues

update:

++*(&b-(&b-&a)*!!some())

А вот этого я не говорил. Не надо присваивать мне свой бред.

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

А это не мой бред. Это из темы про паттерны.

++*(&a+(&b-&a)*!some())

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

Выражение с побочными эффектами - вообще не лучшая идея.

Дурацкие операторы пост-,пре-инкремента

операторы в порядке. это с людьми что-то не то.

++*(&a+(&b-&a)*!some())

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

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

ну и бред же. инкремент даже набирать быстрее просто. иначе, если продолжить твою мысль и не останавливаться на полпути, то и += надо назвать «дурацким».

++*(some()?&a:&b)

самый рабочий вариант из тех, что ты предолжил. но стоит ли его использовать вместо ифа, лично я не убеждён.

определение языка более строгое и обещающее ub(или ещё чё похуже) чем реализации

тем более сегменты ща не в фаворе ( доступные прогеру) есть плоская память аля x86-64 тератерабайт.

поэтому разность на битах (а адресе пока это всёж равнодлинные битовые последовательности)

ну и да для симметрии и меньшей затратности видимо так :

++*(&a^(&a^&b)*!some())

ну и меньше путаницы ибо ^ взаимообратна в отличии от +-

пока из си не пытались стандартизировать

вроде(судя по археологии) можно было компилять

++(u?var1:var2)

ибо если

++arr[u?i1:i2] можно то и .

из совсем свежего:

$key_is_num 
  ? @$aref[$mid] >  $key ? $high = $mid - 1 : ($low = $mid + 1) 
  : @$aref[$mid] gt $key ? $high = $mid - 1 : ($low = $mid + 1);

поэтому разность на битах (а адресе пока это всёж равнодлинные битовые последовательности)

для них определены операции: ptr-ptr и ptr+-size_t. преобразование в целые числа уже частность и в стандартне не определена. ptr-ptr определно только для случая, когда это указатели из одного массива. в частном случае, когда эти указатели в одной плоской модели. когда компилятор видит, что программист написал UB, он вправе генерировать такую несусветную херню... оно тебе надо?

из совсем свежего:

ой. оно работает? оберни первый = в скобки хотя бы.

@$aref[$mid] >  $key ? ($high = $mid - 1) : ($low = $mid + 1) 

так хотя бы я буду видеть, что код рабочий.

Поржал.
Пости на говнокод, пусь другие тоже поржут.

@$aref[$mid] >  $key

хотя тут мне уже не очевидно о чём думал программист в этом сравнении и не ошибся ли он...

Пости на говнокод, пусь другие тоже поржут.

плакать надо...

из совсем свежего

не пиши так лучше. сделаешь меньше ошибок.

как бы ты написал?

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

if (some()) {
    ++a;
} else {
    ++b;
}

а до этого еще такой код:

return $mid if $is_num ? @$aref[$mid] == $key : @$aref[$mid] eq $key;

хотя тут мне уже не очевидно о чём думал программист в этом сравнении

что именно? если key строка - сравниваем как строку, иначе как число.

велик и могуч рус^Wси.

ошибок бояться - в perl не ходить :)

я бы просто в каждый момент времени знал, num у меня в переменной или не num

Набирать быстрее и просто, когда осилил дворак. Запомни это. А по поводу „бреда“ - Полиграф Полиграфыч тоже был не согласен с обоими, да.

т.е. решения ты не предлагаешь, но зато «говнокод, говнокод» :-D

не нужно прятать машину слишком сильно.

(использовать слишком частные частности тож опасно)

ну и деленда ест http://www.youtube.com/watch?v=-n8FP7Ncq8A

не нужно прятать машину слишком сильно.

да блин. я помню «детство» и far указатели.

т.е. решения ты не предлагаешь

Решения чего? Того, что ты не знаешь, интегер у тебя в переменной или строка? А может там указатель? Или того, что та нелепость, на которой ты это пишешь, не умеет имплиситную конвертацию строк в интегеры (это при условии, что в строке 100% число, на что я бы, смотря на этот код, полагаться не стал).

что именно?

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

$arr->[$mid] == $key

а что ты написал я так сразу не смогу сказать как распарсилось, поскольку приведение $arr к массиву через @$arr я понимаю в простых случаях, когда нет других модифицирующих смысл выражений. ну и по хорошему эти случаи не надо нагромождать в одно выражение, если можно потерять нить.

я бы просто в каждый момент времени знал, num у меня в переменной или не num

он похоже пишет какую то «библиотечную» функцию типа сортировки непонятно чего.

Скобки пишу, если предполагается больше одного statement'а.

// P.S. пишу из специального котла :)

far указатели это ересь конкретной платформы

а уж наличие equal при !eq :)