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

LMA>>Ну хорошо, а то я уж боялся, что и
LMA>>

LMA>>a += b += c;
LMA>>

LMA>>тебе не понравится.

E>И не зря боялся. Так писать НЕ НАДО!
Ну я же не зря смайлик поставил!

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

LMA>>

LMA>>p, (q ? p, q : q, q)
LMA>>

LMA>>Просто вторым и третьим аргументом оператора "?:" являются выражения, а не значения — что я уже писал выше.

E>Какие проблемы? Подставь вместо p и q какие-нибудь выражения
Дык там и так выражения!

LMA>>Я уже написал, что приоритетов там нет. Если что-то явно не вводится в стандарте, то это значит, что этого в том, о чем стандарт, нет?
E>Ну в целом да.
В целом — это в том смысле, что пока тебе удобно придерживаться этой точки зрения?

LMA>>Там и "оператора for" нет, о котором ты писал:
E>>>>Обычно этот список состоит из лдного пункта -- третьей части оператора for...
E>Это особенности переводной терминологии. Всего лишь. Правда я забыл, что ты по-русски и по-английски изъясняешься ещё хуже, чем на С++. Извини...
Слив защитан.

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

E>>Приведи, пожалуйста, пример, когда оператор "запятая" в этом месте уместна...
E>>При этом именно оператор "запятая", а не декларация нескольких переменных через запятую...
LMA>Захват ресурса + декларация переменной цикла
Пример кода, пожалуйста...

E>>В чём продлема? Убеди своего начальника в целесообразности использования запятой и используй
LMA>Да у тебя отношение к программистам — просто как к лохам последним! Откуда такое недоверие?
Нет. Просто это часть грамотного управления разработкой. Любое отступление от "простого понятного кода" стоит дополнительных затрат по управлению разработкой и по поддержке. Соответсвенно, если принимается решение о целесообразности такого удороджания, то должны быть приведены внятные аргументы. Как раз инициатор аргументирует, начальник сопротивляется. Если решение верное, то убедит, если нет, то и к лучшему оно...

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

LMA>Слив защитан.
Не, ну если у тебя аргументы таки закончились...
Мне-то казалось, что тебя С++ интересует, а не сливы.

Здравствуйте, Erop, Вы писали:
LMA>>Тратить больше своего времени на никому не нужные вещи... комментировать каждый чих... чтобы обычные программисты тонули в море ненужных им комментариев при просмотре моего кода... понятно... IMHO, вот это и есть саботаж.

E>Нет, писать ненужные комментарии на каждый чих тоже плохо. Программировать надо так, чтобы программа была и так ясна, без комментариев.
E>А вот нетривиальные места надо комментировать. Ещё крайне полезно комментировать семантику методов полей и функций, если она не очевидна из их названий...
Так в том то и проблема, что тривиальность по-разному все понимают!

E>Таки в чём твоя цель? Помочь твоему клиенту или наоборот отомстить?
Моя цель — соблюсти свои интересы, а именно — работать продуктивно, вместо того, чтобы обучать отдельных представителей заказчика.

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

E>Я бы вообще сказал, что использовать результат оператора присваивания нужно только в том случае, если это действительно зачем-то нужно. И то сначала крепко подумать как бы этого избежать...
С фомулировкой "использовать x нужно только в том случае, если это действительно зачем-то нужно." вообще трудно не согласиться.
Не понятно только — зачем пытаться избегать тех конструкций, которые хороши всем, кроме того, что кто-то ВОЗМОЖНО их не поймет?

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

LMA>Моя цель — соблюсти свои интересы, а именно — работать продуктивно, вместо того, чтобы обучать отдельных представителей заказчика.
После твоей "сливы" дальнейшее обсуждение не имеет смысла. IMHO ты плохо понимаешьчто такое "продуктивность"

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

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

LMA>>>

LMA>>>p, (q ? p, q : q, q)
LMA>>>

