आप अपने एसटीएल हेडर कैसे व्यवस्थित करते हैं?

Question

मैं एक बड़ी परियोजना पर काम कर रहा हूं जो एसटीएल का उपयोग करता है और आपके एसटीएल #includes को व्यवस्थित करने के आपके पसंदीदा तरीके के बारे में एक प्रश्न है।

• क्या आप उस स्रोत फ़ाइल में प्रत्येक शीर्षलेख को शामिल करना पसंद करते हैं। उदाहरण के लिए, यदि foo.cpp और bar.cpp दोनों std::string की आवश्यकता है, तो दोनों #include <string> होंगे।
• आप (अर्थात उन्हें एमएस 'stdafx.h' पूर्व संकलित हैडर के लिए जोड़) को एक ही हेडर फाइल है कि सभी एसटीएल हेडर अपनी परियोजना का उपयोग करता है शामिल किया जाना पसंद करते हैं।

पहली विधि का लाभ यह है कि .cpp फ़ाइल एक स्वतंत्र इकाई है और यह चिंता किए बिना एक अलग परियोजना में उपयोग किया जा सकता है कि आप #include खो रहे हैं। दूसरी विधि के फायदे यह है कि आप अपने कंपाइलर्स प्री-कंपाइल हेडर सपोर्ट का उपयोग कर सकते हैं और आप pragmas में एसटीएल #includes को लपेट सकते हैं जो कुछ चेतावनियों को अक्षम करता है (उदाहरण के लिए, कुछ बूस्ट हेडर स्तर 4 पर संकलन करते समय चेतावनियां पैदा करेंगे)।

आप किस का उपयोग करना पसंद करते हैं?

Answer 1

मैं केवल हेडर फाइल है कि वास्तव में हर स्रोत में की जरूरत है, और नहीं हेडर 'सभी को पकड़ने', यथासंभव कम निर्भरता रखने के लिए (और इसलिए बार संकलन) शामिल हैं।

प्रीकंपिल्ड हेडर इस के बावजूद काम कर सकते हैं (यानी मैं संकलन प्रक्रिया को तेज करने के लिए प्रीकंपिल्ड हेडर पर भरोसा करता हूं, न कि घोषणाएं प्राप्त करने के लिए)। इसलिए अगर कुछ प्रीकंपील्ड हेडर के माध्यम से कुछ घोषित किया जाता है, तो भी मुझे 'नियमित' हेडर शामिल होता है, जो गार्ड तंत्र शामिल हो जाएगा और संकलन समय में कुछ भी महत्वपूर्ण नहीं जोड़ देगा।

प्रीकंपिल्ड हेडर एक कंपाइलर विशिष्ट चीज हैं। प्रीकंपिल्ड हेडर को अनुकूलित/बदलने से मेरी राय में कोड के सही कामकाज पर कोई प्रभाव नहीं पड़ेगा।

संभव के रूप में कम के रूप में निर्भरता होने का मुख्य लाभ यह है कि रिफैक्टरिंग आसान हो जाता है (या बल्कि: संभव) है

यह सब पर महान पुस्तक Large Scale C++ Design from Lakos

Answer 2

पूरी तरह से जॉन Lakos की किताब बड़े के लिए सुझाव से सहमत है स्केल सी ++ डिजाइन।

प्रचार सब हेडर एक फ़ाइल के लिए आवश्यक है, चाहे ज या सीपीपी, फ़ाइल अपने आप में। अन्य शीर्षलेख फ़ाइलों द्वारा शामिल फ़ाइलों के साइड इफेक्ट्स पर भरोसा न करें।

एक बड़े हेडर फाइल सभी लिस्टिंग के बाद बढ़ जाती है निर्भरता अनावश्यक रूप से शामिल है और डिजाइन बहुत भंगुर बनाता है।

ओह, एक और चीज कभी हेडर फ़ाइल में घोषणाओं का उपयोग नहीं कर रही है। केवल अपनी कार्यान्वयन फ़ाइलों, .cpp फ़ाइलों में उन्हें कभी भी उपयोग करें।

एचटीएच।

चियर्स,

रोब

Answer 3

मुझे क्या सभी एसटीएल हेडर मैं अपने एकल precompiled header में पूरी परियोजना में आवश्यकता पड़ने वाली है, आम तौर पर डिफ़ॉल्ट Stdafx.h शामिल है। एक प्रीकंपिल्ड हेडर एक परियोजना में स्थापित होने वाली डी-फैक्टो पहली चीज है, जिसमें सभी एसटीएल-/बूस्ट-/प्लेटफार्म हेडर और थर्ड पार्टी लाइब्रेरी शामिल हैं।

एसटीएल & बूस्ट नामस्थानों में व्यवस्थित ढंग से व्यवस्थित होते हैं, इसलिए वे कभी भी मिश्रण-अप या ओवरलैप नहीं करते हैं।

हेडर में मैं आमतौर पर पूर्ण नामों का उपयोग करता हूं, लेकिन स्रोत फ़ाइलों में नामस्थान x का उपयोग करते समय उचित होता है।

Answer 4

आप इन दोनों तरीकों को जोड़ सकते हैं:

दोनों सीपीपी है - फ़ाइलों में शामिल हैं, और यह भी Stdafx.h में जोड़ें। यह आपको अभी भी पीएचसी अनुकूलन देगा।

.cpp - फ़ाइल को अभी भी "stdafx.h" शामिल करना होगा, इसलिए इसकी स्वतंत्रता बहस योग्य है। हालांकि, निर्भरता राज्य स्पष्ट रूप से है, और stdafx.h को हटाने में सभी लापता शामिलों को ढूंढने से सरल है। इसके अलावा, मानक शीर्षलेख - जैसा कि सभी शीर्षकों को चाहिए - सुनिश्चित करें कि उन्हें दो बार शामिल नहीं किया गया है।

---

आम तौर पर, मैं अपने दृष्टिकोण से सहमत "स्वतंत्र" जब सीपीपी एक अन्य परियोजना में जोड़ा जाता है, या एक ज शामिल किया गया है प्रत्येक फ़ाइल बनाने के लिए, जैसे कि, यह अपने निर्भरता का ख्याल रखता है।

---

याद रखें कि एक पीसीएच एक ट्रेडऑफ है, वे विशाल हो सकते हैं। पीसीएच में अधिकतर अप्रयुक्त कोड होने से वास्तव में आपके निर्माण में धीमा हो सकता है। फास्ट डिस्क बहुत मदद करते हैं, हालांकि :)

यह भी ध्यान रखें कि कम से कम कुछ संस्करणों में एमएसवीसी में प्रीकंपिल्ड हेडर सक्षम करने से वास्तव में प्रसंस्करण बदल जाती है: #include "stdafx.h" से पहले घोषणाओं को अनदेखा किया जाता है, इसलिए इसकी आवश्यकता है आपका पहला गैर-टिप्पणी कथन बनें। बदसूरत pitfall।