Esistono due separatori di percorso di uso comune:la barra in avanti Unix e la barra inversa DOS. Riposa in pace, colon Mac classico. Se utilizzati in una direttiva #include, sono uguali secondo le regole degli standard C++11, C++03 e C99?
Risposte:
C99 dice (§6.4.7/3):
C++03 dice (§2.8/2):
C++11 dice (§2.9/2):
Pertanto, sebbene qualsiasi compilatore possa scegliere di supportare una barra rovesciata in un #include percorso, è improbabile che un fornitore di compilatori non supporti la barra in avanti, ed è probabile che le barre inverse facciano scattare alcune implementazioni in virtù della formazione di codici di escape. (Modifica:apparentemente MSVC in precedenza richiedeva una barra rovesciata. Forse altri su piattaforme derivate da DOS erano simili. Hmmm... cosa posso dire.)
C++11 sembra per allentare le regole, ma "supportato condizionalmente" non è significativamente migliore di "causa un comportamento indefinito". La modifica fa più per riflettere l'esistenza di alcuni compilatori popolari che per descrivere uno standard portatile.
Naturalmente, nulla in nessuno di questi standard dice che esistano dei percorsi. Ci ci sono filesystem là fuori senza alcun percorso! Tuttavia, molte librerie assumono nomi di percorso, inclusi POSIX e Boost, quindi è ragionevole volere un modo portatile per fare riferimento ai file all'interno di sottodirectory.