LMA>>>Просто вторым и третьим аргументом оператора "?:" являются выражения, а не значения — что я уже писал выше.
вообщето и значениями и выражениями delete выражение типа void а new типа указатель поэтому

1? delete x:new int;

распарсится нормально, но отбракуется по несовместимым значениям

Здесь собственно особенность того что оператор торйной поэтому от ? идет к : и поскольку запятая меньший приоритет то всеже так

p, (q ? (p, q ): q), q

вариант ответа ошибка, вобщем тоже правдоподобно

P>Здравствуйте, LordMAD, Вы писали:
кстати простая арифметика не имеет приретив поскольку есть унарный плюс и минус

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

E>Вот, ещё придумалось...

void foo()
E>{
E>    typedef std::string Strings[5];
E>    delete new Strings;
E>}

всё ли тут хорошо?
ну какбы это... не является массив типом таким как все. delete [] думаю нужно

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

E>Я бы вообще сказал, что использовать результат оператора присваивания нужно только в том случае, если это действительно зачем-то нужно. И то сначала крепко подумать как бы этого избежать...

И на это правило есть исключение:

int a,b,c,d,e,f;
...
a = b = c = d = e = f = 0;

Но вытворять такое же с "+=" я бы не стал.

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

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

E>>Я бы вообще сказал, что использовать результат оператора присваивания нужно только в том случае, если это действительно зачем-то нужно. И то сначала крепко подумать как бы этого избежать...
Ну это примеры VB-like а ежели вместо b l-value типа ::->[]() то а=б=с и += весьма полезны

CC>И на это правило есть исключение:
CC>

CC>int a,b,c,d,e,f;
CC>...
CC>a = b = c = d = e = f = 0;
CC>

CC>Но вытворять такое же с "+=" я бы не стал.

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

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

S>>А без этих ассертов в начале функций не прожить? Я обычно их пишу если реально надо проверить что-то сложное, а тривиальных методов зачем их писать
LMA>Это общепринятый и довольно удобный способ выразить мысль. Позволяет при последовательном просмотре кода видя только тело функции понять правильно ли она написана. Ставший уже классическим пример с функцией нахождения среднего двух целых чисел о чем-то говорит?

Зачем писать ассерты в каждой функуци? Каждая задача ограничена в ресурсах (время и внимамние).
На написание безполезных ассертов в тривиальных это уходит время и несколько отвлекаешься от поставленной задачи. Лучше это время затратить на написание комментариев и написание еще одного или больше Unit теста.


S>>

S>>a = 3;
S>>b = 4;

S>>assert( a < b ); // зачем?!

S>>void foo( int a, int b )
S>>{
S>>    assert( a < b ); // в принципе можно, но лучше по другому
S>>}

S>>error_cd foo( int a, int b )
S>>{
    
S>>    if( ! (a < b) )
S>>       return assert(0), invalid_parameter;
S>>}


S>>

LMA>К чему эти три примера плохого кода?

чем же они плохи?

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

LMA>>Захват ресурса + декларация переменной цикла
E>Пример кода, пожалуйста...
Сначала объясни — зачем? Что тебе это даст? Декларация нескольких переменных разных типов — дальше что?

LMA>>Да у тебя отношение к программистам — просто как к лохам последним! Откуда такое недоверие?
E>Нет. Просто это часть грамотного управления разработкой.
Увеличение затрат, вызванное лишними действиями — это грамотное управление разработкой?
Фразы вида "мы всегда все делаем по стандарту", "вы всегда делаем правильно", "мы успешно продаем свои продукты" на самом деле означают всего-лишь "мы всегда так делаем".

E>Любое отступление от "простого понятного кода" стоит дополнительных затрат по управлению разработкой и по поддержке.
С этим никто и не спорит, вопрос опять же в том, что "простой понятный код" — это СУБЪЕКТИВНО.

