#pragma एक बार C++ 11 मानक का हिस्सा है?




c++11 macros (2)

मानक ( N3936 9 N3936 ड्राफ्ट) की धारा §16.6 #pragma निर्देशों का वर्णन करती है:

फॉर्म का प्रीप्रोसेसिंग निर्देश

# pragma pp-tokensopt new-line

क्रियान्वयन को कार्यान्वयन-परिभाषित तरीके से व्यवहार करने का कारण बनता है। व्यवहार अनुवाद को असफल होने का कारण बन सकता है या अनुवादक या परिणामी प्रोग्राम को गैर-अनुरूप तरीके से व्यवहार करने का कारण बन सकता है। कार्यान्वयन द्वारा मान्यता प्राप्त कोई भी प्रगति अनदेखा नहीं की जाती है।

असल में #pragma once #pragma निर्देश का कार्यान्वयन विशिष्ट उदाहरण है, और नहीं, यह मानक नहीं है। फिर भी।

इसे अक्सर GCC और Clang समेत अधिकांश "प्रमुख कंपाइलर्स" द्वारा व्यापक रूप से समर्थित किया जाता है और इसलिए कभी-कभी शामिल-गार्ड बॉयलरप्लेट से बचने के लिए अनुशंसा की जाती है।

परंपरागत रूप से, सी ++ में एकाधिक शीर्षलेख समावेशन से बचने के लिए मानक और पोर्टेबल तरीका #ifndef - #define - #endif प्री-कंपाइलर निर्देश योजना का उपयोग करना है जिसे मैक्रो-गार्ड योजना भी कहा जाता है (नीचे कोड स्निपेट देखें)।

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP
...
#endif

अधिकांश कार्यान्वयन / कंपाइलर्स में (नीचे चित्र देखें) हालांकि, एक और अधिक "सुरुचिपूर्ण" विकल्प है जो एक ही उद्देश्य की सेवा करता है जैसे मैक्रो-गार्ड योजना जिसे #pragma once कहा जाता है। #pragma once में मैक्रो-गार्ड योजना की तुलना में कई फायदे हैं, जिनमें कम कोड, नाम संघर्ष से बचने, और कभी-कभी संकलित गति में सुधार शामिल है।

कुछ शोध करते हुए, मुझे एहसास हुआ कि यद्यपि #pragma once निर्देश लगभग सभी ज्ञात कंपाइलर्स द्वारा समर्थित है, इस पर एक कठोरता है कि #pragma once निर्देश सी ++ 11 मानक का हिस्सा है या नहीं।

प्रशन:

  • क्या कोई स्पष्टीकरण दे सकता है कि #pragma once निर्देश सी ++ 11 मानक का हिस्सा है या नहीं?
  • यदि यह सी ++ 11 मानक का हिस्सा नहीं है, तो क्या बाद में रिलीज़ (उदाहरण के लिए, सी ++ 14 या बाद में) पर इसे शामिल करने की कोई योजना है?
  • यह भी अच्छा होगा अगर कोई भी तकनीक में से किसी एक का उपयोग करने के फायदे / नुकसान (यानी, मैक्रो-गार्ड बनाम #pragma once ) में आगे बढ़ सकता है।

#pragma once मानक नहीं है। यह एक व्यापक (लेकिन सार्वभौमिक नहीं) विस्तार है, जिसका उपयोग किया जा सकता है

  • यदि आपकी पोर्टेबिलिटी चिंताएं सीमित हैं, और
  • आप सुनिश्चित कर सकते हैं कि आपकी सभी फ़ाइलें शामिल हैं हमेशा स्थानीय डिस्क पर होती हैं।

इसे मानकीकरण के लिए माना जाता था, लेकिन अस्वीकार कर दिया गया क्योंकि इसे विश्वसनीय रूप से लागू नहीं किया जा सकता है। (समस्या तब होती है जब आपके पास कई अलग-अलग दूरस्थ माउंट्स के माध्यम से फ़ाइलों को सुलभ किया जाता है।)

यह सुनिश्चित करना काफी आसान है कि एक ही विकास में गार्ड संघर्ष शामिल नहीं हैं। पुस्तकालयों के लिए, जिनका उपयोग कई अलग-अलग विकासों द्वारा किया जा सकता है, स्पष्ट समाधान यह है कि जब आप इसे बनाते हैं तो गार्ड को शामिल करने के लिए बहुत सारे यादृच्छिक वर्ण उत्पन्न करना है। (जब भी आप कोई नया हेडर खोलते हैं तो एक अच्छा संपादक आपके लिए ऐसा करने के लिए स्थापित किया जा सकता है।) लेकिन इसके बिना भी, मुझे पुस्तकालयों के बीच संघर्ष के साथ अभी तक कोई समस्या नहीं आ रही है।





c++14