Google स्टाइल गाइड आगे की घोषणा को हतोत्साहित क्यों करता है?

Question

यह नहीं कहना कि Google स्टाइल गाइड पवित्र बाइबल है लेकिन एक नौसिखिया प्रोग्रामर के रूप में, यह एक अच्छा संदर्भ की तरह लगता है।

गूगल स्टाइल गाइड आगे घोषणा के निम्नलिखित नुकसान को सूचीबद्ध

1. आगे घोषणाओं निर्भरता को छुपा सकते हैं, आवश्यक रखता छोड़ जब हेडर बदलने के उपयोगकर्ता कोड की इजाजत दी।

2. लाइब्रेरी में आने वाले परिवर्तनों से आगे की घोषणा को तोड़ दिया जा सकता है। फ़ंक्शंस और टेम्पलेट्स की अग्रेषित घोषणाएं हेडर मालिकों को उनके एपीआई में अन्यथा-संगत परिवर्तन करने से रोक सकती हैं, जैसे कि पैरामीटर प्रकार को चौड़ा करना, डिफ़ॉल्ट मान के साथ टेम्पलेट पैरामीटर जोड़ना, या किसी नए नामस्थान में माइग्रेट करना।

3. नामस्थान std :: प्रतीकों को घोषित करने के लिए अग्रेषित अपरिभाषित व्यवहार पैदा करता है।

4. यह निर्धारित करना मुश्किल हो सकता है कि आगे की घोषणा या पूर्ण # समावेशन की आवश्यकता है या नहीं। एक आगे घोषणा के साथ एक # शामिल की जगह चुपचाप कोड के अर्थ बदल सकते हैं:

कोड:

// b.h: 
    struct B {}; 
    struct D : B {}; 

    // good_user.cc: 
    #include "b.h" 
    void f(B*); 
    void f(void*); 
    void test(D* x) { f(x); } // calls f(B*) 

# शामिल आगे से बदला गया तो बी और डी, परीक्षण के लिए decls() होगा कॉल एफ (शून्य *)।

5. आगे बढ़ने के लिए हेडर से एकाधिक प्रतीकों की घोषणा करना शीर्षलेख को शामिल करने से अधिक वर्बोज़ हो सकता है।

6. आगे की घोषणाओं को सक्षम करने के लिए संरचना कोड (उदाहरण के लिए ऑब्जेक्ट सदस्यों के बजाय पॉइंटर सदस्यों का उपयोग करके) कोड को धीमा और अधिक जटिल बना सकता है।

हालांकि, एसओ पर कुछ खोज यह सुझाव देती थी कि आगे की घोषणा सार्वभौमिक रूप से एक बेहतर समाधान है।

तो इन प्रतीत होता है कि गैर-मामूली नुकसान, क्या कोई इस विसंगति को समझा सकता है?

और इनमें से कुछ या सभी नुकसानों को अनदेखा करना कब सुरक्षित है?

Answer 1

एसओ पर कुछ खोज सुझाव देते हैं कि आगे की घोषणा सार्वभौमिक रूप से एक बेहतर समाधान है।

मुझे नहीं लगता कि यह वही कहता है। आपके द्वारा उद्धृत पाठ उचित फ़ाइल शामिल करने के खिलाफ "गुरिल्ला" आगे की घोषणा की तुलना कर रहा है। मुझे नहीं लगता कि Google इस दृष्टिकोण के लिए एसओ पर बहुत सपोर्ट पायेगा कि Google यहां आलोचना कर रहा है। वह बुरा दृष्टिकोण है, "नहीं, #include में फाइलें शामिल नहीं हैं, बस उन कुछ कार्यों और प्रकारों के लिए घोषणाएं लिखें जिन्हें आप उपयोग करना चाहते हैं"।

उचित फ़ाइल में अभी भी अपनी स्वयं की घोषणाएं शामिल होंगी, और एसओ पर एक खोज यह सुझाव देगी कि यह सही काम है, इसलिए मैं देखता हूं कि आपको यह कहां मिला कि एसओ घोषणाओं के पक्ष में है।लेकिन Google यह नहीं कह रहा है कि लाइब्रेरी की अपनी फ़ाइल में आगे की घोषणाएं नहीं होनी चाहिए, यह कह रही है कि आपको नकली नहीं होना चाहिए और प्रत्येक फ़ंक्शन या टाइप के लिए अपनी खुद की अग्रेषित घोषणा लिखना चाहिए।

