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

RO>Во-первых, он бывает нужен в for.
редко, но +1
RO>Во-вторых, это единственное выражение, позволяющее из потенциально-void-выражения сделать гарантированно-не-void. Применяется в SFINAE. Например:
Как часто это требуется в общем коде?

CC>>2) Объясните, почему оператор запятая лучше вообще не применять.
Не совсем верно выразился, согласен. Смысл был что применять строго там, где иначе никак.

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

LMA>>А никакого припятствования! Речь идет лишь о том, что люди должны иметь определенный уровень квалификации.
E>IMHO это дело менеджера или владельца кода, выяснять какая у кого должна быть квалификация. Действия с твоей стороны направленные на воспрепятствование понимания твоего кода однозначно являются саботажем.
Еще раз: тут нет восприпятствования пониманию. Совеобразная "проверка на вшивость". Если я получу запрос по данной строке — просто буду иметь аргумент, касающийся квалификации инициатора запроса до того, как он будет слать другие запросы. Ну нет у меня желания _каждому_ объяснять что из себя представляет та или иная конструкция языка или алгоритм. Это не означает, что если кто-то поинтересуется для самообразования — то я не объясню.

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

E>Короче -- хороший код должен помогать в нм разобраться, а не мешать.
А кто спорит? Но тратить время _в каждом проекте_, на то, чтобы с кодом мог разобраться любой — не стоит. Просто я ценю свое время.

E>Так у тебя код "delete x, y, z" ещё и стандартный?
А что в нем нестандартного?

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

...
LMA>Еще раз: тут нет восприпятствования пониманию. Совеобразная "проверка на вшивость". Если я получу запрос по данной строке — просто буду иметь аргумент, касающийся квалификации инициатора запроса до того, как он будет слать другие запросы. Ну нет у меня желания _каждому_ объяснять что из себя представляет та или иная конструкция языка или алгоритм. Это не означает, что если кто-то поинтересуется для самообразования — то я не объясню.
Противоречие
...
E>>Короче -- хороший код должен помогать в нм разобраться, а не мешать.
LMA>А кто спорит? Но тратить время _в каждом проекте_, на то, чтобы с кодом мог разобраться любой — не стоит. Просто я ценю свое время.
А время других? Код пишется дни, недели, месяцы а сопровождается годами. Поэтому вожно, чтобы код хорошо сопровождался, иначе затраты на его поддержку со временем будут больше, чем затраты на его переписывание. Если нравится писать в мусорку, тогда действительно стоит писать как можно более запутанный код. Хотя в больших и сложных проектах и без этого проблем хватает.

Здравствуйте, Erop, Вы писали:
E>Ну знать надо, но не все же тонкости. Вернее отсутсвие всех мыслемых тонкостей.
В данном вопросе нужно знать только то, что и delete и , операторы, и представлять отношение их приоритетов.

E>delete вообще редко нужная конструкция, а уж знание на зубок всех возможных исключений в описании этой конструкции в стандарте -- совсем странное требование.
О каких исключениях идёт речь?

E> Я к тому, что вполне могло бы и быть что-то такое, с запятой в delete. Скажем вторые/третьи аргументы в operator delete могли бы так передавать, например...
А можно пример, где оператор "ведёт себя неожиданно" в синтаксическом плане?
Мне как-то всё время казалось, что С++ довольно "кудряв" в синтаксисе объявлений, но вот операторы всегда казались довольно простой и логичной в синтаксисе областью эхотага.

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

CC>Какой еще фейсконтроль в production коде???
Иногда могу пошалить. Конечно, если буду уверен, что другие воспримут это именно как шутку.

CC>Дык пример не совсем про то. В жизни есть ситуации когда надо делать теми силами, что есть в наличии — других не будет.
CC>Можно конечно сказать "а я с этими лохами педальными работать ваще не буду", сесть и ничего не делать. Но как по мне так это не вариант.
Я же не говорю, что так нужно делать во всех проектах. Но бываю же такие проекты, когда с этим все в порядке. Очевидно, что это вопрос лояльности, и я себя не могу назвать нелояльным человеком по отношению к тем фирмам, которые мне деньги платят, но если бы мне пришлось все время с новичками работать — я бы взвыл.

CC>За намеренные ловушки я бы гнал из команды. Код должен быть чистым.
В теории — да, но мир не идеален, а это всего лишь своего рода самозащита.

CC>+1. Но к минимизации метрики "WTF per minute" надо стремиться ИМХО
Да, безусловно.

