Здравствуйте, netch80, Вы писали:
N>Тут есть одна проблемка: на большинстве систем коды EAGAIN и EWOULDBLOCK сейчас совпадают (такое вот легаси), но есть специфические, где они различны. При совпадении switch выдаёт ошибку.
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>assert((The(fileType).one_of<0, 1, 2, 3, 4>())); BFE>>Мне легче его читать, чем пять сравнений соединённых через ||
ЕМ>И Вас не смущает, что из такой формулировки, как правило, не следует, какой смысл имеет данное подмножество и, по-хорошему, нужен дополнительный комментарий?
Евгений, а вас не смущает, что из такой формулировки:
switch(fileType) {
case 0: ... break;
case 1: ... break;
case 2: ... break;
case 3: ... break;
case 4: ... break;
}
не следует какой смысл имеет данное подмножество?
ЕМ>В принципе, я вовсе не против подобных средств группировки. Но засада-то в том, что это сильно избыточно (на каждый вызов создается отдельный класс, который нигде больше не нужен)
И? Ну класс и класс. Он что, у вас есть простит? Каждый день, по три раза?
ЕМ>и весьма уродливо (реализация пакетов параметров шаблона, как очередное сугубо частное решение, худо-бедно годится для подобных последовательностей, а последовательности более другого вида не поймет, и их по-прежнему придется выписывать руками).
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>assert((The(fileType).one_of<0, 1, 2, 3, 4>())); BFE>>Мне легче его читать, чем пять сравнений соединённых через ||
ЕМ>И Вас не смущает, что из такой формулировки, как правило, не следует, какой смысл имеет данное подмножество и, по-хорошему, нужен дополнительный комментарий?
Смущает, но что делать, если концепцию перечисления (enum) понимает примерно только каждый десятый программист, а остальные думают, что это просто набор констант? Когда коллеги закладываются на значения констант перечисления появляются вот такие дурные проверки. Комментарии тут бесполезны.
Здравствуйте, B0FEE664, Вы писали:
BFE>Смущает, но что делать, если концепцию перечисления (enum) понимает примерно только каждый десятый программист, а остальные думают, что это просто набор констант?
Понимание концепция enum, дао набора констант... Постижение истины. Вот на кой подобное в инженерном деле?
BFE>Когда коллеги закладываются на значения констант перечисления появляются вот такие дурные проверки. Комментарии тут бесполезны.
Я вообще фигею — вынесли проверку в отдельную функцию с вменяемым названием и пользуйте. Не нравятся функции вынесите в макрос
Здравствуйте, so5team, Вы писали:
S>Евгений, а вас не смущает, что из такой формулировки: S>
S>switch(fileType) {
S> case 0: ... break;
S>}
S>
S>не следует какой смысл имеет данное подмножество?
Смущает, конечно. Поэтому я такие конструкции, если они повторяются, стараюсь выносить в отдельные единицы.
ЕМ>>на каждый вызов создается отдельный класс, который нигде больше не нужен
S>И? Ну класс и класс. Он что, у вас есть простит? Каждый день, по три раза?
Меня раздражает то, что это все костыли, причем придуманные не студентами-недоучками, а вполне себе профессионалами, вдобавок затащенные в стандарт языка, и повсеместно рекомендуемые. А если я напишу какой-нибудь макрос с переходами в спагетти-стайл, и эти люди увидят его у меня, они станут утверждать, будто мой код "грязный", а их код, построенный, по сути, на тех же принципах — "чистый".
S>Еще и кофе варить не умеет и ренту не приносит.
Здравствуйте, B0FEE664, Вы писали:
BFE>Смущает, но что делать, если концепцию перечисления (enum) понимает примерно только каждый десятый программист, а остальные думают, что это просто набор констант?
Дык, а чему удивляться, когда именно эту концепцию упорно тащили, как минимум, до появления enum class? По-хорошему, scoped enum нужно было иметь уже в первых версиях языка. Тем более, что на нём можно было бы почти даром сделать реализацию небольших множеств, по аналогии с паскалевским set.
Здравствуйте, kov_serg, Вы писали:
_>вынесли проверку в отдельную функцию с вменяемым названием и пользуйте.
К функциональной реализации тут уже были претензии по поводу "лишнего call", как будто такие проверки делаются минимум десятки-сотни тысяч раз в секунду.
_>Не нравятся функции вынесите в макрос :m
Так макрос ведь тоже по-человечески не сделаешь, макропроцессор лишь чуть менее убог, чем механизм шаблонов. Если б можно было, что в макросе, что в шаблоне, псевдоциклом перебрать параметры, формируя по ходу цикла итоговую конструкцию, во многих уродливых решениях попросту не было бы нужды.
Здравствуйте, kov_serg, Вы писали:
BFE>>Смущает, но что делать, если концепцию перечисления (enum) понимает примерно только каждый десятый программист, а остальные думают, что это просто набор констант? _>Понимание концепция enum, дао набора констант... Постижение истины. Вот на кой подобное в инженерном деле?
Затем, что абстрактный код легче править и развивать. В отношении enum это означает, что добавление или удаление элемента в начало или середину перечисления не ломает уже существующий код. Если же считать, что enum — это просто набор констант, то добавление нового элемента в середину перечисления приводит к просмотру и правке всего кода, который прямо или косвенно связан с константами. Часто, если используется тупая сереализация, это вообще невозможно или ломает совместимость с предыдущими версиями.
BFE>>Когда коллеги закладываются на значения констант перечисления появляются вот такие дурные проверки. Комментарии тут бесполезны. _>Я вообще фигею — вынесли проверку в отдельную функцию с вменяемым названием и пользуйте.
Ага. Точно: код из assert вынести в отдельную функцию! Это же гениально и главное просто: добавить отдельный файл с вменяемым названием (на придумывание вменяемого названия потратить минут 20), добавить файл в проект, добавить файл в систему контроля версий, не забыть обложить функцию дефайнами, чтобы она была выкинута при компиляции в release, а потом вызывать её из assert, спрятав от читателя все константы так, чтобы при первой правке кода забыть про добавление константы и поймав assert в рантайме исправить код функции ни разу не подумав о том, что эта проверка была написана не просто так и без этой проверки код лежащий ниже assert'a незаметно работает с ошибкой...
_>Не нравятся функции вынесите в макрос
Для меня наличие макросов означает низкое качество кода.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Смущает, конечно. Поэтому я такие конструкции, если они повторяются, стараюсь выносить в отдельные единицы.
А если не повторяются?
ЕМ>>>на каждый вызов создается отдельный класс, который нигде больше не нужен
S>>И? Ну класс и класс. Он что, у вас есть простит? Каждый день, по три раза?
ЕМ>Меня раздражает то, что это все костыли, причем придуманные не студентами-недоучками, а вполне себе профессионалами, вдобавок затащенные в стандарт языка, и повсеместно рекомендуемые.
Т.е. вы все никак не можете смириться с той вселенной, в которой живете?
Может вам тогда к специалистам обратиться, а не изливать свою боль на RSDN-е?
ЕМ>А если я напишу какой-нибудь макрос с переходами в спагетти-стайл
То у вас нужно попросить объяснить, почему спаггети-стайл, и почему в макросах. Если не сможете, то надавать по рукам.
ЕМ> а их код, построенный, по сути, на тех же принципах
На каких-таких принципах?
S>>Еще и кофе варить не умеет и ренту не приносит.
ЕМ>А и не надо. Не о том спич.
Спич как раз о том, что не нужно требовать от инструмента того, на что он не рассчитан.
Тов.B0FEE664 привел пример кода, который решает его задачи. На универсальность не претендует. На решение абсолютно всех проблем -- тоже. Так чего вы к этому коду прицепились?
Не понимаете как работает? Ну так и не пишите в таком стиле. Пишите как можете. C++ позволяет делать одно и тоже кучей разных способов.
Здравствуйте, Pzz, Вы писали:
A>>Я внезапно понял, что ты просто не умеешь программировать. Зато умничаешь как Александреску.
Pzz>Женя Музыченко — очень квалифицированный программист с многолетним стажем. JFYI.
Печальные же времена переживает программирование, если квалифицированный программист с многолетним стажем не способен распознать нарушение DRY.
Здравствуйте, B0FEE664, Вы писали:
BFE>Затем, что абстрактный код легче править и развивать.
Кто сказал? Абстрактный код обычно помимо того что абстрактный так еще и обобщенный. А на практике есть куча граничных случаев. В результате получаются разные крайности.
И править не сломав может может быть не просто.
BFE>В отношении enum это означает, что добавление или удаление элемента в начало или середину перечисления не ломает уже существующий код.
enum { C0,C1,C2,C3, C_MAX };
Если добавление ломает код это значит код хреновый. А вот удаление и должно ломать, если эта константа использовалась
BFE>Если же считать, что enum — это просто набор констант, то добавление нового элемента в середину перечисления приводит к просмотру и правке всего кода, который прямо или косвенно связан с константами.
Так в enum можно явно значения объявлять:
BFE> BFE>Часто, если используется тупая сереализация, это вообще невозможно или ломает совместимость с предыдущими версиями.
Совместимость с предыдущими версиями это не знача компилятора. Это на совести программиста. И если стоит задача сломать совместимость её обязательно сломают.
BFE>Ага. Точно: код из assert вынести в отдельную функцию! Это же гениально и главное просто: добавить отдельный файл с вменяемым названием (на придумывание вменяемого названия потратить минут 20), добавить файл в проект, добавить файл в систему контроля версий, не забыть обложить функцию дефайнами, чтобы она была выкинута при компиляции в release, а потом вызывать её из assert, спрятав от читателя все константы так, чтобы при первой правке кода забыть про добавление константы и поймав assert в рантайме исправить код функции ни разу не подумав о том, что эта проверка была написана не просто так и без этой проверки код лежащий ниже assert'a незаметно работает с ошибкой...
Точно надо вставлять проверки с портянками констант — это же гениально и главное просто, и когда надо что-то исправить достаточно поменять во всех файла где такое уже умудрились написать.
assert-ы должны проверять инварианты, которые должны быть описаны явно и в одном месте, а не раскиданы равномерно везде.
_>>Не нравятся функции вынесите в макрос BFE>Для меня наличие макросов означает низкое качество кода.
Ха ха ха. То что макросы досих пор есть, означает что их функционал пока нечем заменить. Вы видели реальную кодовую базу без макросов?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, kov_serg, Вы писали:
_>>вынесли проверку в отдельную функцию с вменяемым названием и пользуйте.
ЕМ>К функциональной реализации тут уже были претензии по поводу "лишнего call", как будто такие проверки делаются минимум десятки-сотни тысяч раз в секунду.
Так на секундочку, C++ умеет инлайнить код если это целесообразно. И потом реальный вклад подобной проверки ничтожен, на фоне доступа к оперативной памяти.
ЕМ>Так макрос ведь тоже по-человечески не сделаешь
И кто в этом виноват? Я просто написал что есть такой вариант, и на практике часто встречается. А в макросе может быть уже или код проверки или вызов функции или просто пусто. В зависимости от фазы луны define-ов.
Здравствуйте, kov_serg, Вы писали:
BFE>>Затем, что абстрактный код легче править и развивать. _>Кто сказал?
Очевидно, что я.
_>Абстрактный код обычно помимо того что абстрактный так еще и обобщенный. А на практике есть куча граничных случаев. В результате получаются разные крайности. _>И править не сломав может может быть не просто.
Сложность бывает разная: одно дело — головой думать, другое — искать иголку в стоге сена. И то и то сложно, но есть нюанс.
BFE>>В отношении enum это означает, что добавление или удаление элемента в начало или середину перечисления не ломает уже существующий код. _>
_>enum { C0,C1,C2,C3, C_MAX };
_>
_>Если добавление ломает код это значит код хреновый.
Да уже и так видно, без добавления, что, таки, да.
_>А вот удаление и должно ломать, если эта константа использовалась
очевидно.
BFE>>Если же считать, что enum — это просто набор констант, то добавление нового элемента в середину перечисления приводит к просмотру и правке всего кода, который прямо или косвенно связан с константами. _>Так в enum можно явно значения объявлять: _>
Я об этом и пишу.
BFE>> BFE>>Часто, если используется тупая сереализация, это вообще невозможно или ломает совместимость с предыдущими версиями. _>Совместимость с предыдущими версиями это не знача компилятора. Это на совести программиста. И если стоит задача сломать совместимость её обязательно сломают.
Я где-то в ветке писал про компилятор?
BFE>>Ага. Точно: код из assert вынести в отдельную функцию! Это же гениально и главное просто: добавить отдельный файл с вменяемым названием (на придумывание вменяемого названия потратить минут 20), добавить файл в проект, добавить файл в систему контроля версий, не забыть обложить функцию дефайнами, чтобы она была выкинута при компиляции в release, а потом вызывать её из assert, спрятав от читателя все константы так, чтобы при первой правке кода забыть про добавление константы и поймав assert в рантайме исправить код функции ни разу не подумав о том, что эта проверка была написана не просто так и без этой проверки код лежащий ниже assert'a незаметно работает с ошибкой... _>Точно надо вставлять проверки с портянками констант — это же гениально и главное просто, и когда надо что-то исправить достаточно поменять во всех файла где такое уже умудрились написать.
Если на значение констант полагаются, то — да, везде при использовании должны быть проверки.
_>assert-ы должны проверять инварианты, которые должны быть описаны явно и в одном месте, а не раскиданы равномерно везде.
Для этого есть static_assert'ы
А обычные assert'ы я использую для проверки входных параметров функции для проверки предусловий.
_>>>Не нравятся функции вынесите в макрос BFE>>Для меня наличие макросов означает низкое качество кода. _>Ха ха ха. То что макросы досих пор есть, означает что их функционал пока нечем заменить.
Да, к сожалению, часто функционал нечем заменить и приходится писать руками.
_>Вы видели реальную кодовую базу без макросов?
Да.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Дык, а чему удивляться, когда именно эту концепцию упорно тащили, как минимум, до появления enum class? По-хорошему, scoped enum нужно было иметь уже в первых версиях языка. Тем более, что на нём можно было бы почти даром сделать реализацию небольших множеств, по аналогии с паскалевским set.
Вот ввели enum class и что? 90% программистов продолжают прописывать значения элементам и кастить. Если запретить прописывать значения, то почти все из них просто перестанет пользоваться перечислением.
Здравствуйте, so5team, Вы писали:
S>А если не повторяются?
Тогда там везде разная логика обработки. И внести ошибку, забыв добавить к сравнению одно из значений, или добавив не то, что нужно, не сложнее, чем сделать опечатку.
S>вы все никак не можете смириться с той вселенной, в которой живете?
А Вы действительно воображаете, будто это "вселенная", а не просто засилье подхода "делаем потому, что можем"?
S>у вас нужно попросить объяснить, почему спаггети-стайл, и почему в макросах. Если не сможете, то надавать по рукам.
Тут весь вопрос в том, что понимается под "сможете". Ответить-то я всяко смогу, но мой ответ может не понравится вопрошающим, как верна и обратная ситуация. И тут на первое место выходит эта самая возможность надавать по рукам — в смысле, насколько это осуществимо.
ЕМ>> а их код, построенный, по сути, на тех же принципах
S>На каких-таких принципах?
На принципах применения недоделанных костылей, объединенных не столько разумной логикой, сколько принципами минимализма — "как бы сделать инструмент попроще, чтоб толпа бесплатных энтузиастов придумала для него побольше применений".
S>Спич как раз о том, что не нужно требовать от инструмента того, на что он не рассчитан.
То есть, STL, Boost, Loki применяют инструмент именно для того, на что он был рассчитан? А в последнем обсуждаемом примере одноразовый шаблонный класс создается тоже для того, на что была рассчитана идея классов?
S>Тов.B0FEE664 привел пример кода, который решает его задачи. На универсальность не претендует.
Из высказываний тов. B0FEE664 следует как раз обратное.
S>Так чего вы к этому коду прицепились?
Того, что писать такой код поощряет уродливый механизм реализации "современных" возможностей шаблонов, выдаваемый за передовой.
S>Не понимаете как работает?
Понимаю.
S>Пишите как можете. C++ позволяет делать одно и тоже кучей разных способов.
Так я всегда пишу, как могу, но C++ постоянно вынуждает делать вроде бы простые вещи непременно через задницу. То, что непосредственно в тексте программы это иногда выглядит более-менее читабельно, а задница заботливо вынесена в отдельные заголовки, ситуации не меняет.
Здравствуйте, B0FEE664, Вы писали:
BFE>код из assert вынести в отдельную функцию! Это же гениально и главное просто: добавить отдельный файл с вменяемым названием (на придумывание вменяемого названия потратить минут 20), добавить файл в проект, добавить файл в систему контроля версий, не забыть обложить функцию дефайнами, чтобы она была выкинута при компиляции в release, а потом вызывать её из assert
Я последние лет двадцать делаю именно так. То есть, если инвариант в виде мало-мальски сложного выражения сугубо "местный", то выражение в assert указывается, как есть; если же инвариант встречается в двух-трех разных местах и больше, то для него определяется функция с соответствующим смысловым названием, существующая только в отладочных сборках.
BFE>Для меня наличие макросов означает низкое качество кода.
Здравствуйте, B0FEE664, Вы писали:
BFE>Вот ввели enum class и что? 90% программистов продолжают прописывать значения элементам и кастить.
Теперь это их вина, а не создателей стандартов и компиляторов. У тех, кто имеет доступ к рычагам воздействия, есть выбор — заставлять или не обращать внимания.
BFE>Если запретить прописывать значения, то почти все из них просто перестанет пользоваться перечислением.
А зачем запрещать-то? Наоборот, от компилятора нужна возможность какой-то работы, отличной от ручной, с набором значений, заданных в пределах отдельного enum, хоть явно, хоть неявно.
