объясните мне, пожалуйста, почему следует избегать макросов?
доводы из статьи по ссылке я встречал много раз.
меня они не убеждают и входят в противоречие с моим личным опытом.
я не претендую на звание эксперта по С++, но в своей работе я много работаю с кодом на этом языке.
специфика такая, что мне приходится работать со старым (10+ лет) и очень старым (20+ лет) кодом разного качества.
объясню своё непонимание на примере доводов из статьи по ссылке выше:
Основная проблема с макросами С++ заключается в том, что они выглядят гораздо привлекательнее, чем являются таковыми на самом деле. Макросы игнорируют области видимости, игнорируют прочие возможности и правила языка, и заменяют все символы, которые переопределяют при помощи директивы #define, до самого конца файла. Применение макросов внешне походит на имя или вызов функции, но не имеет с ними ничего общего. Макросы "негигиеничны", в том смысле, что они могут быть раскрыты неожиданно, причем превратиться в зависимости от контекста их использования в самые разные конструкции. Подстановка текста, выполняемая макросами, делает написание хотя бы в небольшой степени "приличного" макроса смесью искусства и черной магии.
да, написание годного макроса это действительно сложнее, чем кажется на первый взгляд.
и я согласен, что корявый макрос может быть причиной множества различных проблем с компиляцией кода.
однако, по моему опыту, навести порядок в макросах не так уж и сложно, здесь автор сильно драматизирует.
написать хороший макрос тоже не очень сложно.
на мой взгляд, хороший шаблонный код писать никак не проще.
понять концепцию текстовых замен, которые производятся препроцессором, гораздо проще, чем понять шаблоны С++.
Программисты, которые полагают, что тяжелее всего расшифровать ошибки, связанные с шаблонами, вероятно, просто никогда не имели дела с плохо написанными или неверно использованными макросами. Шаблоны являются частью системы типов С++, и тем самым позволяют компилятору куда лучше справляться с ними, чем с макросами, которые имеют мало общего с языком программирования. Хуже того, в отличие от шаблонов неверные макросы могут быть раскрыты в нечто, что в силу чистой случайности скомпилируется, не имея при этом никакого смысла. И наконец, ошибка в макросе обнаруживается только после того, как макрос раскрывается, а не при его определении.
по моему опыту, мне существенно больше проблем всегда доставлял тот код, который злоупотребляет шаблонами, нежели тот, который злоупотребляет макросами.
при переносе кода, широко использующего шаблоны, с одной версии компилятора на другую версию того же компилятора или с одного компилятора на другой проблемы с шаблонами возникают часто.
проблем же с макросами при смене компилятора я никогда не видел.
это что касается портирования на другие компиляторы, однако и при отладке кода макросы мне никогда особых проблем не доставляли.
в конце концов, макросы всегда можно раскрыть в нужной части кода и найти ошибку.
однако понять, что не так при ошибке компиляции иных шаблонов, особенно в компиляторах MSVC не самых свежих, мне гораздо сложнее, чем разобраться в коде с макросами.
при этом нет никакого средства, чтобы раскрыть шаблон и превратить его в нешаблонный код.
Здравствуйте, LuciferSaratov, Вы писали:
R>>А вот тебе про #define: 16. Избегайте макросов
LS>объясните мне, пожалуйста, почему следует избегать макросов? LS>доводы из статьи по ссылке я встречал много раз. LS>меня они не убеждают и входят в противоречие с моим личным опытом. LS>я не претендую на звание эксперта по С++, но в своей работе я много работаю с кодом на этом языке. LS>специфика такая, что мне приходится работать со старым (10+ лет) и очень старым (20+ лет) кодом разного качества.
"Избегайте" не означает же "полностью исключите". "Избегайте" означает, не употребляйте там, где без этого легко можно обойтись. Почему так — в статье написано достаточно хорошо, по-моему. Макросы не подчиняются правилам областей видимости, на функциональные макросы не распространяется ADL, для макросов нельзя использовать перегрузку и концепты и пр. Если статья не убеждает, то у меня тоже вряд ли получится.
Есть такие случаи, когда без макросов просто никак, например, описание разного рода типов со статической структурой. Использование макросов может придать таким описаниям очень приятный декларативный вид, легко изменяемый и расширяемый и избавить от написания громадного количества сопровождающего кода, такого как загрузка-выгрузка, сериализация-десериализация, операции разные — сравнения, сложения, вычитания, вывода-вывода и пр. Но это же не значит, что нужно начать повсеместно использовать макросы вместо констант и функций.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, LuciferSaratov, Вы писали:
LS>да, написание годного макроса это действительно сложнее, чем кажется на первый взгляд. LS>и я согласен, что корявый макрос может быть причиной множества различных проблем с компиляцией кода. LS>однако, по моему опыту, навести порядок в макросах не так уж и сложно, здесь автор сильно драматизирует. LS>написать хороший макрос тоже не очень сложно.
Порядок порядок подключения заголовочных файлов может очень сильно все поменять, как бы вы хорошо не писали.
LS>на мой взгляд, хороший шаблонный код писать никак не проще.
Зато он предсказуемей.
LS>понять концепцию текстовых замен, которые производятся препроцессором, гораздо проще, чем понять шаблоны С++.
Сложные задачи — сложные средства.
Здравствуйте, LuciferSaratov, Вы писали:
LS>однако, по моему опыту, навести порядок в макросах не так уж и сложно, здесь автор сильно драматизирует.
А как можно навести порядок в макросах?
Пример из практики: в проекте используются две сторонние библиотеки и обе из них определяют один и тот же define но в разные значения. Как разрешить коллизию?
LS>написать хороший макрос тоже не очень сложно. LS>на мой взгляд, хороший шаблонный код писать никак не проще. LS>понять концепцию текстовых замен, которые производятся препроцессором, гораздо проще, чем понять шаблоны С++.
Так вроде как макросы — это не вопрос сложности. Это скорее вопрос безопасности.
LS>по моему опыту, мне существенно больше проблем всегда доставлял тот код, который злоупотребляет шаблонами, нежели тот, который злоупотребляет макросами. LS>при переносе кода, широко использующего шаблоны, с одной версии компилятора на другую версию того же компилятора или с одного компилятора на другой проблемы с шаблонами возникают часто. LS>проблем же с макросами при смене компилятора я никогда не видел.
— ok для Linux, но на windows: ERROR — это дефайн в константу и код не скомпилируется (зависит от порядка includ'ов)
Ну и классика по функциям и дефайнам min и max, из-за чего декларация этих функций выглядит нестандартно под windows: отсюда
_EXPORT_STD template <class _Ty>
class numeric_limits : public _Num_base { // numeric limits for arbitrary type _Ty (say little or nothing)public:
_NODISCARD static constexpr _Ty(min)() noexcept { // Шеф! Шеф! Что это было!?return _Ty();
}
_NODISCARD static constexpr _Ty(max)() noexcept { // Шеф! Шеф! Что это было!?return _Ty();
}
_NODISCARD static constexpr _Ty lowest() noexcept {
return _Ty();
}
_NODISCARD static constexpr _Ty epsilon() noexcept {
return _Ty();
}
LS>это что касается портирования на другие компиляторы, однако и при отладке кода макросы мне никогда особых проблем не доставляли. LS>в конце концов, макросы всегда можно раскрыть в нужной части кода и найти ошибку.
Ага. Занятие часа на 4: вспомнить опцию компилятора, настроить переменные окружения, запустить компиляцию этого отдельного файла и по косвенным признакам найти результат подстановки...
LS>однако понять, что не так при ошибке компиляции иных шаблонов, особенно в компиляторах MSVC не самых свежих, мне гораздо сложнее, чем разобраться в коде с макросами. LS>при этом нет никакого средства, чтобы раскрыть шаблон и превратить его в нешаблонный код.
С шаблонами сложнее, но зато шаблоны — намного более мощный инструмент.
Здравствуйте, T4r4sB, Вы писали:
TB>Где гарантия, что результат будет вычислен при компиляции? Есть какой-то список операций, дающий гарантию?
Да, есть: consteval
Здравствуйте, wander, Вы писали:
W>Здравствуйте, rg45.
W>Зря ты с ним сцепился. У человека govnokod.ru из головы все никак не выветрится.
То есть ты считаешь, что неадекватное поведение рг45 это ок что ли?
Я вижу его сообщения в лучшем случае как " да как ты посмел уточнить то что я говорю и усомниться в полноте моих высказываний111", не так что ли?
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, T4r4sB, Вы писали:
TB>>Где гарантия, что результат будет вычислен при компиляции? Есть какой-то список операций, дающий гарантию? BFE>Да, есть: consteval
О боже, скольно ж там теперь видов констант, отличия которых поймет только гурман
Здравствуйте, Shmj, Вы писали:
S>Как я понимаю, старый стиль, когда константы определялись виде #define — деканонизировали и предали анафеме. Теперь есть constexpr.
S>Вообще зачем это нужно — можете ли пример привести?
Ты когда константы заводишь, как их описываешь?
Второе легче читается, плюс на consexpr можно нормально стиль использовать, ChunkSize, не боясь что макрос где то что то попортит, а дальше логика проста, есть зависимые константы которые хочется легко и понятно описать, чтобы их было можно легко и понятно поддерживать, и нужны уже функции времени компиляции.
S>Почему не использовать просто const, который времени выполнения?
Это разные вещи, const != consexpr, #define != constexpr. static не входит в constexpr, вот это кстати было удивительно узнать, почему по умолчанию consexpr это не static inline consexpr.
Здравствуйте, T4r4sB, Вы писали:
TB>То есть ты считаешь, что неадекватное поведение рг45 это ок что ли?
Я считаю, что неадекватно себя вести сначала начал ты.
Свое отношение к реакции рг45 на твой выпад в #12 (и особенно в #16) я уже высказал и получил от него адекватный ответ.
TB>Я вижу его сообщения в лучшем случае как " да как ты посмел уточнить то что я говорю и усомниться в полноте моих высказываний111", не так что ли?
Это только твое восприятие.
W>Свое отношение к реакции рг45 на твой выпад в #12 (и особенно в #16) я уже высказал и получил от него адекватный ответ.
Его хамство в re7 и re9 ты в упор не видишь? Или ему можно? Это твой друг что ли?
Адекватный ответ — это кукушка хвалит петуха за то что хвалит он кукушку?
Что не так в ре16? Я спокойно сказал что его фраза может быть понята неоднозначно с точки зрения норм русского языка, что тут блин не так?
Здравствуйте, T4r4sB, Вы писали:
TB>Его хамство в re7 и re9 ты в упор не видишь?
Там нет никакого хамства. TB>Или ему можно?
Нет, ему не можно. Но хамства там нет. TB>Это твой друг что ли?
Нет. Вообще ни разу. Мы за послоедние 10 лет едва ли парой фраз перекинулись и то только в этом разделе.
Просто ты несправедливо прикопался на ровном месте, вот я и среагировал.
TB>Адекватный ответ — это кукушка хвалит петуха за то что хвалит он кукушку?
Что?
Человек согласился, что зря ввязался в словесную перепалку с тобой.
Это адекватный ответ, потому что соответствует действительности.
Адекватный человек от неадекватного отличается как раз тем, что способен принять действительность.
TB>Что не так в ре16? Я спокойно сказал что его фраза может быть понята неоднозначно с точки зрения норм русского языка, что тут блин не так?
Вместо того, чтобы уточнить суть непонятного в словах оппонента, ты начинаешь упрекать его в неправильном применении норм русского языка.
Я уж помолчу о том, что никакой неоднозначности с точки зрения норм тут нет, это ладно.
