2012-11-13 6 views
42

क्या कोई दिशा-निर्देश हैं कि सी ++ टेम्पलेट्स और टेम्पलेट मेटा-फ़ंक्शंस को डॉक्सीजन के साथ कैसे दस्तावेज किया जाना चाहिए?डॉक्सिजन के साथ सी ++ टेम्पलेट्स और टेम्पलेट मेटाफंक्शन को कैसे दस्तावेज़ित करें?

उदाहरण के लिए:

/// @brief metafunction for generation of a map of message types to 
/// their associated callbacks. 
/// @tparam Seq the list of message types 
template< class Seq > 
struct generate_callback_map 
{ 
    typedef typename mpl::transform< Seq 
            , build_type_signature_pair<mpl::_1> 
            >::type vector_pair_type; 
    typedef typename fusion::result_of::as_map<vector_pair_type>::type type; 
}; 

अब तक मैं निम्नलिखित सुझाव देखा है:

  • @tparam टेम्प्लेट पैरामीटर दस्तावेज़ के लिए इस्तेमाल किया।
  • @arg टेम्पलेट पैरामीटर दस्तावेज करने का वैकल्पिक तरीका।
  • @brief मेटाफंक्शन का वर्णन करने के लिए उपयोग किया जाता है।

मेटाफंक्शन के लिए 'लौटा प्रकार' कैसे दस्तावेज किया जाना चाहिए?

क्या किसी के पास C++ टेम्पलेट्स के साथ डॉक्सीजन का उपयोग करने के लिए कोई अच्छा सुझाव या व्यक्तिगत वरीयता है?

+4

@ पब्बी: यह वास्तव में उपयोगी सलाह है। आप से क्या उपयोग करेंगे? –

+0

@JanHudec इसे उत्पन्न करने के बजाय इसे स्वयं लिखें। एक शैली गाइड और पाठ्यक्रम के लगातार स्वरूपण का प्रयोग करें। पठनीय कोड टीएमपी के लिए एक बड़ा प्लस है क्योंकि वे एक रिसाव अमूर्त हैं। एक psuedocode का उपयोग करके व्याख्या करने में मदद करता है क्योंकि सी ++ वाक्यविन्यास बेकार है। – Pubby

+4

@ पब्बी मजाक कर रहे होंगे। अच्छा दस्तावेज़ तब होता है जब आप कोड को कभी नहीं देखते हैं।आपने हेडर में स्पष्टीकरण टिप्पणियां पढ़ी हैं, और आप कार्यान्वयन पर भी ध्यान देने की परवाह नहीं करते हैं, यानी, आपको कोड शैली, स्वरूपण, पठनीयता और जो भी कुछ भी पसंद नहीं है - यह एक अच्छा दस्तावेज़ है। * Doxygen * इन दस्तावेज़ों को स्रोत कोड * (आदर्शतः हेडर से) * निकालने के लिए सिर्फ एक उपकरण है। बेशक अगर आप अपने एपीआई विवरण को एचटीएमएल/पीडीएफ/जो भी, अच्छी तरह से, शुभकामनाएं के बजाय «targzipped» शीर्षकों के समूह की तरह वितरित करना चाहते हैं; मैं * Doxygen * का उपयोग करना पसंद करेंगे। –

उत्तर

18

मुझे नहीं लगता कि यह संभव उपयोग दस्तावेज़ उन्नत टेम्पलेट है, क्योंकि यह मूल रूप से वस्तु उन्मुख प्रतिमान के लिए डिजाइन किया गया था और metaprograming नहीं Doxygen साथ निर्माण करती है। एक उदाहरण के रूप में, जीएनयू एसटीएल (libstdC++) डॉक्सिजन का उपयोग करता है लेकिन एसटीएल में मेटाप्रोग्रामिंग दस्तावेज करने के poor job करता है।

दूसरी ओर, को बढ़ावा देने के लिए अपने स्वयं उपकरणों का उपयोग करता: QuickBook स्टैंडअलोन पाठ फ़ाइलें और Doxygen प्रलेखित स्रोत का उपयोग करता है BoostBook मार्कअप (DocBook के विस्तार), जो बारी-बारी html/पीडीएफ उत्पन्न करता है उत्पन्न करने के लिए। result libstdC++ के मुकाबले अधिक जानकारीपूर्ण है लेकिन स्पष्ट रूप से देव से थोड़ा और काम शामिल है।

चूंकि बूस्ट प्रलेखन तर्कसंगत रूप से मेटाप्रोग्रामिंग के लिए सबसे अच्छा है, इसलिए आप उस मार्ग पर जा सकते हैं, खासकर जब यह डॉक्सिजन पूरा करता है - आप अपने मौजूदा मार्कअप का पुन: उपयोग कर सकते हैं।

