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

CC>А вот "может быть так, а может эдак", если про удаление обоих заикнется — тогда все таки минус. Ну базовые ж вещи! Тем более при прямой работе с памятью.

Ну, в целом, стандарт у С++ кудрявый. И кто его там знает, что придумали там для запятой в delete. IMHO, может быть три варианта (по степени убывания вероятности)
1) удалится второй
2) удалится первый
3) удаляться таки оба, только второй как скаляр (это если delete x, y; устроен так же как и int x, y

Какой из трёх выбрали авторы языка догадаться, IMHO, нельзя. Это надо знать. Но на кой бы это знать --

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

LMA>Запись "delete x, y, z;" есть способ повысить минимальный уровень требований к осуществляющему code review, если, конечно, писавший такое понимает, что он делает "delete x;". Т.е. способ не подпускать новичков к своему коду,...
А что, систем контроля версий и распределения прав вы не используете в работе?
Да и какой смысл в этой записи писать "x, y" вообще? Это типа просто обфускация на коленке?
Я бы такие ПРЕДНАМЕРЕННЫЕ действия воспринимал как преднамеренный саботаж, и немедленно бы уволил...
Хотя, возможно ты о разработке в OpenSource канечна... Там уволить нельзя вроде как...

LMA>писать просто
LMA>

LMA>assert(true);
LMA>

Нахрена это вообще писать? Этот код эквивалентен пустому оператору. Если ты хочешь что-то написать читателю кода, а не компилятору, то от чего бы не воспользоваться человеческим языком, а не языком С++ ребусов?..

LMA>...если Вы понимаете о чем я. Что в конечном итоге может повысить производительность труда, между прочим. Понятно, что такое применимо не для всех проектов.

В целом я понимаю. Ты о генерации С++ кода, который никто кроме тебя поддерживать не сможет.
Мало того, что это вредно для бизнес-процессов, так это ещё и для тебя вредно.
Во-первых, ты не сможешь работать с другими людьми\
Во-вторых, обычно такие подходы приводят к тому, что через пару лет надо что-то поправить, а не выходит...

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

P>а еще можно сделать tranDets++ гдето по пути
P>чтоб от этого защитится ???лучше??? замутить так

1) IMHO, невменяемых кодеров допускать к коду на голых указателях нехорошо и даже опвсно.
2) Так

char * const tranDets = new char[128];

не хватит?

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