E>Соответсвенно, если принимается решение о целесообразности такого удороджания, то должны быть приведены внятные аргументы.
Удорожание происходит тогда, когда вместо низкооплачиваемого программиста берут высокооплачиваемого. А если имеется высокооплачиваемый — никакого удорожания нет.

E>Как раз инициатор аргументирует, начальник сопротивляется. Если решение верное, то убедит, если нет, то и к лучшему оно...
Начальник — менеджер, он в этом понимать ничего не должен — у него совсем другие заботы, и это правильно. Программист имеет право на презумпцию вменяемости: он пишет код как считает нужным, качество этого кода видно из code review.

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

E>Не, ну если у тебя аргументы таки закончились...
E>Мне-то казалось, что тебя С++ интересует, а не сливы.
Ну давай обсудим твои "особенности переводной терминологии", которые заставили тебя слово statement перевести как ОПЕРАТОР, при том, что для языка C++ слово operator уже занято.

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

LMA>>Моя цель — соблюсти свои интересы, а именно — работать продуктивно, вместо того, чтобы обучать отдельных представителей заказчика.
E>После твоей "сливы" дальнейшее обсуждение не имеет смысла. IMHO ты плохо понимаешьчто такое "продуктивность"
Для меня это эффективное создание хорошо поддерживаемого, производительного и т.д. кода. Так что я упустил?

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

LMA>>>>Просто вторым и третьим аргументом оператора "?:" являются выражения, а не значения — что я уже писал выше.
P>вообщето и значениями и выражениями delete выражение типа void а new типа указатель поэтому
P>

P>1? delete x:new int;
P>

P>распарсится нормально, но отбракуется по несовместимым значениям
Какое отношение то, что написали Вы, имеет к тому, что написал я?

P>Здесь собственно особенность того что оператор торйной поэтому от ? идет к : и поскольку запятая меньший приоритет то всеже так

P>p, (q ? (p, q ): q), q

P>вариант ответа ошибка, вобщем тоже правдоподобно
Что Вы хотели этим сказать?

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

P>кстати простая арифметика не имеет приретив поскольку есть унарный плюс и минус
Вы понимаете, надеюсь, что вычитание и смена знака — это разные операции?

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

S>Зачем писать ассерты в каждой функуци? Каждая задача ограничена в ресурсах (время и внимамние).
В каждой — не за чем.

S>На написание безполезных ассертов в тривиальных это уходит время и несколько отвлекаешься от поставленной задачи.
Безполезных assert'ов писать не надо. assert(true); — это не безполезный assert, это способ документирования. Или Вы не понимаете зачем документировать свой код?

S>Лучше это время затратить на написание комментариев
Потому что "assert(true);" — писать быстрее и это понятнее, чем "// no preconditions".

S>и написание еще одного или больше Unit теста.
unit-тесты — это не панацея, они тем полезнее, чем менее квалифицированные люди пишут код. В ряде случаев они почти бесполезны. Скорее всего, на написание качественного unit-теста уйдет существенно больше времени, чем на грамотное внесение assert'ов.

S>>>

S>>>a = 3;
S>>>b = 4;

S>>>assert( a < b ); // зачем?!

S>>>void foo( int a, int b )
S>>>{
S>>>    assert( a < b ); // в принципе можно, но лучше по другому
S>>>}

S>>>error_cd foo( int a, int b )
S>>>{
    
S>>>    if( ! (a < b) )
S>>>       return assert(0), invalid_parameter;
S>>>}


S>>>

LMA>>К чему эти три примера плохого кода?

S>чем же они плохи?
Первые два assert'а вообще не нужны, третий пример вообще никуда не годится — это нужно переписывать.

Здравствуйте, Аноним, Вы писали:
...
А>Определенно, LordMAD впечатления опытного профессионала не производит, скорее всего просто подросток с комплексами.
А>Крайне мала вероятность, что он действительно участвует в коммерческих проектах, в виду отсутствия минимальных коммуникативных навыков и мании величия.
Ну так "безумный" в нике не зря