Czy #pragma jest kiedyś częścią standardu C ++ 11?

Tradycyjnie, standardowym i przenośnym sposobem uniknięcia wielu włączeń nagłówków w C ++ było / jest użycie #ifndef - #define - #endifschematu dyrektyw prekompilatora, zwanego również schematem ochrony makr (zobacz fragment kodu poniżej).

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP
...
#endif

Jednak w większości implementacji / kompilatorów (patrz rysunek poniżej) istnieje bardziej „elegancka” alternatywa, która służy temu samemu celowi, co schemat ochrony makro #pragma once. #pragma oncema kilka zalet w porównaniu ze schematem ochrony makr, w tym mniej kodu, unikanie kolizji nazw, a czasami poprawioną szybkość kompilacji.

Po przeprowadzeniu pewnych badań zdałem sobie sprawę, że chociaż #pragma oncedyrektywa jest obsługiwana przez prawie wszystkie znane kompilatory, istnieje niejasność dotycząca tego, czy #pragma oncedyrektywa jest częścią standardu C ++ 11, czy nie.

Pytania:

• Czy ktoś mógłby wyjaśnić, czy #pragma oncedyrektywa jest częścią standardu C ++ 11, czy nie?
• Jeśli nie jest częścią standardu C ++ 11, czy są jakieś plany włączenia go w późniejszych wersjach (np. C ++ 14 lub nowszych)?
• Byłoby również miło, gdyby ktoś mógł bardziej szczegółowo omówić zalety / wady stosowania którejkolwiek z technik (tj. Makroostrożność kontra #pragma once).

#pragma oncenie jest standardem. Jest to szeroko rozpowszechnione (ale nie uniwersalne) rozszerzenie, z którego można korzystać

• jeśli Twoje obawy dotyczące przenoszenia są ograniczone, i
• możesz być pewien, że wszystkie pliki dołączane są zawsze na dysku lokalnym.

Był brany pod uwagę pod kątem normalizacji, ale odrzucony, ponieważ nie można go niezawodnie wdrożyć. (Problemy występują, gdy masz pliki dostępne przez kilka różnych zdalnych montowań).

Dość łatwo jest upewnić się, że nie ma konfliktów włączania zabezpieczeń w ramach jednego rozwoju. W przypadku bibliotek, które mogą być używane przez wiele różnych programów, oczywistym rozwiązaniem jest wygenerowanie wielu losowych znaków dla funkcji włączania strażnika podczas jej tworzenia. (Można ustawić dobry edytor, który zrobi to za Ciebie za każdym razem, gdy otworzysz nowy nagłówek.) Ale nawet bez tego nie napotkałem jeszcze żadnych problemów z konfliktami między bibliotekami.

Sekcja §16.6 normy ( projekt N3936 ) opisuje #pragmadyrektywy jako:

Dyrektywa wstępnego przetwarzania formularza

# pragma pp-tokensopt new-line

powoduje, że implementacja zachowuje się w sposób zdefiniowany przez implementację. Takie zachowanie może spowodować niepowodzenie tłumaczenia lub spowodować, że tłumacz lub wynikowy program zachowa się w sposób niezgodny. Każda pragma, która nie została rozpoznana przez implementację, jest ignorowana.

Zasadniczo #pragma oncejest to instancja #pragmadyrektywy specyficzna dla implementacji i nie, nie jest to standard. Jeszcze.

Często jest szeroko obsługiwany przez większość "głównych kompilatorów", w tym GCC i Clang, dlatego czasami zaleca się unikanie standardowej wersji include-guards.