использование 





Увидел этот код и завязалась дискуссия по поводу необходимости в этом случае (и вообще) использовать макрос(ы). 
Хотелось бы, чтобы ответы были аргументированы, ибо мои доводы противной стороной были отклонены.

Это сообщение отредактировал(а) Sahab - 19.4.2012, 17:49

предпочитаю вместо макросов использовать функции/шаблонные_функции.

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


Это сообщение отредактировал(а) boostcoder - 19.4.2012, 17:49

поправочка: речь шла не о "необходимости", а, скорее, "почему бы и нет?". Интересны в данном случае преимущества шаблонной функции перед макросом.
Уже есть, например, такие: 
1) дебагер не поймёт
2) надо контролировать во что раскроется макрос (флаг -E с выводом в файл)
3) макрос небезопасен (вот тут особенно интересно почему)


Это сообщение отредактировал(а) serghd - 19.4.2012, 17:43

По поводу этого я в принципе молчу, потому что если аргументироваться подобным, то можно такого говнеца наваять...

макросы только там где необходимо

Это сообщение отредактировал(а) mes - 19.4.2012, 17:55

как уже было замечено - непонятно во что он раскроется.
если же он раскроется так, что код все равно скомпилируется но при этом логика будет нарушена - то тут начнется самое интересное. и дебагер тут не поможет, ибо препроцессор весь код развернет в одну строку %)
второе - макросы работают заменой одних токенов, другими. можно с легкостью пересечь имена аргументов макроса с именами переменных в коде, и опять, имеем вынос моцга.

но основная непонятка заключается в том: зачем макрос при контекстной кодогенерации?

чтобы говнеца не ваять надо знать "ПОЧЕМУ то, а не это". Если объяснений нет, или они неубедительны, то "почему бы и нет".

Приведите хотя бы один положительный момент использования макроса в данном случае.

Добавлено через 5 минут и 48 секунд
Если для Вас неубедительным является "небезопасность" макросов. Что ж - вперед, и надеюсь не напоретесь на херню.

Из положительного. Если конкретно на этом примере, то, к примеру, переменную pos, которая на стеке, мне не надо никуда передавать. Она декларирована перед макросом и без проблем будет в рантайме изменена развёрнутым им кодом. То же самое и о status.

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



Это сообщение отредактировал(а) serghd - 19.4.2012, 20:15

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

ответил

шаблонные (или обычные) функции.
Странно, что никто не вспомнил о главном отличии - макросы не проверяют типы. В тот же microsoft'овский #define max можно отдать знаковую и беззнаковую переменную и, возможно, напороться на неприятность. С std::max такое не даст сделать компилятор.


Почему бы не передавать везде void* и кастить к тому, что хочешь по си-шному ?
Почему бы не выбрасывать исключения в деструкторе ?
Почему бы, если тебе сказали, что такая-то конструкция UB, не проверить, что на паре-тройке компиляторов всё работает и успокоиться ?
Почему бы не игнорировать warning'и ?

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

то есть, по-вашему, такая реализация правильнее/красивее/понятнее?:



...с кучей аргументов?...

Это сообщение отредактировал(а) serghd - 20.4.2012, 20:04

конечно правильней. ибо не зависит от контекста.
к тому же, код переусложнен.

в чём конкретно?