E>IMHO, может быть три варианта (по степени убывания вероятности)
E>1) удалится второй
E>2) удалится первый
E>3) удаляться таки оба, только второй как скаляр (это если delete x, y; устроен так же как и int x, y
Однако...

E>Какой из трёх выбрали авторы языка догадаться, IMHO, нельзя. Это надо знать. Но на кой бы это знать --
Знать надо формат вызова delete. И как оно работает. Надеюсь с этим ты согласен?

Впрочем я тут круче пример придумал:

    char *foo = new char[100];
    char *bar = new char[100];

    delete [] (foo,bar);    // ЫЫЫЫЫ!!!

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

CC>Впрочем я тут круче пример придумал:
CC>

CC>    char *foo = new char[100];
CC>    char *bar = new char[100];
CC>    delete [] (foo,bar);    // ЫЫЫЫЫ!!!
CC>

Не сильно-то он и круче. Насколько понимаю, это эквивалентно записи delete [] bar.

Не вижу смысла вообще обсуждать подобные клинические случаи.
IMHO delete в таком виде, в каком он представлен в этих примерах быть не должно, потому как smart pointer'ы более exception safe.

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

PC>Не сильно-то он и круче.
Не сильно, но я тут опросик по аське утворил — некоторых он заставил посомневаться и задуматься.
Показательно между прочим.

PC>Насколько понимаю, это эквивалентно записи delete [] bar.
Почти. Ты про foo забыл, хоть оно и выбросится компилером.
А объяснить почему именно так будет можешь?

PC>Не вижу смысла вообще обсуждать подобные клинические случаи.
Ну например потому, что на таких клинических случаях часто построены вопросы на собеседованиях и brainbench.
Да и просто мне поностальгировать захотелось

PC>IMHO delete в таком виде, в каком он представлен в этих примерах быть не должно
Не должно, факт.

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

CC>Знать надо формат вызова delete. И как оно работает. Надеюсь с этим ты согласен?

Ну знать надо, но не все же тонкости. Вернее отсутсвие всех мыслемых тонкостей.
delete вообще редко нужная конструкция, а уж знание на зубок всех возможных исключений в описании этой конструкции в стандарте -- совсем странное требование. Я к тому, что вполне могло бы и быть что-то такое, с запятой в delete. Скажем вторые/третьи аргументы в operator delete могли бы так передавать, например...

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

CC>Не сильно, но я тут опросик по аське утворил — некоторых он заставил посомневаться и задуматься.
CC>Показательно между прочим.

Я думаю потому, что похоже на запись

new( bufffer ) T;

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

PC>>Насколько понимаю, это эквивалентно записи delete [] bar.
CC>Почти. Ты про foo забыл, хоть оно и выбросится компилером.
CC>А объяснить почему именно так будет можешь?

Конечно. Всё что в скобках будет вычисляться первым. Оператор запятая вернёт свой последний аргумент, в первом аргументе вычисляться ничего не будет, так что в итоге к в качестве аргумента delete поступит bar.

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

CC>Смысла в этом коде нет никакого. А запутать может, особенно при беглом просмотре кода, когда глаз цепляется за начало строк.
Смысл — в фейсконтроле. Чтобы не запутать — можно после кода в коментарии поставить смайлик.

CC>А какой смысл их не подпускать?
Чтобы вместо того, чтобы разжевывать очевидные (для людей схожей квалификации) вещи в своем коде, написать больше действительно полезного кода. Если не нравится пример, который я уже привел — могу привести другой: вместо расписывания что делает "хитрый" по мнению неучей код — дать ссылку на "must have" для тех кто забыл. Например, вместо объяснения почему "вместо" цикла идет простой x&(x-1) — дать ссылку на книжку K&R.

CC>В свое время столкнулись с капитальной нехваткой квалифицированных С++шников.
Не бывает нехватки квалифицированных кадров (по крайней мере, в РФ) — бывает желание найти квалифицированных кадров, готовых работать "за еду".

CC>Пришлось выбирать лучших из тех что были. И они должны были работать и желательно как можно более эффективно.
Только вот сколько Вы потеряли на том, что квалифицированные ваши сотрудники были вынуждены работать с этими, Вы не посчитали?

CC>А вот такие запутывалки только тормозят понимание кода. Следовательно их использование скорее во вред.
Такие ловушки не надо разрасывать по всему коду — только на самом видном месте.

CC>Вообще я лично оценивал всегда как большой плюс, если на пример какого нибудь головоломного заворота кода собеседуемый отвечал что за такой код надо больно бить по рукам и заставлять переписывать. Разумеется если такой ответ приходил на простую конструкцию то эффект был как раз противоположный.
В общем случае — это сильно зависит от заворота и от того, в каком месте проекта он используется. В любом случае, так как все субьективно, WTFs/min равным нулю не бывает.

CC>ИМХО некоторые возможности С++ людям со слабой волей лучше и не знать вовсе — не удержатся от применения везде где только можно. Получившуюся помойку потом и сами часто не могут отладить/модифицировать.
C++ — это язык для квалифицированных программистов. Всем будет лучше других держать подальше.

CC>Это и надо выяснять на собеседовании + испытательный срок еще есть для особо клинических случаев.
Вам очень везет, если Вы можете проводить собеседование для _каждого_, кто будет иметь дело с Вашим кодом. Могу только позавидовать.

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

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

-1.

Во-первых, он бывает нужен в for.

Во-вторых, это единственное выражение, позволяющее из потенциально-void-выражения сделать гарантированно-не-void. Применяется в SFINAE. Например:

// можно ли вызвать someFunction(T())?

typedef char (&Yes)[1];
typedef char (&No)[2];

BOOST_STATIC_ASSERT(sizeof(Yes) != sizeof(No));

struct Failure { };

Failure someFunction(...);

No operator ,(Failure, Yes);

template <class T>
T& make();

sizeof( someFunction(make<T>()) , Yes() ) == sizeof(Yes); // если истинно, то можно

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

E>А что, систем контроля версий и распределения прав вы не используете в работе?
При чем тут это? Или у вас принято, чтобы программист пофамильно выбирал, кто будет смотреть на его код?

E>Я бы такие ПРЕДНАМЕРЕННЫЕ действия воспринимал как преднамеренный саботаж, и немедленно бы уволил...
А в чем саботаж?

LMA>>писать просто
LMA>>

LMA>>assert(true);
LMA>>

E>Нахрена это вообще писать? Этот код эквивалентен пустому оператору. Если ты хочешь что-то написать читателю кода, а не компилятору, то от чего бы не воспользоваться человеческим языком, а не языком С++ ребусов?..
Нету к сожалению "человеческого" языка — есть русский, английский, немецкий, китайский и т.д. Все что я знаю о том, кто будет смотреть мой код — он должен знать C++. А тому, для кого "assert(true);" — не пустой звук, я готов помочь такими конструкциями понять мой код.

E>В целом я понимаю. Ты о генерации С++ кода, который никто кроме тебя поддерживать не сможет.
Нет. Сможет любой, знающий C++. Только действительно знающий, а не тот которому delete x, y; "не режет глаз" (и который не помнит какие у какого оператора приоритеты). И как я уже писал, тут многое зависит от проекта и не надо думать, что так нужно делать всегда и везде — есть проекты, в которых действительно стоит ненужные () расставлять и прочие вещи чисто для удобочитаемости. Тут вопрос скорее в том, какие проекты для себя выбирает человек.

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

E>>А что, систем контроля версий и распределения прав вы не используете в работе?
LMA>При чем тут это? Или у вас принято, чтобы программист пофамильно выбирал, кто будет смотреть на его код?
У разных программистов есть доступ к разным областям кода. При этом у кода как правило есть сотрудник, который отвечает за его текущее состояние и править его можно только при его участии либо при участии его начальника. А что, у вас как-то не так?
При этом права раздаёшь не ты, а менеджеры, которые управляют производством ПО...

LMA>А в чем саботаж?
В преднамеренном препятствовании коллективной разработке и снижении управяемости процесса производства ПО.

E>>Нахрена это вообще писать? Этот код эквивалентен пустому оператору. Если ты хочешь что-то написать читателю кода, а не компилятору, то от чего бы не воспользоваться человеческим языком, а не языком С++ ребусов?..
LMA>Нету к сожалению "человеческого" языка — есть русский, английский, немецкий, китайский и т.д. Все что я знаю о том, кто будет смотреть мой код — он должен знать C++. А тому, для кого "assert(true);" — не пустой звук, я готов помочь такими конструкциями понять мой код.
А ты даже и языка коллег не знаешь? А как вы общаетесь? На С++? Или таки речь про OpenSource?
Вообще-то в нормальной программае, кроме комментариев есть ещё и идентификаторы и документация и интерфейсные сообщения и имена файлов... Обычно, если языки разработчиков отличаются используют английский...

LMA>Нет. Сможет любой, знающий C++. Только действительно знающий, а не тот которому delete x, y; "не режет глаз" (и который не помнит какие у какого оператора приоритеты). И как я уже писал, тут многое зависит от проекта и не надо думать, что так нужно делать всегда и везде — есть проекты, в которых действительно стоит ненужные () расставлять и прочие вещи чисто для удобочитаемости. Тут вопрос скорее в том, какие проекты для себя выбирает человек.
Даже очень знающий С++ может не обратить внимания на твои художества. Кроме того, он может попробовать выяснить зачем такая хреновина написана. Я, например, требую от сотрудников, чтобы они избегали нестандартного кода. А если уж избежать не получилось, то должно быть понятно, зачем тут понадобилось извращаться...

Короче реально бы уволил без разговоров.

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

LMA>>При чем тут это? Или у вас принято, чтобы программист пофамильно выбирал, кто будет смотреть на его код?
E>У разных программистов есть доступ к разным областям кода. При этом у кода как правило есть сотрудник, который отвечает за его текущее состояние и править его можно только при его участии либо при участии его начальника. А что, у вас как-то не так?
E>При этом права раздаёшь не ты, а менеджеры, которые управляют производством ПО...
Откуда взялось "править"? Речь пока что шла о просмотре кода. Заказчик может передать код кому-угодно по своему усмотрению для чего угодно, это уже не моя проблема. Но моя проблема, чтобы он был читаем квалифицированным программистом из любой страны.

LMA>>А в чем саботаж?
E>В преднамеренном препятствовании коллективной разработке и снижении управяемости процесса производства ПО.
А никакого припятствования! Речь идет лишь о том, что люди должны иметь определенный уровень квалификации.

E>А ты даже и языка коллег не знаешь?
Реально обычно догадываюсь, но я на многих из этих языков не говорю.

E>А как вы общаетесь?
Я со ВСЕМИ колегами не общаюсь напрямую.

E>Вообще-то в нормальной программае, кроме комментариев есть ещё и идентификаторы и документация и интерфейсные сообщения и имена файлов... Обычно, если языки разработчиков отличаются используют английский...
Где на C++ нельзя, приходится английский — мир не идеален.

E>Даже очень знающий С++ может не обратить внимания на твои художества.
Так это моя задача, чтобы знающий обратил — это не сложно.

E>Кроме того, он может попробовать выяснить зачем такая хреновина написана.
Always welcome. Но если что — пусть не удивляется, если "опущу".

E>Я, например, требую от сотрудников, чтобы они избегали нестандартного кода. А если уж избежать не получилось, то должно быть понятно, зачем тут понадобилось извращаться...
+1. Только что есть "нестандартный код" — видимо у нас разные взгляды.

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

E>>В преднамеренном препятствовании коллективной разработке и снижении управяемости процесса производства ПО.
LMA>А никакого припятствования! Речь идет лишь о том, что люди должны иметь определенный уровень квалификации.
IMHO это дело менеджера или владельца кода, выяснять какая у кого должна быть квалификация. Действия с твоей стороны направленные на воспрепятствование понимания твоего кода однозначно являются саботажем.

LMA>Где на C++ нельзя, приходится английский — мир не идеален.
Просто улучши свой английский, а не на мар гони

E>>Кроме того, он может попробовать выяснить зачем такая хреновина написана.
LMA>Always welcome. Но если что — пусть не удивляется, если "опущу".
Короче -- хороший код должен помогать в нм разобраться, а не мешать.

LMA>+1. Только что есть "нестандартный код" — видимо у нас разные взгляды.
Так у тебя код "delete x, y, z" ещё и стандартный?

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

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

PC>>>Насколько понимаю, это эквивалентно записи delete [] bar.
CC>>Почти. Ты про foo забыл, хоть оно и выбросится компилером.
CC>>А объяснить почему именно так будет можешь?

PC>Конечно. Всё что в скобках будет вычисляться первым. Оператор запятая вернёт свой последний аргумент, в первом аргументе вычисляться ничего не будет, так что в итоге к в качестве аргумента delete поступит bar.

Правильно. Но как оказалось с запятой сталкивались не все...

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

E>Ну знать надо, но не все же тонкости. Вернее отсутсвие всех мыслемых тонкостей.
E>delete вообще редко нужная конструкция, а уж знание на зубок всех возможных исключений в описании этой конструкции в стандарте -- совсем странное требование. Я к тому, что вполне могло бы и быть что-то такое, с запятой в delete. Скажем вторые/третьи аргументы в operator delete могли бы так передавать, например...
Перестань меня удивлять! Я почему то до сих пор считал что ты знаешь С++ на достаточном уровне...

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

CC>>Смысла в этом коде нет никакого. А запутать может, особенно при беглом просмотре кода, когда глаз цепляется за начало строк.
LMA>Смысл — в фейсконтроле. Чтобы не запутать — можно после кода в коментарии поставить смайлик.
Какой еще фейсконтроль в production коде???

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

CC>>В свое время столкнулись с капитальной нехваткой квалифицированных С++шников.
LMA>Не бывает нехватки квалифицированных кадров (по крайней мере, в РФ) — бывает желание найти квалифицированных кадров, готовых работать "за еду".
Это вопрос уже к руководству. Но и реально некоторый кадровый голод на вменяемых людей тогда был. (Не РФ )

CC>>Пришлось выбирать лучших из тех что были. И они должны были работать и желательно как можно более эффективно.
LMA>Только вот сколько Вы потеряли на том, что квалифицированные ваши сотрудники были вынуждены работать с этими, Вы не посчитали?
Не я принимал такое решение.

CC>>А вот такие запутывалки только тормозят понимание кода. Следовательно их использование скорее во вред.
LMA>Такие ловушки не надо разрасывать по всему коду — только на самом видном месте.
За намеренные ловушки я бы гнал из команды. Код должен быть чистым.

CC>>Вообще я лично оценивал всегда как большой плюс, если на пример какого нибудь головоломного заворота кода собеседуемый отвечал что за такой код надо больно бить по рукам и заставлять переписывать. Разумеется если такой ответ приходил на простую конструкцию то эффект был как раз противоположный.
LMA>В общем случае — это сильно зависит от заворота и от того, в каком месте проекта он используется. В любом случае, так как все субьективно, WTFs/min равным нулю не бывает.
+1. Но к минимизации метрики "WTF per minute" надо стремиться ИМХО

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

CC>>Это и надо выяснять на собеседовании + испытательный срок еще есть для особо клинических случаев.
LMA>Вам очень везет, если Вы можете проводить собеседование для _каждого_, кто будет иметь дело с Вашим кодом. Могу только позавидовать.
Проводил собеседования в соседний отдел, где делали не ядро проекта а всякое сильно попроще. Ну и требования были на самом пределе разумного. Если кто попадался потолковее тогда уже мучали капитально. Впрочем я уже там полгода как не работаю.

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

LMA>А тому, для кого "assert(true);" — не пустой звук, я готов помочь такими конструкциями понять мой код.
Так объясни какой сермяжный смысл ты в это вкладываешь?
Для меня это пустой звук. Обычный комментарий пользы принес бы больше.

LMA>Нет. Сможет любой, знающий C++. Только действительно знающий
Мсье нескромен

Складывается впечатление что ты "предпочитаешь выражать свои мысли музыкой С++" (С)
Это так?

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

LMA>+1. Только что есть "нестандартный код" — видимо у нас разные взгляды.
Страшная мысль: а coding standard у вас есть вообще? Или художники на вольном выпасе?