हालांकि यह वास्तव में आपके प्रश्न का उत्तर नहीं देता है, तो आपको हालिया क्लैंग developments में रुचि हो सकती है। --with-extra-options=-Wdocumentation के साथ क्लैंग का निर्माण करते समय यह आपके कोड के साथ अपने डॉक्सिजन मार्कअप की जांच करता है और दस्तावेज़ीकरण चेतावनियां उत्पन्न करता है। आपको डॉक्स/कोड सिंक्रनाइज़ रखने के लिए मजबूर करता है।

+1

के रूप में चुना जाना चाहिए, मैं सहमत हूं कि अधिकांश बूस्ट प्रलेखन बहुत अच्छा है और यह निश्चित रूप से उनके दृष्टिकोण का पालन करने के लिए समझ में आता है। – mark

+1

यहां बहुत अच्छी जानकारी है। क्लैंग/एलएलवीएम दस्तावेज जांच का लिंक बेहद उपयोगी है! मुझे इसे काम करने के लिए सिर्फ '-डॉडिटेशन' का उपयोग करना पड़ा। ओपी के सवाल का सख्ती से जवाब नहीं देते हैं, हालांकि। –

+1

पुन "एक उदाहरण के रूप में, जीएनयू एसटीएल (libstdC++) डॉक्सिजन का उपयोग करता है लेकिन एसटीएल में मेटाप्रोग्रामिंग दस्तावेज करने का एक खराब काम करता है।" जीएनयू दस्तावेज, अवधि का एक गरीब काम करता है। स्रोत कोड देखें। मौजूद छोटी टिप्पणी सबसे खराब है। डॉक्सिजन की असफलताओं के उदाहरण के रूप में जीएनयू की लुभावनी टिप्पणी का उपयोग करना उचित नहीं है। एक बेहतर उदाहरण कुछ अच्छी तरह से टिप्पणी स्रोत होगा कि फिर भी डॉक्सिजन में बुरा लग रहा है। –

33

फ़ंक्शन तर्कों के लिए @tparam टेम्पलेट तर्क, @arg का उपयोग करें। वापसी मूल्यों के लिए, @return। यहां कोई वापसी नहीं है। केवल typedef एस हैं।

बीटीडब्ल्यू, आपका नमूना कोड मेटाफंक्शन की तरह नहीं दिखता है। मेटाफंक्शंस बालों वाले जानवर हैं जो एसएफआईएनएई का लाभ लेते हैं ताकि सी ++ मूल रूप से (उदाहरण के लिए, प्रतिबिंब) का इरादा न हो। आपका generate_callback_map टेम्पलेट टाइपपीफ के लिए बस एक C++ 03 स्टैंड-इन जैसा दिखता है।

जो आप खो रहे हैं वह इस टेम्पलेट का उपयोग करने के तरीके पर आपके टाइपिफ़ और दस्तावेज़ीकरण पर दस्तावेज़ है।

/// @brief metafunction for generation of a map of message types to 
/// their associated callbacks. 
/// @details 
/// Usage: Use <tt>generate_callback_map<Type>::type</tt> to ... 
/// @tparam Seq the list of message types 
/// 
template< class Seq > 
struct generate_callback_map 
{ 
    /// @brief It's a good idea to document all of your typedefs. 
    typedef typename mpl::transform< Seq 
           , build_type_signature_pair<mpl::_1> 
           >::type vector_pair_type; 

    /// @brief This is why generate_callback_map exists. Document it! 
    typedef typename fusion::result_of::as_map<vector_pair_type>::type type; 
}; 
+4

सी ++ में, "मेटाफंक्शन" आम तौर पर ओपी के जैसे कोड को संदर्भित करता है। हां, यह एक टाइपिफ़ है, लेकिन उस टाइपपीफ में वह प्रकार होता है जो निर्दिष्ट संकलन-समय "फ़ंक्शन" का मूल्यांकन करने का परिणाम होता है। – jalf

+6

मैं विवाद करूंगा कि यहां कोई वापसी नहीं है। औपचारिक रूप से कक्षाओं में वापसी मूल्य नहीं होते हैं, लेकिन तर्कसंगत रूप से 'टाइप' टाइपिफ़ एक वापसी है। और एक अलग सदस्य के रूप में कक्षा के लिए मुख्य दस्तावेज निकाय में बेहतर दस्तावेज किया जाएगा। –

+1

कोई तर्क दे सकता है कि यहां एक वापसी है, उसी अर्थ में यह संरचना परिभाषा एक कार्य है। लेकिन डॉक्सिजन और संबंधित/संगत दस्तावेज़ जेनरेटर के दृष्टिकोण से, उदाहरण में कुछ भी टैग करने की कोशिश कर रहे हैं, '@ रिटर्न' के साथ बस इसे भ्रमित कर देगा। @ डेविड का उदाहरण टाइपपीफ दस्तावेज इस समारोह में कार्य करता है और यह स्पष्ट है, लेकिन संरचना पर संक्षिप्त दस्तावेज़ीकरण द्वारा इसे बढ़ाया जा सकता है। –

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