srggal wrote:
>
> K>>Главный момент — за неответ не штрафуем.
>
> D>Полёт фантазии здесь будет только у тех людей, которые не знают, что
> приведённый пример — бредовый.
> D>Главный момент — отсеиваются грамотные.
>
> -1
> Грамотные не отсеятся, а вот полета фантазии я тут не вижу

Человек в принципе может сам дойти до идеи, что вместо блока
почти везде можно поставить один единственный оператор. Через
наводящие вопросы и сравнения с if-ами. С этим вопросом
можно вытянуть человека на уровень, когда можно пустить
на c++, если формально по вопросам ему надо еще C учить.

Mikhail

igna wrote:
>
> Правда? А вот такое:
>
> #include <iostream>
> int main()
> {
> switch(0) ;
> };
>
> — компилироваться не должно?

Как оказалось, может и не собираться. Но не из-за свича,
а из-за заголовка.

Mikhail

ааа, т.е. вы faq вчера только прочитали?

Dimentiy wrote:
>
> K>Если человек понимает, что пример бредовый, но не может
> K>ничего предположить, и тем более если не хочет, то этот
> K>человек, скорее всего, неадекватен.
>
> Неадекватен тот, кто будет копаться в бреде.

Если задача поставлена именно таким образом, и он не
копается, то человек слишком заморочен. Кто знает,
когда еще и какой кусок работы он посчитает бредом,
так что все в итоге застрянет ?

Mikhail

Lorenzo_LAMAS wrote:
>
> ааа, т.е. вы faq вчера только прочитали?

Ну да.

Мой пойнт, что знать все это можно и книги
читать надо. А не то что я такой гениальный
мол и все знаю сам. Если бы.

А к ревьюерам, которые знание всего этого
требуют и ожидают в обязательном порядке,
у нас отношение скорее всего одинаковое.

Mikhail

Здравствуйте, Dimentiy, Вы писали:

D>Здравствуйте, kittown, Вы писали:

K>>Если человек понимает, что пример бредовый, но не может
K>>ничего предположить, и тем более если не хочет, то этот
K>>человек, скорее всего, неадекватен.

D>Неадекватен тот, кто будет копаться в бреде.

Блин, Хоуливарз.

Я копаюсь в бреде, мне кроме этого, ещё и деньги за это платят, и называют это красивыми словами РеИнжиниринг, Импрувмент, Саппорт.

ИМХО Не нужно все обобщать, и уж тем более усугублять такими мощными высказываниями.

ЗЫ
Думаю таких неадекватных немало, взять например вот Прокоментируйте код

Автор: Tom
Дата: 30.11.05

.

Здравствуйте, Андрей Коростелев, Вы писали:

АК>Хм, а какой конструктивный вывод можно сделать о разнице между студентами,
АК>справившимися с этим заданием и не справившимися?

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

Здравствуйте, srggal, Вы писали:

S>Я копаюсь в бреде, мне кроме этого, ещё и деньги за это платят, и называют это красивыми словами РеИнжиниринг, Импрувмент, Саппорт.

Здравствуйте, RomanOdaisky, Вы писали:

K>>Дык,UB. Множественная модификация переменной между точками следования.
K>>Угадал?

RO>На этот раз нет. Assignment operators имеют левую ассоциативность (или, наоборот, правую?). Т. е. они сперва вычисляют то, что справа, затем то, что слева, затем вызывается operator =(). Да и, ЕМНИП, операторы присваивания как раз создают ТС.

А вот на этот раз не угадал ты
Ассоциативность (фактически, правила расстановки скобок) не влияет на порядок вычисления независимых аргументов (в том числе — взятие ссылки "куда"), а присваивание не создаёт точки следования.

Здравствуйте, korzhik, Вы писали:

RO>>x ^= y ^= x ^= y;

RO>>Что делает?
K>меняет значения x и y

Не "меняет" а "пытается обменять". Ещё неизвестно, что оптимизирующий компилятор про эту конструкцию подумает (а подумать он может всё что угодно — UB развязывает ему руки).

Здравствуйте, Глеб Алексеев, Вы писали:

