math.h macro collisioni

Question

Macro DOMAIN in matematica.h si scontra con enumerazioni e possibilmente con altri tipi. Non so cosa farmene.

#include <algorithm> 

enum Type { DOMAIN }; 


int main(){ 
    Type t = Type::DOMAIN; 
    return 0; 

} 

Compilare con flag -std = C++ 11. La versione C99 di questo codice viene compilato perfettamente bene però:

#include <algorithm> 

enum Type { DOMAIN }; 


int main(){ 
    Type t = DOMAIN; 
    return 0; 

} 

Ho controllato il codice sorgente e la biblioteca è da biasimare. algoritmo include stl_algo.h, in cui v'è ifdef:

#if __cplusplus >= 201103L 
#include <random>  // for std::uniform_int_distribution 
#include <functional> // for std::bind 
#endif 

Il seguente codice compila bene su C++ 11 compilatore:

#include <random> 
#include <iostream> 
int main(){ 
    std::cout << DOMAIN << std::endl; 
    return 0; 
} 

Si tratta di una caratteristica o un bug?

EDIT * fix sporca:

#ifdef DOMAIN 
#undef DOMAIN 
#endif 

Answer 1

È un bug (o una "verruca" se si vuole essere generosi).

Tutto il resto di questa risposta si riferisce solo a GCC e alle intestazioni della libreria C standard di Gnu. I riferimenti alle pagine man si riferiscono a un sistema Linux (ma ho aggiunto dei collegamenti a man7.org).

La macro DOMAIN viene fornita dal supporto System V math.h. (Vedere man matherr.) Il supporto del sistema V è normalmente abilitato definendo la macro del test delle funzioni _SVID_SOURCE (vedere man feature_test_macros), ma è abilitato insieme a una serie di altre estensioni se _GNU_SOURCE è definito o per impostazione predefinita se non sono definite macro di test delle funzionalità .

gcc pubblicitario predefinito _GNU_SOURCE per programmi C se l'opzione --std viene omesso o impostato a gnu##. Le varie opzioni --std=c## causano la definizione di __STRICT_ANSI__.Di conseguenza, la compilazione del codice C con alcuni standard C espliciti sopprimerà le estensioni System V. Questo deve essere fatto perché le estensioni del System V non sono compatibili con gli standard, nemmeno con Posix, perché inquinano lo spazio dei nomi globale. (DOMAIN è solo un esempio di questo inquinamento.)

Tuttavia, g++ definisce _GNU_SOURCE anche se --std=c++## è specificato, e di conseguenza le estensioni System V sarà furtivamente. (Grazie a @dyp per il collegamento a questo libstdc++ FAQ entry. e questo long and inconclusive discussion from 2001 on the GCC mailing list)

Un brutto soluzione è quella di impostare le funzioni di te stesso, e poi undefine __USE_SVID:

#include <features.h> 
#undef __USE_SVID 

#include <random> 
#include <iostream> 

int main(){ 
    std::cout << DOMAIN << std::endl; 
    return 0; 
} 

(Live on coliru)

IMHO, questo non dovrebbe essere necessario. Ma eccolo.

Answer 2

§ 17.6.5.2 [res.on.headers]/1 di N4140 dice:

A C++ intestazione può includere altre intestazioni C++. Un'intestazione C++ deve fornire le dichiarazioni e le definizioni che appaiono nella sua sinossi. Un'intestazione C++ mostrata nella sinossi come comprendente altri header C++ deve fornire le dichiarazioni e le definizioni che appaiono nelle sinossi di quelle altre intestazioni.

Pertanto, è valido per <algorithm> a #include <cmath> che inietta l'incriminato macro costante nel vostro spazio dei nomi.

Si noti, tuttavia, che il “quick fix e sporco” non è consentita dallo standard (§ 17.6.4.3.1 [macro.names]/1):

Un'unità di traduzione che include uno standard l'intestazione della libreria non deve essere #define o #undef nomi dichiarati in qualsiasi intestazione di libreria standard.

Dovrete scegliere un nome diverso da DOMAIN per il vostro enum costante.