C/C++ समारोह/विधि सजावट

अस्वीकरण: मैं नहीं सी ++ कुछ समय के लिए किया है ...C/C++ समारोह/विधि सजावट

यह आजकल पठनीयता में सुधार के लिए C/C++ समारोह/विधि घोषणाओं को सजाने के लिए आम है?

क्रूड उदाहरण:

void some_function(IN int param1, OUT char **param2);

मैक्रो में और बाहर एक खाली शरीर के साथ परिभाषित साथ
(अर्थात हल्के प्रलेखन यदि इस उदाहरण में आप करेंगे)। बेशक मैं समझता हूं कि यह विधि/समारोह से जुड़े "डॉक्टर टिप्पणी ब्लॉक" के साथ समानांतर में कुछ हद तक चला जाता है।

क्या आप कुछ अन्य उदाहरण प्रदान कर सकते हैं ... यह मानते हुए कि यह विषय समुदाय के लिए उपयोगी है। कृपया ध्यान रखें कि उपरोक्त उदाहरण यह है कि यह क्या है।

स्रोत

2009-10-29 jldupont

मुझे लगता है कि 'const * कीवर्ड के साथ आईएनएस * चिह्नित करना बेहतर है। –

यक! भावी रखरखाव करना इस जानकारी को सिर्फ एक टिप्पणी में रखने के बजाय बेकार मैक्रो दिखाना है? अन्य मौजूदा मैक्रोज़ के साथ हस्तक्षेप जोखिम? जी नहीं, धन्यवाद! – ctd

@ निक डी, कभी-कभी आप छोटे पैरामीटर 'प्रकार एफ (प्रकार मान) {value.op() के रूप में IN पैरामीटर के मान द्वारा गैर-कॉन्स पास का उपयोग करना चाहते हैं; प्रतिलाभ की मात्रा; } 'यह संकलक न केवल वापसी मूल्य प्रति को विस्तारित करने की अनुमति देता है बल्कि इनपुट प्रतियों का निर्माण भी करता है यदि उत्तीर्ण तर्क एक अस्थायी है। –

मैं इस तरह की सजावट की सराहना नहीं करता।

बहुत बेहतर की तरह में

void some_function(AClass const &param1, AnotherClass &param2)

आमतौर पर Int मान द्वारा और नहीं पारित कर रहे हैं संदर्भ द्वारा स्थिरांक और संदर्भ और निरंतर संदर्भ, उपयोग करने के लिए, तो मैं उदाहरण के लिए Aclass और AnotherClass इस्तेमाल किया। ऐसा लगता है कि एम्पी इन और आउट जोड़ना विचलित होगा।

स्रोत

2009-10-29 19:28:21 Francesco

मैंने इसे पहले नहीं देखा है। मुझे लगता है कि टिप्पणियों में इस तरह की जानकारी डालना बेहतर होगा।

स्रोत

2009-10-29 19:27:19

मैं इस्तेमाल करने की कोशिश: इनपुट पैरामीटर या संदर्भ के लिए

मान अगर वे बड़ा बाहर मापदंडों के लिए
संदर्भ हैं
प्वाइंटर बुलाया कार्य करने के लिए स्वामित्व देने के लिए

अधिकांश समय वास्तव में देखना आसान है कि कौन से या आउट पैरामीटर हैं, निश्चित रूप से घोषणा में उचित नाम एक अच्छा दस्तावेज हैं।

मुझे उन लोगों को लगता है, जो एडॉन्स परेशान करते हैं।

स्रोत

2009-10-29 19:28:30

सी ++ में

नहीं, मैं सी प्रोग्रामिंग पेशेवर नहीं किया है लेकिन कम से कम C++ मापदंडों के प्रकार आत्म व्याख्यात्मक है:

void f(std::string const &); // input parameter 
void f(std::string);   // input parameter again (by value) 
void f(std::string&);  // in/out parameter 
std::string f();    // output

