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

A>Странно, я всегда считал, что конструкция "while(*dest++ = *src++);" распознается нормальным разработчиком на уровне зрительных образов, без включения мозгов. Например когда смотрю на карандаш, то понимаю что это карандаш, не пытаясь при этом проанализовать форму предмета, прочитать что на нем написано, пощупать из чего этот предмет сделан и т.д.

Нефига, в контексте конструкции "while..." ты смотришь на деревянную палочку без надписей содержащую внутри себя некое черное вещество. Ты полагаешь что это карандаш, пытаешся заточить его, убеждаешся что он точится и что вещество внутри оставляет след и видимо является грифелем. И только после этого ты заключаешь что это карандаш.

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

ГВ>Раз-другой прочтут — запомнят. Я не понимаю, неужели C++ настолько неподъёмен, что мозги перетрудятся от чтения документации?

700 страниц ISO стандарта, между прочим. И в реальных проектах не думаю, что больше 10 % всех наворотов используется.

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

A>Странно, я всегда считал, что конструкция "while(*dest++ = *src++);" распознается нормальным разработчиком на уровне зрительных образов, без включения мозгов. Например когда смотрю на карандаш, то понимаю что это карандаш, не пытаясь при этом проанализовать форму предмета, прочитать что на нем написано, пощупать из чего этот предмет сделан и т.д.

Зависит исключительно от опыта работы с подобными конструкциями. Т.к. в рабочем коде я ничего похожего вообще не припомню (во всем местах работы был хорошо поставлен процесс его вычистки), то опыт ограничивается студенчеством и конференциями.

Например, нижеследующий код я теперь тоже сходу читаю, но только потому что полный изврат и с ним разбирался специально:

