людирекомендую#ifdef для условной компиляции с большим отрывом,ищи#ifdef обосновывает, что его использование широко распространено.

Все же#ifdef NAME (или эквивалентно#if defined(NAME) и связанные#ifndef NAME (а также#if !defined(NAME)) имеют серьезный недостаток:

header.h

#ifndef IS_SPECIAL
#error You're not special enough
#endif

source.cpp

#include "header.h"

gcc -DIS_SPECIAL source.cpp

пройдет, очевидно, как будет

source1.cpp

#define IS_SPECIAL 1
#include "header.h"

Но так будет

source0.cpp

#define IS_SPECIAL 0
#include "header.h"

что совершенно неправильно. И некоторые компиляторы C ++, передали файл, обработанный вC режим (из-за расширения или опции командной строки) эффективно делать#define __cplusplus 0, Я видел, как вещи ломаются, когда

#ifdef __cplusplus
extern "C" {
#endif
/* ... */
#ifdef __cplusplus
}
#endif

был обработан вC режим, гдеextern "C" неверный синтаксис, потому что__cplusplus на самом деле был автоматически определен для0.

С другой стороны, это работает правильно для всех компиляторов:

#if __cplusplus
extern "C" {
#endif
/* ... */
#if __cplusplus
}
#endif

Почему люди до сих пор используют#ifdef по этому сценарию? Они просто не знают, что#if отлично работает на неопределенных именах? Или жеесть ли реальный недостаток#if против#ifdef для условной компиляции?

Очевидно, что#ifdef действительно имеет допустимое использование, такое как предоставление значений по умолчанию для настраиваемых параметров:

#ifndef MAX_FILES
#define MAX_FILES 64
#endif

Я только обсуждаю случай тестирования флага.