कि एक साथ इन-कोड का दस्तावेजीकरण उपकरण (Doxygen) जहां के साथ पैरामीटर में कुछ संदर्भ जोड़ें (फ़ंक्शन द्वारा कौन से मान अपेक्षित हैं या अस्वीकार्य हैं, फ़ंक्शन कैसे ऑब्जेक्ट्स में पास किए जाते हैं ...

पॉइंटर्स के बारे में: हम अपने विधि इंटरफेस में कच्चे पॉइंटर्स को सीमित करते हैं। आवश्यकता होने पर , उनका उपयोग किया जा सकता है, लेकिन सामान्य स्मार्ट पॉइंटर्स को प्राथमिकता दी जानी चाहिए। फिर फिर, स्वामित्व अर्थशास्त्र choic से आते हैं स्मार्ट पॉइंटर का ई: shared_ptr <> पतला साझा ज़िम्मेदारी (या जब आवश्यक हो) के लिए, auto_ptr <>/unique_ptr <> एकल स्वामित्व के लिए (आमतौर पर कारखानों, स्थानीय या सदस्य विशेषताओं से वापसी मूल्य के रूप में) ...

स्रोत

2009-10-29 19:33:02

'टी &' दोनों "बाहर" और "इन/आउट" हो सकते हैं, हालांकि। –

हां, लेकिन यह पूरी तरह से निर्मित वस्तु होना चाहिए, इसलिए यह 'पूरी तरह से' बाहर नहीं है। मैं उन्हें देखता हूं (यह सिर्फ मुझे, एक आम जमीन नहीं है) इन/आउट पैरामीटर के रूप में चाहे वे संसाधित/पढ़े जाएं या नहीं। स्वीकार्य होने पर, मुझे संदर्भ द्वारा प्राप्त तर्क के लिए स्पष्टीकरण की आवश्यकता होगी जिसका कोड कोड समीक्षा में फ़ंक्शन के अंदर उपयोग नहीं किया जाता है। स्थान जहां यह स्वीकार्य है: कच्चे बफर (स्मृति के एक ब्लॉक के लिए सूचक) लौटने वाला एक फ़ंक्शन जो पैरामीटर के रूप में पारित आकार को अपडेट करता है (केवल * बाद में * वास्तव में * एक सुरक्षित निर्माण का उपयोग न करने के लिए उचित *) या आवश्यकता होने पर अनुकूलन के रूप में –

मैंने इसे देखा है, लेकिन मुझे नहीं लगता कि मैं कहूंगा कि यह "सामान्य" है।

Win32 एपीआई (सी नहीं सी ++) कुछ इसी तरह का उपयोग करता है:

WINADVAPI 
BOOL 
WINAPI 
CreateProcessWithLogonW(
    __in  LPCWSTR lpUsername, 
    __in_opt LPCWSTR lpDomain, 
    __in  LPCWSTR lpPassword, 
    __in  DWORD dwLogonFlags, 
    __in_opt LPCWSTR lpApplicationName, 
    __inout_opt LPWSTR lpCommandLine, 
    __in  DWORD dwCreationFlags, 
    __in_opt LPVOID lpEnvironment, 
    __in_opt LPCWSTR lpCurrentDirectory, 
    __in  LPSTARTUPINFOW lpStartupInfo, 
    __out  LPPROCESS_INFORMATION lpProcessInformation 
    );

विजुअल C++ 2005 और बाद में compilers के मामले में, ये वास्तव में __$allowed_on_parameter तरह घोषणाओं के लिए नक्शे और संकलन समय पर जाँच कर रहे हैं।

स्रोत

2009-10-29 19:33:31

विंडोज हेडर वास्तव में वास्तव में ऐसा करते हैं। इस्तेमाल की गई टिप्पणियों की पूरी सूची के लिए Header Annotations देखें। उदाहरण के लिए "

DWORD 
WINAPI 
GetModuleFileName(
    __in_opt HMODULE hModule, 
    __out_ecount_part(nSize, return + 1) LPTSTR lpFilename, 
    __in DWORD nSize 
    );

इस समारोह के लिए, hModule एक वैकल्पिक इनपुट पैरामीटर है, lpFilename एक आउटपुट पैरामीटर जो nSize चरित्र तत्वों की एक अधिकतम स्टोर और जो (समारोह की वापसी मूल्य) में शामिल होंगे +1 चरित्र तत्वों है उस में वापसी पर, और nSize एक इनपुट पैरामीटर है।

स्रोत

2009-10-29 19:34:57

+1। इस ब्लॉग एंट्री में पृष्ठभूमि और अधिक उदाहरण हैं: http://blogs.msdn.com/michael_howard/archive/2006/05/19/602077.aspx –

लेकिन वे खाली मैक्रोज़ नहीं हैं - अंत में, वे एसएएल विशेषताओं में विस्तार करते हैं जैसे '[SA_Pre (...)]' और '[SA_Post (...)] ', जो वास्तव में संकलक द्वारा संभाले जाते हैं। –

प्रलेखन प्रयोजनों के लिए, एक अच्छी तरह से लिखा टिप्पणी ब्लॉक के लिए पर्याप्त है, इसलिए इन किसी भी उद्देश्य पूरा नहीं है। इसके अलावा, कुछ प्रलेखन टिप्पणी पारसर्स सिर्फ इस तरह के लिए विशेष सिंटेक्स है एक बात; उदाहरण के लिए, डोक्सीजन दिया गया, आप लिख सकते हैं:

/** 
* @param[in] param1 ... 
* @param[out] param2 ... 
**/ 
void some_function(int param1, char **param2);

स्रोत

2009-10-29 19:43:31

... लेकिन दस्तावेज़ीकरण चिंता के बाहर चीजों के बारे में क्या? – jldupont

आपका क्या मतलब है? आप सार्वजनिक विधियों में न केवल सभी तरीकों को दस्तावेज कर सकते हैं और दस्तावेज करना चाहिए। दस्तावेज़ीकरण पीढ़ी के उद्देश्य के लिए, आमतौर पर यह संकेत देने का एक तरीका है कि कौन से तरीके "निजी उपयोग के लिए" हैं, ताकि वे सार्वजनिक दस्तावेज़ों में न आएं - उदा। Doxygen में '\ internal'। –

यदि आप दस्तावेज़ों को नहीं देख रहे हैं, तो आप स्रोत कोड देख रहे हैं। यदि यह कम से कम स्पष्ट रूप से स्पष्ट नहीं है, तो आपको सजावट के बजाय स्रोत में तत्वों को दोबारा करने और/या नाम बदलने की आवश्यकता है। –

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

यदि आप वास्तव में दस्तावेज़ बनाना चाहते हैं तो इसे वहां टिप्पणी दें।

void some_function(/* IN */ int param1, /* OUT */ char **param2);

इसके अलावा एक वापसी मूल्य ठीक काम करेगा जब बाहर का उपयोग क्यों करें।
इसके अलावा मैं अपने इरादों को इंगित करने के लिए रेफरी और कॉन्स्ट रेफ द्वारा पास का उपयोग करना पसंद करूंगा। जब आपका कोड सही होता है तो भी कंपाइलर अब इरादे के लिए अपेक्षाकृत अच्छा अनुकूलन करता है।


#define begin { 
#define end } 

int main(int argc, char* argv[]) 
begin 
    ... 
end

स्रोत

2009-10-29 19:55:16

अच्छा बिंदु ... धन्यवाद! – jldupont

@ मार्टिन: जहां तक आपने "char *" टिप्पणी की है, मेरे पास प्रश्न के शीर्ष पर मेरा अस्वीकरण था ;-) – jldupont

/* +1 */(प्लसोन के विपरीत) –

केवल एक चीज बदतर यह तो बहुत पहले एक सी कार्यक्रम पास्कल देव द्वारा लिखित में देखा गया :

void some_function(int i_param1, char** o_param2, int& io_param3);

स्रोत

2009-10-29 20:04:56

मैं पैरामीटर प्रकार में जानकारी के अतिरिक्त देखा उपसर्गों का उपयोग I_, o_, io_:

void some_function(/* IN */ int const& param1, /* OUT */ char*& param2); 
// OK for int const& is kind of silly but other types may be usefull.

स्रोत

2009-10-29 21:16:33

C/C++ समारोह/विधि सजावट

उत्तर

संबंधित मुद्दे