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

LMA>Формально — практически любого. Хотелось бы узнать: а как может формулироваться стандарт, запрещающий такое?
Например, через запрет необоснованного (задаётся явным перечислением обоснованных случаев + разрешение начальника под его ответственность) использования запятой...
Кроме того ревью ещё бывают...

E>>Я бы даже

delete p, p = 0;

писать не стал бы...
LMA>Ты считаешь, что это менее читабельно, чем
LMA>

LMA>delete p;
LMA>p = 0;
LMA>

LMA>?
Да, считаю. Это необоснованное усложнение кода. Чтобы понять код с двумя операторами нужны толкьо базовые знания С++, а чтобы понять код с запятой, надо, по крайней мере, знать о точках следования. При этом код с запятой не проще написать и он не имеет никакх преимуществ для сколь угодно квалифицированного прграммиста. Так что он однозначно хуже.

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

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

L>

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

L>Объясните пожалуйста вот это посимвольно. Что-то я грузанулся...

Ну это такой панковский способ описать копируемый тип, с sizeof 1 и 2.
Теперь можно наваять каких-то функций с разными прототипами, которые возвращают тот или иной тип, после чего, можно написать выражение, тип которого будет зависеть от каких-то условий. После этого можно взять sizeof от этого выражения и узнать в CT верно какое-то условие или нет
IMHO это всё почти лишнее. Крайне редко бывает полезно.

Если же тебе не понятны сами типы, то Yes -- это ссылка на массив char из одного символа, а No на массив из двух.

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

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

CC>>Всего то?..
LMA>Было бы интересно узнать — как этот же вопрос решается у Вас.

А без этих ассертов в начале функций не прожить? Я обычно их пишу если реально надо проверить что-то сложное, а тривиальных методов зачем их писать

a = 3;
b = 4;

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

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

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

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

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

E>>Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:"
LMA>Я уже написал: "аргументами "?:" являются выражения?" (выделил жирным)
То есть ты ссылаешься на то, что корректность С++ выражений и порядок применения операций определяется не приоритетами, а некими грамматиками? Несводимыми, при этом, к понятию "приоритет операции"? Если так, то это обозначает, что приоритетов операций в С++ нет...

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

---

Пока что ты не прошёл лично мой ценз на соответствие уровня знаний С++ и уровня понтов по этому поводу

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

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

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

LMA>Ты считаешь, что это менее читабельно, чем
LMA>

LMA>delete p;
LMA>p = 0;
LMA>

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

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

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

LMA>>Ты считаешь, что это менее читабельно, чем
LMA>>

LMA>>delete p;
LMA>>p = 0;
LMA>>

LMA>>?
CC>Да.
CC>Код через запятую не имеет никакого преимущества, а вероятность неверного понимания или сотворения в том месте неоднозначной ошибки только повышает.
как правило, вторая половина вообще не нужна, ее пишут для а вероятность неверного понимания или сотворения в ДРУГОМ месте неоднозначной ошибки только повышает.
А вероятность закопипастить, одно без другого повышается, таким образом код c ; менее писабелен

struct Trash
{ template <class T> 
  Trash& operator << (T& d)
  { delete[] d,d=0;
    return *this;
  } 
} static trash;

............
   trash<<x<<y<<z;

обертку можно сделать

Здравствуйте, Programador,
или както так сделать чтоб выводить delete[] и delete , хотя для одиночных можно всегда new[1] звать, чтоб не путатся

 struct Trash
{ template <class T> 
  Trash& operator << (T& d)
  { delete d,d=0;
    return *this;
  } 
 template <class T, int N> 
  Trash& operator << (T (&d)[N])
  { delete[] d;
    return *this;
  } 
} static old;
void foo()
{  int *x,y[2],(&z)[]=(int (&)[])y;
   old<<x<<y<<z;
}

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

P> или както так сделать чтоб выводить delete[] и delete , хотя для одиночных можно всегда new[1] звать, чтоб не путатся
Вот уж реально людям заняться нечем

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