आप सही #include अगर फ़ाइल, और अपने निर्माण श्रृंखला काम करता है, तो निर्भरता छुपी नहीं है और समस्याओं ज्यादातर लागू नहीं है के बाकी है, इस तथ्य शामिल है कि फाइल घोषणाओं में शामिल होने के बावजूद शामिल हैं। अभी भी कुछ कठिनाइयां हैं, लेकिन यह नहीं है कि Google यहां किस बारे में बात कर रहा है।

प्रकार के आगे घोषणाओं पर विशेष रूप से देख रहे हैं उनके लिए वर्ग परिभाषा के साथ तुलना में, (4) कि, गलत (D के आगे घोषणा के बाद से जा रहा व्यक्त नहीं कर सकते कि यह B से ली गई है कि के लिए आप की जरूरत का एक उदाहरण देता है कक्षा परिभाषा)। "पिंपल" नामक एक तकनीक भी है जो सावधानीपूर्वक किसी विशेष उद्देश्य के लिए अग्रेषित प्रकार की घोषणा का उपयोग करती है। तो फिर आप इसके लिए SO पर कुछ समर्थन देखेंगे, लेकिन यह इस विचार का समर्थन करने जैसा नहीं है कि हर कोई सामान्य रूप से #include की बजाय हेडर फ़ाइलों को इंगित करने के बजाय कक्षाओं को आगे घोषित करना चाहिए।

Answer 2

टाइटस विंटर्स 'CppCon 2014 talk से:

बड़ा एक है कि हम हाल ही में सीखा है है: आगे उस में एक टेम्पलेट के साथ कुछ भी घोषित वास्तव में बुरा विचार है। इसने रखरखाव की समस्याओं को जन्म दिया जैसे आप विश्वास नहीं करेंगे। अग्रेषित घोषणा ठीक है, में मामलों में ठीक है? मेरा संदेह यह है कि नियम वास्तव में बदल रहा है: लाइब्रेरी मालिकों को एक ऐसा हेडर प्रदान करने के लिए प्रोत्साहित किया जाता है जो विशेष रूप से उन चीजों को घोषित करता है जो उन्हें लगता है कि वे (जोर दिया गया है), और आपको शायद खुद को घोषित नहीं करना चाहिए, और आपको खुद को घोषित नहीं करना चाहिए, किसी को कभी भी एक टेम्पलेट प्रकार घोषित नहीं करना चाहिए। हम देखेंगे। हम अभी भी जो सीख चुके हैं उससे [अश्रव्य] विवरण निकाल रहे हैं।

तो हो सकता है कि टेम्पलेट प्रकारों की घोषणा सीधे आगे बढ़ाने की कोशिश करने के साथ समस्याएं आगे की घोषणा थोक को हतोत्साहित करने के अपने उद्देश्यों में से एक हो ...? के रूप में वर्णित here (समाधान 2.2), here, और here

इसके अलावा, "एक ऐसा हेडर विशेष रूप से आगे बातें उन्हें लगता है कि इसके लायक हैं वाणी" उपलब्ध कराने के रास्ते <iosfwd> के समान प्रयोग किया जाता है लगता है,।

---

संपादित करें:

स्पष्ट रूप से, मैं यह नहीं कह रहा था मैं सहमत हूं या आगे घोषणा की गूगल की निराशा से असहमत हैं। मैं बस अपने तर्क को समझने की कोशिश कर रहा था, और <iosfwd> के बारे में एक तरफ/अवलोकन किया।

व्यक्तिगत रूप से, मैं घोषणाओं आगे का उपयोग जब भी मैं कर सकते हैं, दिशानिर्देश है कि एक ही GOTW (समाधान 3) ऊपर लिंक में बाद में कहा निम्नलिखित:

दिशानिर्देश: कभी नहीं #include एक हैडर जब एक आगे घोषणा पर्याप्त होगा।

लेकिन विंटर के तर्क में कुछ योग्यता भी प्रतीत होती है।मैंने कोड पर काम किया है जहां मैंने तृतीय पक्ष लाइब्रेरी से टेम्पलेट प्रकारों को घोषित किया है, और सिंटैक्स गन्दा हो जाता है (मैंने अभी तक रखरखाव की समस्याओं में भाग नहीं लिया है)। OTOH, मैं सभी आगे घोषणाओं के रूप में गूगल सी ++ स्टाइल गाइड में कहा गया है हतोत्साहित बारे में इतना यकीन नहीं कर रहा हूँ, लेकिन मुझे लगता है कि है कि क्या गूगल के लिए काम करता है?

अस्वीकरण: मैं कोई विशेषज्ञ, अभी भी सीख रहा हूँ।