CC>Оно то да, но вернемся на грешную землю в реальный мир: есть большой проект на С++. Надо его двигать и быстро. Квалифицированных людей нехватка, есть пучок недоквалифицированных. Т.е. теорию вроде знают но опыта нету. Что делать будем?
CC>Вариантов реальных два:
CC>1) Колбасить теми силами что есть на износ — высок риск фатального износа, что чревато...
CC>2) Взять несколько толковых неопытных "на подхват", от них реально помощь бывает + через некоторое время при достаточной степени вменяемости можно вырастить прогера "достаточной" квалификации.
Но это же не значит, что те, которые "на подхват" должны ковыряться в Вашем коде.

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

LMA>Но это же не значит, что те, которые "на подхват" должны ковыряться в Вашем коде.
Менять они его права не имели. Но понимать его они должны без отвлечения меня от работы.
И простота понимания кода играет тут существенную роль

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

CC>Так объясни какой сермяжный смысл ты в это вкладываешь?
CC>Для меня это пустой звук. Обычный комментарий пользы принес бы больше.
assert (-ы) в начале функции являются проверкой на preconditions. "Пустой" указывает на то, что preconditions отсутствуют (а не забыты). Больше читайте Александра Степанова.

LMA>>Нет. Сможет любой, знающий C++. Только действительно знающий
CC>Мсье нескромен
Я про себя ничего не писал. Но я действительно считаю, что если человек не знает приоритеты операторов в C++, то язык он не знает. Некоторых других языков программирования это, кстати, касается в меньшей степени.

CC>Складывается впечатление что ты "предпочитаешь выражать свои мысли музыкой С++" (С)
CC>Это так?
Язык C++ хорошо подходит для выражении моих мыслей — лучше других языков программирования. И я убежден, что использовать для выражения своих мыслей язык программирования — лучше, чем коментарии на естественном языке.

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

CC>Страшная мысль: а coding standard у вас есть вообще? Или художники на вольном выпасе?
Конечно есть. Но мои личные стандарты кодирования более жесткие, чем в тех проектах, в которых я участвую. Стандарты кодирования проектов разные — это зависит от проекта.

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

LMA>>Еще раз: тут нет восприпятствования пониманию. Совеобразная "проверка на вшивость". Если я получу запрос по данной строке — просто буду иметь аргумент, касающийся квалификации инициатора запроса до того, как он будет слать другие запросы. Ну нет у меня желания _каждому_ объяснять что из себя представляет та или иная конструкция языка или алгоритм. Это не означает, что если кто-то поинтересуется для самообразования — то я не объясню.
sc>Противоречие
В чем? Если я не готов объяснять каждому, это не значит, что не объясняю кому-то.

LMA>>А кто спорит? Но тратить время _в каждом проекте_, на то, чтобы с кодом мог разобраться любой — не стоит. Просто я ценю свое время.
sc>А время других? Код пишется дни, недели, месяцы а сопровождается годами. Поэтому вожно, чтобы код хорошо сопровождался, иначе затраты на его поддержку со временем будут больше, чем затраты на его переписывание. Если нравится писать в мусорку, тогда действительно стоит писать как можно более запутанный код. Хотя в больших и сложных проектах и без этого проблем хватает.
Все верно, но это не значит, что он должен хорошо сопровождаться любым человеком. Если Ваш код не может сопровождать обезьяна, это же не значит, что его плохо сопровождать. Повторю: писать код, который легок для понимания квалифицированным программистом быстрее (а еще приятнее), чем код, понимаемый любым программистом.

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

CC>Но понимать его они должны без отвлечения меня от работы.
Странное требование — чтобы они могли его понимать. Зачем? Может стоит просто подумать о другой декомпозиции?

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

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

CC>>Так объясни какой сермяжный смысл ты в это вкладываешь?
CC>>Для меня это пустой звук. Обычный комментарий пользы принес бы больше.
LMA>assert (-ы) в начале функции являются проверкой на preconditions. "Пустой" указывает на то, что preconditions отсутствуют (а не забыты). Больше читайте Александра Степанова.
не любых preconditions, а только внутренних, например внутримодульных.
вместо assert(true) на мой взгляд лучше assert("no preconditions");
...
CC>>Складывается впечатление что ты "предпочитаешь выражать свои мысли музыкой С++" (С)
CC>>Это так?
LMA>Язык C++ хорошо подходит для выражении моих мыслей — лучше других языков программирования. И я убежден, что использовать для выражения своих мыслей язык программирования — лучше, чем коментарии на естественном языке.
В коде с хорошими комментариями просто быстрее ориентироваться. Не нужно вчитываться, особенно в хитро закрученный код, чтобы найти интересующее место. А когда место найдено, тогда уже можно и детально разобраться. Код пишут один раз а читают сотни, а то и тысячи раз.

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