E>А заказчикам нашим сочувствовать не надо. Мы производим весьма успешные коробочные продукты, и библиотеки и SDK и в целом всем всё нравится.
Я просто делаю выводы из твоих слов. То, что некие продукты продаются, ведь не означает, что при другом подходе они не продавались бы лучше, так что это никак не доказывает того, что твоим заказчикам не надо посочувствовать. Кстати сказать, если судить по твоим репликами, сильно сомневаюсь, чтобы такого подпустили бы к серьезным продуктам, без обид.

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

E>И какова же эта существенная причина преднамаренно понижать качество кода?

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

E>Я не удивлён. Тебя я понял так, что НАДО,
Тогда читай внимательнее, я же выделил жирным шрифтом!

E>Обычно, когда критикуют, то приводят аргументы. И сразу ясно кто там чего стоит, и как критик и как автор.
Ага, в духе: почему у вас тут x*(x-1) — мы хотим цикл.
Может мне просто с новичками не везет, а у других таких проблем не бывает?

E>Если даже очень неквалифицированный программист найдёт в твоём прекраснейшем коде ошибку или недочёт какой -- то это будет на благо проекту!!!
+1. Только вот неквалифицированные ничего серьезного НИ РАЗУ не находили, зато времени на них уходит уйма.

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

E>Система контроля версий + вменяемый менеджмент процессом разработки + не читать письма людей, не имеющих к делу отношения...
Система контроля версия тут не при чем — я уже объяснял.
Вменяемый менеджмент. Даже не смешно.
Вопрос выбора стиля написания кода должен решаться ДО НАПИСАНИЯ кода, а не когда выяснится КОГО поставит заказчик на работу с кодом. Или ты его письма предлагаешь не читать?

E>Короче вопрос компетентности и допуска людей к коду должен решаться как-то административным путём, а не путём насыщения кода каким-то ребусами...
Административные пути — самые неэффективные. Точнее это просто не работает в больших распределенных командах.

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

LMA>>Формально — практически любого. Хотелось бы узнать: а как может формулироваться стандарт, запрещающий такое?
E>Например, через запрет необоснованного (задаётся явным перечислением обоснованных случаев + разрешение начальника под его ответственность) использования запятой...
Хотелось бы увидеть список необоснованных случаев использования запятой!!! Думаю, если бы такой можно было составить заранее, компилятор на такие случаи уже бы ругался.

E>Кроме того ревью ещё бывают...
Дык о нем родимом и речь! Код прошел 10 code review "без сучка, без задоринки" разными людьми, его передали еще кому-нибудь. Он сегодня одно пиьсьмо написал — получил ссылку в "букварь", завтра — еще одно, послезавтра — еще...

E>>>Я бы даже

delete p, p = 0;

писать не стал бы...
LMA>>Ты считаешь, что это менее читабельно, чем
LMA>>

LMA>>delete p;
LMA>>p = 0;
LMA>>

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

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

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

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>

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

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

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

E>Не совсем понятно. Приоритет операции -- это очень просто. Это частичное упорядочение на множестве операций, позволяющее сравнить операции, которые могут конкурировать между собой за приоритет. Если ещё проще, то это такая таблица, где каждой операции сопоставлен элемент упорядоченного множества. Число, например.
E>IMHO, если какая-то система понятий "тождественна" системе с приоритетами, то ты всегда можешь выписать такую таблицу и предъявить её.
E>Выпиши её, пожалуйста, для двух операций: "?:" и ","...
Возьми K&R — там эти два оператора есть в списке упорядоченных операций — в начале списка самые приоритетные, числа подставишь сам. Полученная таблица будет тождественна тому, что описано в стандарте C++, за исключением разницы между C и C++, что для этих двух операторов роли не играет.

E>>>Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:"
LMA>>Я уже написал: "аргументами "?:" являются выражения?" (выделил жирным)
E>То есть ты ссылаешься на то, что корректность С++ выражений и порядок применения операций определяется не приоритетами, а некими грамматиками? Несводимыми, при этом, к понятию "приоритет операции"? Если так, то это обозначает, что приоритетов операций в С++ нет...
Я не пойму к чему это ты. Пусть у тебя приоритет "?:" получится 101, а у "," — 103 (меньшее значение соответствует более высокому приоритету), что дальше? Что ты хочешь сказать?