switch (0) { case 1: if (0) { case 0: cout << "Hello World! << endl;}}

Mikhail

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

K>Например, нижеследующий код я теперь тоже сходу читаю, но только потому что полный изврат и с ним разбирался специально:

K>

K>switch (0) { case 1: if (0) { case 0: cout << "Hello World! << endl;}}
K>

Боюсь что не скомпилируется — второй case без switch. А вообще после "switch (0) { case 1" можно дальше не читать.

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

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

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

A>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>А на поддержку, значит, традиционно приглашаем новичков. Следовательно, любой код должен быть ориентирован на новичков. Так?

Не совсем так. Несколько пунктов пропустили
A>Именно! Задачи кода — 1. реализовывать бизнес-функции максимально полно
2. Быть надежным и стабильным.
3. быть как можно проще в поддержке.
4. Быть максимально эффективным.

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

E>Таки не понял, за что минус
E>Я сказал ровно тоже самое.

E>PS 10% от $10000 — это $1000. Для $5000 — это $500.
Минус снял, поскольку не смог восстановить ту логику, согласно которой его выставил

PS. А я вообще написал символ строго меньше :D

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

ГВ>>У меня тоже не всегда есть такая уверенность. Здесь лучше всего помогает чтение стандарта и тесты.
K>Но есть фичи, неаккуратная обработка которых более вероятна.

Есть. И что? Голову никто не отменяет.

K>>>>>Аксиома: выбор стиля код программиста — не личное дело программиста, и вообще не его дело. Это дело тех, кто будет код поддерживать.
ГВ>>>>А на поддержку, значит, традиционно приглашаем новичков. Следовательно, любой код должен быть ориентирован на новичков. Так?
K>>>Я — не новичек. Но если мне подают код, ориентированный на новичков, то с ним работать гораздо легче. Спрашивается, нафига тогда выпендриваться ?
ГВ>>Вы сформулировали аксиому, я сформулировал естественное логическое следствие из этой аксиомы в условиях традиционной практики. Оставьте свои впечатления при себе и ответьте на заданный вопрос.

K>Ваш вопрос опирается на предположение, что "код для новичков" и "код, с которым хотел бы работать профи", обязательно разные вещи. Я считаю, что это одно и то же.

Во-первых, не верное противопоставление "новичка" и "профи". Скорее уж, "новичок" vs. "опытный".
Во-вторых, ошибочное следствие. Код "для новичка" и код "для профи" — совсем не одно и то же. Разные целевые аудитории, разные ограничения.

K>В этих условиях ваш вопрос получается эквивалентен "следовательно, любой код должен быть ориентирован на профессионалов". Ответ на оба эти одинаковых вопроса положительный. Я, как профессионал, предпочту работать с кодом, ориентированным на новичков.

Во-третьих, я же ясно просил не оперировать собственными предпочтениями.

ГВ>>Если эти самые "остальные" мотивируют свои трудности необходимостью изучить инструмент, то это сугубо их личные проблемы. Инструмент надо знать и уметь.
K>Эти остальные могут знать инструмент от и до. Но зачем им ненужный геморрой ?

Я что-то не понимаю, в чём геморрой-то? В снижении читабельности? Так читабельность — субъективная характеристика, это в каждом конкретном случае определяется. А то бывает и так, что "угадал все буквы, не смог прочесть слово".

ГВ>>С чего это Вы взяли, что на выходе у автора неизбежно получится г-но? Это всего лишь код на языке программирования и всё. Если фичи не понятны, то в них нужно разобраться, а не бравировать своим непониманием, прикрывая его маской заботы о ближнем.

K>Да кого вообще волнуют эти фичи ? Ну знаю их я. Знает сосед. Знает еще кто-нибудь. Может, все вокруг знают. Результат один — их применение должно быть обоснованным. Если их использование не несет каких-либо существенных плюсов, если это чистое эстетство ради более красивого кода, или может для сокращения десяти строк в семь (тоже мне разница), и при этом еще и затрудняют поддержку, то у них нет права на применение. Начальный кодинг много времени не занимает, как ты к нему не подходи. А вот дебаг и изменения жрут время с поистине зверским аппетитом. При этом обьем изменений кода снова минимален. Да пусть этот несчастный код втрое раздуют, только бы читался легче.

И с субъектными характеристиками настоятельно советую обращаться осторожнее. Мне, например, легче прочитать сотню килобайт компактного кода, чем мегабайты, но "простого".

ГВ>>Поймите меня правильно, я не против ругани в адрес того, кто оставил г-но за собой, хотя и на это могут быть свои вполне рациональные причины. Я против того, чтобы руководствоваться таким неправильным силлогизмом:
K>Я за огранчение на использование фич, создающих трудности в чтении и дебаге, в том числе чтении и дебаге "новичками".

А я за то, чтобы новички поскорее переставали быть новичками. Ваше ИМХО супротив моего ИМХО. До многого договоримся?

ГВ>>1. В некоторых случаях использование фичи X влечёт проблемы.
ГВ>>2. Проблемный код является г-ном.
ГВ>>Вывод: всякое использование фичи X — г-но.

K>Не всякое, а бесконтрольное.

Бесконтрольное использование чего угодно может повлечь проблемы. Молотком и тем можно пальцы отбить. Это же не повод запрещать им пользовтаься даже тем, кто им пользоваться умеет?

K>Правильный вывод: допущение использования фичи без серьезного ее основания — ошибочно. [...] а и потому, что его всем труднее разбирать, анализировать взаимодействие различных его кусков и держать в голове одновременно все нюансы используемых конструкций.

Если вывод делать только на основании Ваших рассуждений — тогда да. Вопрос только в том, что именно подразумевать под "основанием". Любую программу можно написать вовсе без C++, даже без C.

ГВ>>На бытовом уровне это может быть приемлемо, в технической деятельности — нет.
K>Между полным запретом и полным попустительством есть еще грань "запрет на применение без хорошего обоснования (на применение)".

Да, есть такая грань. Только определение "хорошего основания" опять упирается в осознанность или паче чаяния, в голосование. Первое "слишком сложно", второе слишком неоднозначно — дураков может оказаться больше. Вывод? На практике это обратится в полный запрет. Не мытьём, так катаньем.

ГВ>>Это тоже так. Но у примитивизации есть и оборотная сторона, прежде всего связанная с увеличением объёма исходников. "Комбинаторный взрыв", знаете ли.

K>Смотря как писать. Если писать монолит и не разбивать на подсистемы — возможно. А в промышленных системах полгода интенсивной разработки могут включать лишь неделю-другую на собственно кодирование. Да и тогда все неплохо разбито на модули. В одном месте разбивка нарушилась, и я в тот раз перетаскивал потроха на более правильное место.

К чему это всё? Я говорил только о том, что борьба с комбинаторным взрывом не всегда возможна без нетривиальных фич.

K>>>Все запреты неоднократно выстраданы на крешах.
ГВ>>Не стоит обобщать эту красивую легенду. На самом деле, запреты могут копироваться из всяческих good practices на основании одной только интуиции.
K>Это мне не помешало изрядно в оные креши потыкаться носом. На практиках основаны а) рекомендации б) запреты в условиях "при прочих равных" в) более жесткие запреты "при отсутствии обоснования и наличии обходных путей".

Охотно верю. Но тогда нужно дополнительно проанализировать Вашу собственную практику. У других она может быть совсем другой. И выводы могут быть другими.

ГВ>>Началось... Ладно, чтобы не вдаваться в длинные рассуждения, прочтите

K>Прочитал. Нашел утверждение, что при прочих равных надо выбирать более безопасный код. Добавлю, что еще и легко читаемый большей аудиторией. Отличие размера кода, скажем, в два раза, считаю незначительным, при сравнимом размере обьектника. С чем из этого вы не согласны ?

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

K>Кстати, могу предложить еще более интересный небезопасный код копирования строки:

K>

K>{
K>    int i = 0;
K>    while(dst[i] = src[i]) { ++i;}
K>}
K>

K>Вопрос на засыпку — когда такой вариант окажется лучше ?

Например, когда у нас нет operator *() и operator ++() для итераторов набора. Может быть, по критериям производительности... Надо конкретную ситуацию смотреть. Сколь я помню, для строк такая конструкция менее оптимальна, чем с указателями и постинкрементом.

ГВ>>Главное, что "разобрался и выучил". То, что "хочется видеть" что-то там — дело десятое. Это совсем не повод запрещать окружающим это самое что-то использовать.

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

Одно другому не противоречит. Не путайте разброд и шатание вообще и отсутствие именно идеологических запретов. Запреты по сугубо техническим причинам вполне имеют право на существование.

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

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

Как минимум.

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

ГВ>>А на поддержку, значит, традиционно приглашаем новичков. Следовательно, любой код должен быть ориентирован на новичков. Так?
A>Именно! Задачи кода — 1. реализовывать бизнес-функции максимально полно

Программы состоят не только из "бизнес"-кода.

A>2. быть как можно проще в поддержке.

Это достигается структурированием самого кода, а не кастрацией инструмента.

A>Так что использование выкрутасов типа виртуального наследования в реальном проекте ИМХО что художника из Строгановки приглашать покрасить забор.

Плохое ИМХО, что я ещё могу сказать?

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

ГВ>>Раз-другой прочтут — запомнят. Я не понимаю, неужели C++ настолько неподъёмен, что мозги перетрудятся от чтения документации?
A>700 страниц ISO стандарта, между прочим. И в реальных проектах не думаю, что больше 10 % всех наворотов используется.

Не знаю, как оно в реальных, а вот в настоящих проектах дела обстоят совсем не так. А в самых настоящих всё ещё сложнее.

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

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

ГВ>>>А на поддержку, значит, традиционно приглашаем новичков. Следовательно, любой код должен быть ориентирован на новичков. Так?
A>>Именно! Задачи кода — 1. реализовывать бизнес-функции максимально полно

ГВ>Программы состоят не только из "бизнес"-кода.

A>>2. быть как можно проще в поддержке.

ГВ>Это достигается структурированием самого кода, а не кастрацией инструмента.

а чем плоха с т.з. бизнеса кастрация инструмента? Ведь уменьшается риск посадить трудноотлавливаемую ошибку. Какие тут минусы?

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

A>>>2. быть как можно проще в поддержке.
ГВ>>Это достигается структурированием самого кода, а не кастрацией инструмента.
A>а чем плоха с т.з. бизнеса кастрация инструмента? Ведь уменьшается риск посадить трудноотлавливаемую ошибку. Какие тут минусы?

Мы уже начали обсуждать бизнес? Я что-то пропустил?

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

И с третьей стороны. Это любимый приём офисных демагогов типа менеджеров среднего звена (уж сколько я их насмотрелся...), оправдывать непонятно-почему-сделанные-шаги абстрактными "интересами бизнеса". Впрочем, это уже так, вырвалось...

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

K>Вообще же, самый правильный подход — писать код наиболее каноническим способом, чтобы это не значило, т.к. код пишется не для прямой трансляции в машкод, а для восприятия оптимизатором. Чем более знаком код оптимизатору, тем лучше результат.

Кстати, пример с итераторами и постинкрементами уж куда как каноничен. Практически, копия ARM-овского варианта.

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

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

A>>Так я все-таки не пойму, в чем заключается выпендреж. Если кто-то из разработчиков не понимает конструкции *src++, то это именно его нужно бить по голове резиновой дубинкой.

Д>Объясняю, за что надо бить.
Д>1. Это copy-paste распространенной реализации паттерна копирования

Вот на вскидку тоже самое без copy&paste — на все случаи программирования.

template<typename T>
bool IsTerm(T val);

template<class OutIt, class InIt>
inline void CopyTerm(OutIt dest, InIt src)
{
    while(!IsTerm(*dest++ = *src++));
}

inline bool IsTerm(char c)
{
  return !c;
}

Д>2. Этот код крайне небезопасен. Напоминаю — в точности такой же кусок кода обошелся MS в миллионы долларов убытков, не говоря уже о потере репутации.

MS-у, вероятно, обошёлся в миллионы долларов не сам код, а то, что где-то было реализовано неправомерное предположение о допустимости отсутствия контроля длины передаваемых данных.

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

Д>знание одного принципа избавляет от необходимости знать сотни деталей (С) Конфуций

Верно. Знание одного принципа виртуального наследования избавляет от необходимости знать сотню деталей.

Д>могу только посочувствовать тем, кто этого не понимает. Мозги — они не бесконечные

+1

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

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

K>>Вообще же, самый правильный подход — писать код наиболее каноническим способом, чтобы это не значило, т.к. код пишется не для прямой трансляции в машкод, а для восприятия оптимизатором. Чем более знаком код оптимизатору, тем лучше результат.

ГВ>Кстати, пример с итераторами и постинкрементами уж куда как каноничен. Практически, копия ARM-овского варианта.

Каноничен для человека, воспитанного Страуструпом. А если этот код будет пытаться понять не Сишник(такое, кстати, бывает) — ему прийдется много думать, в отличии от CopyTo(source, dest)

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

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

A>>>>2. быть как можно проще в поддержке.
ГВ>>>Это достигается структурированием самого кода, а не кастрацией инструмента.
A>>а чем плоха с т.з. бизнеса кастрация инструмента? Ведь уменьшается риск посадить трудноотлавливаемую ошибку. Какие тут минусы?

ГВ>Мы уже начали обсуждать бизнес? Я что-то пропустил?

А к нему все сводится, к пошлому получению денег с клиента. Если т-ко код не пишется для самовыражения. И ограничение вполне себе понятное и правильное — писать так, чтобы код могли поддерживать не т-ко 5 гуру, но и 500 мартышек.

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

ГВ>>Мы уже начали обсуждать бизнес? Я что-то пропустил?
A>А к нему все сводится, к пошлому получению денег с клиента. Если т-ко код не пишется для самовыражения. И ограничение вполне себе понятное и правильное — писать так, чтобы код могли поддерживать не т-ко 5 гуру, но и 500 мартышек.

Хех. Не всё так просто. Не к одному только стряхиванию денег с клиента всё сводится. Как раз самовыражение тоже зачастую является нехилой мотивацией. А отсутствие этой самой мотивации вполне может привести к тому, что и продукта-то никогда не появится...

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

ГВ>>Кстати, пример с итераторами и постинкрементами уж куда как каноничен. Практически, копия ARM-овского варианта.
J>Каноничен для человека, воспитанного Страуструпом. А если этот код будет пытаться понять не Сишник(такое, кстати, бывает) — ему прийдется много думать, в отличии от CopyTo(source, dest)

Вывод: не надо тащить на поддержку C++-ных проектов кого попало.