можно обойтись.
Я опять без конкретики, но подойдёт любой пример, в котором используется #error, но без этого #error код бы вполне скомпилировался. error — для случаев, когда разработчик уверен, что скомпилированный код окажется неработоспособен, а warning — для случаев, когда код "скорее всего" будет неработоспособен.
Почему бы не поставить #error? Для того, чтобы не ломать весь проект почём зря.
Давайте попробую изобразить более правдоподобный пример. Разрабатывается драйвер для какого-то устройства (да-да, раз до сих пор как-то без этого жили, то могут жить и дальше, но ведь когда-то и без [[deprecated]] жили).
В зависимости от версии устройства требуется различный код инициализации, основной работы, управления питанием устройства и т.д.
Как разработчик драйвера, я хочу получать предупреждения в каждом устройство-специфичном месте при компиляции с новой версией/моделью устройства.
Вот приносят мне новую модель, я добавляю соответствующие define и хочу с одной стороны — скомпилировать код (в качестве fallback возможно использование кода для последней реализованной версии устройства), а с другой — видеть все предупреждения, потому что по-правильному я должен добавить хотя бы пустые #ifdef для новой модели.
В общем, #warning — ещё одно средство диагностики (которой много не бывает). Для организации чего-то вроде enumeration value not handled in switch. Сейчас на это часто #error ставят, независимо от фактической критичности места.
Ну вот, условно, в Qt вместо
#error "Qt has not been tested with this compiler"
мог быть просто warning.
https://code.woboq.org/qt5/qtbase/src/corelib/global/qcompilerdetection.h.html#505
последнее очень тонкий момент: как платному суппорту реагировать на обращение "почему я скомпилировал Qt, а программа не работает"? А вы видели ворнинг?
Обсуждают сегодня