_>>но во время пузырька вам нужно будет обменять 2 ячейки памяти? это нетривиально без 3-й ячейки. Вот и требуется найти рещение как обойтись без этой дополнительной ячейки.

ГА>ИМХО, маразм.
ГА>Если временную переменную при перестановке элементов считать дополнительной памятью, то что делать со счетчиками циклов? Хотелось бы на код успешного кандидата взглянуть.

Хм... а ведь, между прочим, решение есть. Только оно ВЕСЬМА нетривиальное.
И помоему, уже было в Этюдах.

Причём можно действовать без UB в обмене (ну, это достигается элементарно: распишем арифметику на три отдельных операции).

Здравствуйте, Вадим Никулин, Вы писали:

RO>>У кого-то из нас глюки. ГДЕ UB? Приведите, пожалуйста, 2 или больше противоречащих варианта вычисления (по шагам).

ВН>UB в том, что между изменениями, например, переменной y нет точек следования.

Следует ли понимать, что

a = b = c = 0;

— тоже UB, поскольку может быть, помимо обычного понимания, записано в виде

((a = b) = c) = 0;

, что эквивалентно

a = 0;

для тривиального operator =(...)?

Я посмотрел 5.17p1, там написано group right-to-left. Определение последнего термина я не нашел, но оно "на пальцах" разъясняется в 5.9p1.

Здравствуйте, korzhik, Вы писали:

АШ>>

АШ>>x ^= y; y ^= x; x ^= y;
АШ>>

K>Насколько я понимаю в общем случае работает только для unsigned ?

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

x = x (+) y
y = y (-) x // y = y (+) x (-) y
x = x (-) y // x = x (+) y (-) x

Здравствуйте, ekamaloff, Вы писали:

ШР>>

ШР>>    a += b;

ШР>>    b = a - b;

ШР>>    a = a - b;

E>Однако может привести к переполнению.

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

E>ЗЫ: задавали этот вопрос на одном из собеседований... За минуту допер (ответа ессно не знал).

А какой правильный ответ?
Вот что нашёл в С99:

6.2.6.2 Integer types

1 For unsigned integer types other than unsigned char, the bits of the object
representation shall be divided into two groups: value bits and padding bits (there need
not be any of the latter). If there are N value bits, each bit shall represent a different
power of 2 between 1 and 2N-1, so that objects of that type shall be capable of
representing values from 0 to 2N — 1 using a pure binary representation; this shall be
known as the value representation. The values of any padding bits are unspecified.44)

44) Some combinations of padding bits might generate trap representations, for example, if one padding
bit is a parity bit. Regardless, no arithmetic operation on valid values can generate a trap
representation other than as part of an exceptional condition such as an overflow, and this cannot occur
with unsigned types. All other combinations of padding bits are alternative object representations of
the value specified by the value bits.

Здравствуйте, Roman Odaisky, Вы писали:

ВН>>UB в том, что между изменениями, например, переменной y нет точек следования.
RO>Следует ли понимать, что

RO>a = b = c = 0;

— тоже UB, поскольку может быть, помимо обычного понимания, записано в виде

RO>((a = b) = c) = 0;

, что эквивалентно

RO>a = 0;

для тривиального operator =(...)?

RO>Я посмотрел 5.17p1, там написано group right-to-left. Определение последнего термина я не нашел, но оно "на пальцах" разъясняется в 5.9p1.

Ну ёлки палки, сколько ещё программистов расшибёт лоб, чтобы понять: operator precedence и associativity управляют лишь расстановкой скобок — и больше вообще ничем?

a=b=c=d всегда трактуется как a=(b=(c=(d))).

Поскольку операторы встроенные, то между вычислением аргументов и входом в функцию operator=(), и между выходом из функции и передачей результата дальше — точек следования нет. Собственно, и функций-то здесь нет.
Это развязывает оптимизирующему компилятору руки — он может превратить это выражение в a=d, b=d, c=d.

Теперь меняем = на +=: a+=(b+=(c+=(d)))
Очевидно, что c1=c0+d, b1=b0+c0+d, a1=a0+b0+c0+d или a1=a0+b1 или a1=a0+b0+c1 где a0,b0,c0 — исходные значения, a1,b1,c1 — конечные значения одних и тех же переменных a,b,c. Где компилятор хранит значения, используемые в выражении — то ли в регистрах, то ли сразу в переменных — никто не знает. Где хочет, там и хранит. И порядок выполнения тоже на усмотрение компилятора.