...
LMA>Все верно, но это не значит, что он должен хорошо сопровождаться любым человеком. Если Ваш код не может сопровождать обезьяна, это же не значит, что его плохо сопровождать. Повторю: писать код, который легок для понимания квалифицированным программистом быстрее (а еще приятнее), чем код, понимаемый любым программистом.
Не любым человеком, а большинством программистов код должен пониматься без особых напрягов.
Лучше медленне писать, но быстрее сопровождать, быстрее править баги и быстрее дописывать новую фунциональность
Даже достаточно простой и понятный код со временем может очень усложниться. После того, как над ним поработают несколько программистов подряд в течение нескольких лет. Так что лишние "кучеряшки" в коде лишние

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

LMA>"Пустой" указывает на то, что preconditions отсутствуют (а не забыты).
Всего то?..

CC>>Складывается впечатление что ты "предпочитаешь выражать свои мысли музыкой С++" (С)
CC>>Это так?
LMA>Язык C++ хорошо подходит для выражении моих мыслей — лучше других языков программирования. И я убежден, что использовать для выражения своих мыслей язык программирования — лучше, чем коментарии на естественном языке.
Спасибо.
Вопросов больше не имею.

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

CC>Хм. Какой хороший вопрос для собеседования!
И все таки я настаиваю на том, что вопрос отличный.
Вон даже тут сколько всего интересного о собеседниках узнал

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

CC>Перестань меня удивлять! Я почему то до сих пор считал что ты знаешь С++ на достаточном уровне...
Про весь С++ не скажу, но про operator delete знаю, возможно вообще всё.
При этом, судя по опыту обучения людей языку, многие люди имеют склонность ожидать, что у operator delete есть какие-нибудь особые формы, анологичные new( buffer ) T; или вызовам других operator new с дополнительными аргументами. IMHO в незнаии того, как там оно на самом деле большого вреда нет. Правда я в таких случаях, прошу человека почитать стандарт и выяснить ответ самостоятельно... Всё польза.

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

T>Мне как-то всё время казалось, что С++ довольно "кудряв" в синтаксисе объявлений, но вот операторы всегда казались довольно простой и логичной в синтаксисе областью эхотага.
Проверим, что тут всё просто?
Ты, наверное знаешь, что код delete p; вызовет деструктор *p, а потом позовёт operator delete( p );
1) Как вызвать operator delete( void*, size_t );
2) Как вызвать operator delete( void*, const char* );
3) Как вызывать operator delete( int );

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

LMA>Странное требование — чтобы они могли его понимать. Зачем? Может стоит просто подумать о другой декомпозиции?
Например при его использовании и отладки базирующегося на нём кода...

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

T>А можно пример, где оператор "ведёт себя неожиданно" в синтаксическом плане?
T>Мне как-то всё время казалось, что С++ довольно "кудряв" в синтаксисе объявлений, но вот операторы всегда казались довольно простой и логичной в синтаксисе областью эхотага.

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

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

всё ли тут хорошо?

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

LMA>Все верно, но это не значит, что он должен хорошо сопровождаться любым человеком. Если Ваш код не может сопровождать обезьяна, это же не значит, что его плохо сопровождать.
Не, ну если у вас и обезьяны доступ к коду имеют, то мне всё больше интересно где ты таки работаешь?

LMA>Повторю: писать код, который легок для понимания квалифицированным программистом быстрее (а еще приятнее), чем код, понимаемый любым программистом.

Может быть ты таки пояснишь, начиная с какой квалификации программиста конструкции вроде "delete x, y, z" начинают облегчать понимание кода?

Моей квалификации, например, хватило бы только на то, чтобы понять "Осторожно! Код писали люди с альтернативным подходом к программированию!!! Дальше может быть любое г.!!!!". Правда мне пришлось сделать осмысленное усилие, когда я этот пример тут увидел. Вспомнить про операторы, про запятую и т. д. Нормальный код на С++ я читаю не задумываясь о синтаксисе, примерно как текст по-русски или по-английски.

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

CC>>Страшная мысль: а coding standard у вас есть вообще? Или художники на вольном выпасе?
LMA>Конечно есть. Но мои личные стандарты кодирования более жесткие, чем в тех проектах, в которых я участвую. Стандарты кодирования проектов разные — это зависит от проекта.

и что? delete x, y, z; стандарты какого проекта позволяют писать?
Я бы даже

delete p, p = 0;

писать не стал бы...