У меня нет заявления гуру относительно использования директив препроцессора, и я не могу добавить ссылку на известную. Но я хочу дать вам ссылку на простой пример, который можно найти на Microsoft MSDN .
#define A
#undef B
class C
{
#if A
void F() {}
#else
void G() {}
#endif
#if B
void H() {}
#else
void I() {}
#endif
}
Это приведет к простому
class C
{
void F() {}
void I() {}
}
и я думаю, что это не очень легко читать, потому что вы должны посмотреть вверху, чтобы увидеть, что именно определено в этой точке. Это становится более сложным, если вы определили это в другом месте.
Для меня выглядит намного проще создавать различные реализации и
вставлять их в вызывающую программу вместо переключения определений для создания «новых» определений классов. (... и поэтому я понимаю, почему вы сравниваете использование определений препроцессора с использованием IoC). Помимо ужасной читабельности кода с использованием инструкций препроцессора, я редко использовал определения препроцессора, потому что они увеличивают сложность тестирования вашего кода, потому что они приводят к нескольким путям (но это также проблема внедрения нескольких реализаций внешним IoC-контейнером).
Microsoft сама использовала множество определений препроцессора в API win32, и вы могли бы знать / помнить ужасное переключение между вызовами методов char и w_char.
Может быть, вам не следует говорить «Не используйте это». Скажите им, «Как использовать это» и «Когда использовать это» вместо этого. Я думаю, что все согласятся с вами, если вы предложите хорошие (более понятные) альтернативы и сможете описать риски, связанные с использованием препроцессорных определений / makros.
Нет необходимости в гуру ... просто будьте гуру. ; -)