Теперь делаем невинный фокус: a+=(b+=(c+=(b)))
Подставляем b вместо d. Получаем (в произвольном порядке, заметьте!!!)
c1=c0+bx,
b1=b0+c0+bx
a1=a0+b0+c0+bx или a0+b1 или a0+b0+c1
где bx — содержимое переменной b в произвольный момент времени до конца вычислений.
В результате — имеем всё что угодно.

Думаете, компилятор такой умный, он увидит? Агащас

void ub(int& a, int& b, int& c, int& d) { a+=b+=c+=d; } // ну здесь-то, казалось бы, нет неоднозначностей?..
int main()
{
  int a=1,b=2,c=3;
  ub(a,b,c,b); // будут!
}

Да если компилятор и увидит неоднозначности — он скорее туда заглушек навтыкает, чем попытается родить правильный код. Какая разница: ранняя диагностика UB, всего-то навсего.

Здравствуйте, Кодт, Вы писали:

ГА>>Если временную переменную при перестановке элементов считать дополнительной памятью, то что делать со счетчиками циклов? Хотелось бы на код успешного кандидата взглянуть.
К>Хм... а ведь, между прочим, решение есть. Только оно ВЕСЬМА нетривиальное.
К>И помоему, уже было в Этюдах.
Знание что двойной xor возвращает то же значение нетривиально? Ну не знаю. Когда мне впервые задали такой вопрос, я сразу догадался на чем основана.

a^=b;
b=a^b;
a^=b;

Хотя всякое бывает.
С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Знание что двойной xor возвращает то же значение нетривиально? Ну не знаю.
Это-то понятно. Массив отсортируй без дополнительной памяти (под счётчик)

Здравствуйте, Кодт, Вы писали:

К>В результате — имеем всё что угодно.

Пожалуй, вы правы... У меня вообще в последнее время складывается впечатление, что программы нужно писать так, чтобы на один оператор приходилось ровно одно действие. Дело-то нехитрое, а N-ная часть багов исчезнет (точнее, так и не будет творчески создана).

Здравствуйте, Кодт, Вы писали:

ГА>>ИМХО, маразм.
ГА>>Если временную переменную при перестановке элементов считать дополнительной памятью, то что делать со счетчиками циклов? Хотелось бы на код успешного кандидата взглянуть.

К>Хм... а ведь, между прочим, решение есть. Только оно ВЕСЬМА нетривиальное.
К>И помоему, уже было в Этюдах.
В этюдах не нашел. И т.к. pavel_turbin с помощью этого теста "отсеивает слабоумных", сомневаюсь, что именно это решение требовалось. Все-таки обычно под отказом от дополнительной памяти при сортировке понимают сортировку массива на месте, а не фокусы без локальных переменных.

К>Причём можно действовать без UB в обмене (ну, это достигается элементарно: распишем арифметику на три отдельных операции).
Это понятно. Самое интересное — это действительно реализовать сортировку без счетчиков циклов. Но для этого этюда надо точнее оговорить условия. Если подойти формально и считать, что "дополнительная память"=="локальные переменные", то можно просто заменить итерацию рекурсией, только в действительности в стеке памяти это съест больше (разве что все рекурсивные вызовы будут концевыми, до такого варианта я еще не додумался, и если компиляторы оптимизируют хвостовую рекурсию). А если считать, что функция принимает (int* array, size_t n), и ничего сверх этого ни в стеке, ни в куче использовать нельзя, то я даже не знаю. Видимо, слабоумный .

Здравствуйте, korzhik, Вы писали:

K>

K>Если же это определение функции, располагающееся за пределами определения класса, то ставить точку с запятой после такого определения явно запрещено стандартом языка. Для этого надо внимательно рассмотреть фрагмент грамматики в пункте 7/1 и обязательно прочитать пункт 7/3.

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

А ещё вопрос такй у меня возник. Если это таки запрещенно, то зачем коммитету такой запрет понадобился? У кого-нибудь есть идеи мотивации такого запрета?