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

BFE>>Затем, что абстрактный код легче править и развивать.
_>Кто сказал?
Очевидно, что я.

_>Абстрактный код обычно помимо того что абстрактный так еще и обобщенный. А на практике есть куча граничных случаев. В результате получаются разные крайности.
_>И править не сломав может может быть не просто.
Сложность бывает разная: одно дело — головой думать, другое — искать иголку в стоге сена. И то и то сложно, но есть нюанс.

BFE>>В отношении enum это означает, что добавление или удаление элемента в начало или середину перечисления не ломает уже существующий код.
_>

_>enum { C0,C1,C2,C3, C_MAX };
_>

_>Если добавление ломает код это значит код хреновый.
Да уже и так видно, без добавления, что, таки, да.

_>А вот удаление и должно ломать, если эта константа использовалась
очевидно.

BFE>>Если же считать, что enum — это просто набор констант, то добавление нового элемента в середину перечисления приводит к просмотру и правке всего кода, который прямо или косвенно связан с константами.
_>Так в enum можно явно значения объявлять:
_>

_>enum { B0=1,B1=2,B2=4,B3=8,B4=16,B5=32,B6=64,B7=128 };
_>

Я об этом и пишу.

BFE>>
BFE>>Часто, если используется тупая сереализация, это вообще невозможно или ломает совместимость с предыдущими версиями.
_>Совместимость с предыдущими версиями это не знача компилятора. Это на совести программиста. И если стоит задача сломать совместимость её обязательно сломают.
Я где-то в ветке писал про компилятор?

BFE>>Ага. Точно: код из assert вынести в отдельную функцию! Это же гениально и главное просто: добавить отдельный файл с вменяемым названием (на придумывание вменяемого названия потратить минут 20), добавить файл в проект, добавить файл в систему контроля версий, не забыть обложить функцию дефайнами, чтобы она была выкинута при компиляции в release, а потом вызывать её из assert, спрятав от читателя все константы так, чтобы при первой правке кода забыть про добавление константы и поймав assert в рантайме исправить код функции ни разу не подумав о том, что эта проверка была написана не просто так и без этой проверки код лежащий ниже assert'a незаметно работает с ошибкой...
_>Точно надо вставлять проверки с портянками констант — это же гениально и главное просто, и когда надо что-то исправить достаточно поменять во всех файла где такое уже умудрились написать.
Если на значение констант полагаются, то — да, везде при использовании должны быть проверки.

_>assert-ы должны проверять инварианты, которые должны быть описаны явно и в одном месте, а не раскиданы равномерно везде.
Для этого есть static_assert'ы
А обычные assert'ы я использую для проверки входных параметров функции для проверки предусловий.

_>>>Не нравятся функции вынесите в макрос
BFE>>Для меня наличие макросов означает низкое качество кода.
_>Ха ха ха. То что макросы досих пор есть, означает что их функционал пока нечем заменить.
Да, к сожалению, часто функционал нечем заменить и приходится писать руками.

Вы видели реальную кодовую базу без макросов?
Да.

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

BFE>>Затем, что абстрактный код легче править и развивать.
_>Кто сказал?
Очевидно, что я.

_>Абстрактный код обычно помимо того что абстрактный так еще и обобщенный. А на практике есть куча граничных случаев. В результате получаются разные крайности.
_>И править не сломав может может быть не просто.
Сложность бывает разная: одно дело — головой думать, другое — искать иголку в стоге сена. И то и то сложно, но есть нюанс.

BFE>>В отношении enum это означает, что добавление или удаление элемента в начало или середину перечисления не ломает уже существующий код.
_>

_>enum { C0,C1,C2,C3, C_MAX };
_>

_>Если добавление ломает код это значит код хреновый.
Да уже и так видно, без добавления, что, таки, да.

_>А вот удаление и должно ломать, если эта константа использовалась
очевидно.

BFE>>Если же считать, что enum — это просто набор констант, то добавление нового элемента в середину перечисления приводит к просмотру и правке всего кода, который прямо или косвенно связан с константами.
_>Так в enum можно явно значения объявлять:
_>

_>enum { B0=1,B1=2,B2=4,B3=8,B4=16,B5=32,B6=64,B7=128 };
_>

Я об этом и пишу.

BFE>>
BFE>>Часто, если используется тупая сереализация, это вообще невозможно или ломает совместимость с предыдущими версиями.
_>Совместимость с предыдущими версиями это не знача компилятора. Это на совести программиста. И если стоит задача сломать совместимость её обязательно сломают.
Я где-то в ветке писал про компилятор?

BFE>>Ага. Точно: код из assert вынести в отдельную функцию! Это же гениально и главное просто: добавить отдельный файл с вменяемым названием (на придумывание вменяемого названия потратить минут 20), добавить файл в проект, добавить файл в систему контроля версий, не забыть обложить функцию дефайнами, чтобы она была выкинута при компиляции в release, а потом вызывать её из assert, спрятав от читателя все константы так, чтобы при первой правке кода забыть про добавление константы и поймав assert в рантайме исправить код функции ни разу не подумав о том, что эта проверка была написана не просто так и без этой проверки код лежащий ниже assert'a незаметно работает с ошибкой...
_>Точно надо вставлять проверки с портянками констант — это же гениально и главное просто, и когда надо что-то исправить достаточно поменять во всех файла где такое уже умудрились написать.
Если на значение констант полагаются, то — да, везде при использовании должны быть проверки.

_>assert-ы должны проверять инварианты, которые должны быть описаны явно и в одном месте, а не раскиданы равномерно везде.
Для этого есть static_assert'ы
А обычные assert'ы я использую для проверки входных параметров функции для проверки предусловий.

_>>>Не нравятся функции вынесите в макрос
BFE>>Для меня наличие макросов означает низкое качество кода.
_>Ха ха ха. То что макросы досих пор есть, означает что их функционал пока нечем заменить.
Да, к сожалению, часто функционал нечем заменить и приходится писать руками.

_>Вы видели реальную кодовую базу без макросов?
Да.