E>Пока что ты не прошёл лично мой ценз на соответствие уровня знаний С++ и уровня понтов по этому поводу
Взаимно.

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

LMA>>получу реальную пользу в виде доводов против того, чтобы _это_ критиковало мой код.
CC>Следует ли понимать, что человека, обозначенного как _это_ вы считаете недопрограммистом а то и вообще недочеловеком?
Просто утрировал, не придирайтесь.
Никто не рождается опытным программистом. И есть множество сфер человеческой деятельности, в которых большинство из нас ничего не понимает до самой смерти.

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

LMA>>Ты считаешь, что это менее читабельно, чем
LMA>>

LMA>>delete p;
LMA>>p = 0;
LMA>>

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

a += b;

писать

a = a + b;

(конечно при условии одинакового результата, что верно в большинстве, наверное, случаев) потому, что для тех, кто "пришел" с других языков программирования так понятнее?

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

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

E>>И какова же эта существенная причина преднамаренно понижать качество кода?

E>>Твоя патологическая боязнь критики?
LMA>У меня нет боязни критики, не суди по себе о других. Просто объяснять прописные истины желания нет. А тебе видать нравится из букваря цитаты в исходники вставлять, что у вас за килобайты кода примии дают?
А что тогда обозначают всякие рассуждения про _ЭТО_, которое будет ТЕБЯ критиковать...

E>>Я не удивлён. Тебя я понял так, что НАДО,
LMA>Тогда читай внимательнее, я же выделил жирным шрифтом!
Я тоже выделил слово НЕЛЬЗЯ...

E>>Обычно, когда критикуют, то приводят аргументы. И сразу ясно кто там чего стоит, и как критик и как автор.
LMA>Ага, в духе: почему у вас тут x*(x-1) — мы хотим цикл.
IMHO, это значит, что надо написать комментарий... Но вообще-то вопрос довольно глупый. Показывает что задающий вопрос не разобрался. А ещё показывает, что ты написал код эффективный, но непонятный -- есть куда расти...

LMA>Может мне просто с новичками не везет, а у других таких проблем не бывает?
IMHO, ты просто не умеешь работать с людьми. Например, не умеешь заваёвывать у них авторитет. Иначе тебе бы не задавали дуратских вопросов, не попробовав предварительно разобраться самостоятельно. С другой стороны объяснить тот или иной приём в целом не долго...

LMA>+1. Только вот неквалифицированные ничего серьезного НИ РАЗУ не находили, зато времени на них уходит уйма.
IMHO, это говорит о том, что в вашей конторе очень плохо поставлена организация труда. Ко мне люди с улицы с вопросами "а почему вот у вас там написанно" не подходят...

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

LMA>Вопрос выбора стиля написания кода должен решаться ДО НАПИСАНИЯ кода, а не когда выяснится КОГО поставит заказчик на работу с кодом.
Я с этим не спорю. Я спорю с тем, что при написании кода нужно использовать направленные на его преднамеренное запутывание трюки, вроде "delete x, y, z"
LMA>Или ты его письма предлагаешь не читать?
Ты таки занимаешься аутсорсингом или OpSo?


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

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

LMA>Хотелось бы увидеть список необоснованных случаев использования запятой!!! Думаю, если бы такой можно было составить заранее, компилятор на такие случаи уже бы ругался.
Наоборот. Список контекстов, где запятая уместна. Обычно этот список состоит из лдного пункта -- третьей части оператора for...

E>>Кроме того ревью ещё бывают...
LMA>Дык о нем родимом и речь! Код прошел 10 code review "без сучка, без задоринки" разными людьми, его передали еще кому-нибудь. Он сегодня одно пиьсьмо написал — получил ссылку в "букварь", завтра — еще одно, послезавтра — еще...
Какой код? "delete x, y, z"?

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