अभ्यास

Question

आम से मेरा उपयोगिता मतलब नहीं है, मैं एक ऐसा हेडर enums कि कई प्रकार के उपयोग करना चाहते हैं रखती है, आदि

उदाहरण के लिए, इसका मतलब यह कई प्रकार के एक Color हो सकता है अगर , जो एक enum है, आप इसे उपलब्ध करना चाहते हैं। कुछ लोग इसे कक्षा में डाल देंगे कि यह "सर्वोत्तम के साथ फिट बैठता है", लेकिन यह हेडर निर्भरता के मुद्दों को बना सकता है।

मैं वास्तव में ऐसे शीर्षलेख बनाने में नापसंद करता हूं जिसमें इस तरह की चीजें हैं, क्योंकि ऐसा लगता है कि यह कोड को और अधिक जटिल बनाता है। मैं दूसरों के विचारों की तलाश में हूं कि इस तरह की स्थिति में चलने पर वे किस तकनीक को नियोजित करते हैं। यदि वे "सामान्य" शीर्षलेख का उपयोग करते हैं, आदि

Answer 1

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

typedef unsigned char uint8; 
typedef signed char int8; 
typedef unsigned char uint08; 
typedef signed char int08; 
typedef unsigned short uint16; 
typedef signed short int16; 
typedef unsigned int uint32; 
typedef signed int int32; 
typedef unsigned long long uint64; 
typedef signed long long int64; 
typedef const char cchar; 
typedef const bool cbool; 
typedef char Byte; 

#ifdef ASSERT 
/* Re-defining assert */ 
#undef ASSERT 
#endif 

#ifdef DEBUG 
#ifndef ASSERTIONS 
#define ASSERTIONS 
#endif 
#endif 

#define ASSERT_ALWAYS(Expression) if (!(Expression)) FatalError(ErrorInfo("Assertion Failure", #Expression, FUNCTION_NAME, __FILE__, __LINE__)) 

#ifdef ASSERTIONS 
#ifdef DEBUG 
#define ASSERT(Expression) ASSERT_ALWAYS(Expression) 
#else 
#define ASSERT(Expression) if (!(Expression)) ErrorLog("[Release Assertions]: The following assertion failed: " # Expression) 
#endif 
#else 
#define ASSERT(Expression) 
#endif 

Answer 2

सामान्य हेडर ठीक है जब तक कि आपके प्रोजेक्ट पर काम करने वाले कुछ लोग ही नहीं हैं। एक बार जब आपके पास 20+ लोग उस फ़ाइल को संपादित करते हैं और आगे और बाद में विलय बदलते हैं, तो आपको एक दुःस्वप्न होना शुरू हो जाता है।

शायद एक विकल्प color.h या common/color.h फ़ाइल होगी, जो आपकी फ़ाइलों पर कुछ संरचना लागू करेगा।

Answer 3

IMO आम हेडर अच्छा अभ्यास अगर तुम उन्हें चीजें हैं जो शायद ही कभी बदलने युक्त करने के लिए प्रतिबंधित कर रहे हैं:

उदाहरण के लिए, यहाँ मेरी Common.h से दो अंश हैं

typedef unsigned int UINT32; 

यदि आप स्वयं को इस फ़ाइल को बहुत अधिक संपादित करते हैं, तो आपके पास इसमें सामान है जो वहां से संबंधित नहीं है।

Answer 4

व्यक्तिगत रूप से मैं एक प्रशंसक नहीं हूं।

1. मैं मतलब है कि आप एक निरंतर (या प्रकार) को संशोधित जब कि केवल एक ही स्थान पर प्रयोग किया जाता है, आप अपने पूरे परियोजना पुनः संकलित की जरूरत है।
2. निरंतर (या प्रकार की परिभाषा) का मूल्य और निरंतर निरंतर (या प्रकार) का उपयोग दो अलग-अलग स्थानों में होता है।

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

निरंतर या प्रकार का व्यापक रूप से उपयोग किया जाता है या यदि निरंतर या प्रकार मॉड्यूल में साझा किया जाता है तो स्थिर शीर्षलेख फ़ाइल के लिए एक मामला है।

Answer 5

यदि आप 'वैश्विक' enums चाहते हैं तो उन्हें वैश्विक नामस्थान प्रदूषित करने के बजाय उन्हें अपने नामस्थान में रखें, उदा।:

// Types.h 

namespace MyTypes 
{ 
    enum Color 
    { 
     RED, 
     BLUE, 
     GREEN, 
    }; 
} 

व्यक्तिगत रूप से मैं कक्षा के साथ जुड़े एनमों को रखना पसंद करता हूं लेकिन वाईएमएमवी।

Answer 6

मैं प्रत्येक सीपीपी फ़ाइल की आवश्यकता के बारे में स्पष्ट होना पसंद करता हूं। मुझे लगता है कि यह लंबे समय तक आसान है और यह 'आम' हेडर को फ़ाइलों को पुनर्निर्मित करने से रोकता है जब उन्हें होने की आवश्यकता नहीं होती है। एक परियोजना बढ़ने के साथ, सख्त 'केवल वही शामिल है जो आपको चाहिए' नीति बनाने के समय को बनाए रखने में मदद कर सकती है। जब आप शुरुआत में एक नई कक्षा बना रहे हैं तो इसका मूल्य थोड़ा सा विचार है। मेरे पास अक्सर एक सिंगल एनम या टाइपपीफ के लिए हेडर फाइलें होती हैं और मैं एक विशेष बिल्ड कॉन्फ़िगरेशन के रूप में भी जाता हूं जो प्रीकंपिल्ड हेडर के बिना बनाता है और (जब से मैं विजुअल स्टूडियो के साथ काम करता हूं) #pragma hdrstop का उपयोग करता हूं ताकि प्रत्येक फाइल होने के बजाय मेरे प्रीकंपील्ड हेडर को परिभाषित किया जा सके। इस उद्देश्य के लिए एक आम फ़ाइल शामिल करने की आवश्यकता है।

वर्षों से मुझे बिल्ड समय को कम रखने और कोड को पुस्तकालयों में या अन्य परियोजनाओं में फैलाने की अनुमति देने के लिए बहुत अच्छी तरह से काम करने के लिए यह पाया गया है या परीक्षण harnesses के लिए बनाया गया है।

मैं आम हेडर को अनावश्यक युग्मन के रूप में देखता हूं जिसे हटाया जाना चाहिए और ईमानदार होना, आलस्य का संकेत और विस्तार पर ध्यान देने की कमी।