c++ - क्या मुझे कई कार्यों को एक फाइल में रखना चाहिए? या, अधिक या कम, एक फ़ंक्शन प्रति फ़ाइल?




build-process compilation (6)

मुझे अपना कोड व्यवस्थित करना अच्छा लगता है, इसलिए आदर्श रूप से मुझे प्रति वर्ग एक वर्ग चाहिए या जब मेरे पास गैर-सदस्यीय फ़ंक्शन होते हैं, प्रति फ़ाइल एक फ़ंक्शन

कारण हैं:

  1. जब मैं कोड पढ़ता हूं तो मुझे हमेशा पता होगा कि मुझे एक निश्चित फंक्शन या क्लास कैसे मिलना चाहिए।

  2. अगर यह एक क्लास या एक गैर सदस्य फ़ंक्शन प्रति हैडर फ़ाइल है, तो मैं एक संपूर्ण गड़बड़ शामिल नहीं होगा जब मैं शीर्ष लेख फ़ाइल include करता हूँ

  3. अगर मैं फ़ंक्शन में एक छोटा बदलाव करता हूं तो केवल उस फ़ंक्शन को पुनः कंपाइल करना होगा।

हालांकि, कई हेडर में सब कुछ विभाजित करना और कई कार्यान्वयन फ़ाइलों को संकलन धीमा कर सकता है। मेरी प्रोजेक्ट में, अधिकांश फ़ंक्शंस एक निश्चित संख्या में टॉम्प्लेटेड अन्य लाइब्रेरी फ़ंक्शंस तक पहुंचते हैं। ताकि प्रत्येक कार्यान्वयन फ़ाइल के लिए एक बार कोड संकलित हो जाए। मेरी पूरी परियोजना को संकलित करना एक मशीन पर 45 मिनट या उससे अधिक समय लेता है। लगभग 50 ऑब्जेक्ट फाइलें हैं, और प्रत्येक एक ही महंगा-टू-कंपाइल करने वाले हेडर का उपयोग करता है

हो सकता है, क्या यह प्रति हेडर फाइल के लिए एक वर्ग (या गैर-सदस्यीय फ़ंक्शन) स्वीकार्य है, लेकिन इन कार्यान्वयन के कई या सभी कार्यान्वयन को एक कार्यान्वयन फ़ाइल में डालना, जैसे निम्न उदाहरण में?

// foo.h
void foo(int n);

// bar.h
void bar(double d);

// foobar.cpp
#include <vector>
void foo(int n) { std::vector<int> v; ... }
void bar(double d) { std::vector<int> w; ... }

दोबारा, लाभ यह होगा कि मैं सिर्फ फ़ू फ़ंक्शन या सिर्फ बार फ़ंक्शन को शामिल कर सकता हूं, और पूरी परियोजना का संकलन तेजी से होगा क्योंकि foobar.cpp एक फाइल है, इसलिए std::vector<int> (जो सिर्फ यहाँ कुछ अन्य महंगे-से-संकलित templated निर्माण के लिए एक उदाहरण) एक बार में संकलित किया जाना चाहिए, के रूप में दो बार के विरोध के रूप में अगर मैं एक foo.cpp और bar.cpp अलग से संकलित किया है। बेशक, ऊपर दिए गए मेरे कारण (3) इस परिदृश्य के लिए मान्य नहीं हैं: बस foo () {...} को बदलने के बाद मुझे पूरे, संभवत: बड़ा, फाइल foobar.cpp को पुनः कंपाइल करना foobar.cpp

मैं उत्सुक हूँ कि आपके विचार क्या हैं!


आप अपने कुछ कार्यों को एक या अधिक कक्षाओं के स्थैतिक तरीकों के रूप में दोहराने के लिए कर सकते हैं: यह आपको एक मौका (और एक अच्छा बहाना) प्रदान करता है ताकि उनमें से कई को एकल स्रोत फाइल में बांट सकें।

एक स्रोत फाइल में कई फ़ंक्शन होने या नहीं होने का एक अच्छा कारण, यदि वह स्रोत फाइल ऑब्जेक्ट फाइलों के साथ एक-टू-एक होती है, और लिंकर पूरी ऑब्जेक्ट फाइलों को लिंक करती है: यदि एक एक्जीक्यूटेबल एक फ़ंक्शन चाहता हो, लेकिन दूसरा नहीं, तो उन्हें अलग स्रोत फ़ाइलों में (ताकि लिंकर दूसरे के बिना एक लिंक कर सकता है)


मेरा एक पुराना प्रोग्रामिंग प्रोफेसर ने रखरखाव के लिए प्रत्येक सौ सौ लाइन कोड मॉड्यूल को तोड़ने का सुझाव दिया। मैं अब सी ++ में विकसित नहीं कर सकता, लेकिन सी # में मैं खुद को एक फ़ाइल प्रति एक वर्ग तक सीमित करता हूं, और फ़ाइल का आकार तब तक कोई फर्क नहीं पड़ता जब तक कि मेरे ऑब्जेक्ट से कोई संबंध नहीं है आप एडिटर स्पेस को बेहद कम करने के लिए #प्रगमा क्षेत्रों का उपयोग कर सकते हैं, निश्चित नहीं कि अगर सी ++ कंपाइलर के पास है, लेकिन यदि ऐसा होता है तो निश्चित रूप से उन का उपयोग करें

अगर मैं अभी भी C ++ में प्रोग्रामिंग कर रहा था तो मैं प्रति फ़ंक्शन एकाधिक फ़ंक्शन का उपयोग करके समूह फ़ंक्शन का उपयोग करूँगा। इसलिए मेरे पास 'सर्विसकप' नामक एक फाइल हो सकती है, जो कि "सेवा" को परिभाषित करती है। प्रति फ़ाइल एक फ़ंक्शन होने के कारण किसी भी तरह, किसी भी तरह अपनी परियोजना में अपना रास्ता वापस लेने के लिए अफसोस होगा

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

यह एक भी स्रोत को परिभाषित करने वाली कई स्रोत फाइलों को परेशान नहीं करता है Ie: 'ServiceConnection.cpp' 'ServiceSettings.cpp', और इतने पर आगे।

कभी-कभी अगर मैं एक ऑब्जेक्ट बनाता हूं, और यह अन्य ऑब्जेक्ट्स का मालिक है, तो मैं एक से ज्यादा क्लासेस को एक फाइल में जोड़ूंगा। उदाहरण के लिए एक बटन नियंत्रण जिसमें 'बटन लिंक' ऑब्जेक्ट शामिल हैं, मैं उस बटन कक्षा में जोड़ सकता हूं। कभी-कभी मैं नहीं करता, लेकिन यह "पल की पसंद" निर्णय है।

क्या आपके लिए सबसे अच्छा काम करता है छोटी परियोजनाओं पर विभिन्न शैलियों के साथ थोड़ा सा प्रयोग करने में मदद मिल सकती है। आशा है कि इससे आपको थोड़ी मदद मिलेगी।


मैं आपके दृष्टिकोण के कुछ फायदे देख सकता हूं लेकिन कई नुकसान हैं I

1) पैकेज सहित एक दुःस्वप्न है आप 10-20 के साथ समाप्त कर सकते हैं जिसमें आपको आवश्यक फ़ंक्शंस प्राप्त हो सकते हैं। उदाहरण के लिए यदि STDIO या StdLib इस तरह लागू किया गया था।

2) कोड को ब्राउज़ करना थोड़ा दर्द हो सकता है क्योंकि सामान्य रूप से फ़ाइलों को स्विच करने के बजाय फाइल के माध्यम से स्क्रॉल करना आसान होता है। स्पष्ट रूप से बहुत बड़ी फाइल कठिन है लेकिन यहां तक ​​कि आधुनिक आईडीई के साथ भी फाइल को नीचे की जरूरत के मुकाबले काफी आसान करना है और उनमें से बहुत से शॉर्टकट की फ़ंक्शंस है

3) फ़ाइल रखरखाव करना एक दर्द है।

4) मैं छोटे फ़ंक्शंस और रिफैक्टरिंग का बड़ा प्रशंसक हूं। जब आप ओवरहेड जोड़ते हैं (इसे एक नई फ़ाइल बनाते हुए, इसे स्रोत नियंत्रण में जोड़ते हैं ...) यह लोगों को लंबे समय तक कार्य करने के लिए प्रोत्साहित करता है, जहां 1 फ़ंक्शन को 3 भागों में तोड़ने के बजाय, आप केवल 1 बड़ा एक बनाते हैं


मैंने फाइल प्रति फ़ंक्शन में फ़ाइलों को विभाजित करने की कोशिश की, लेकिन इसमें कुछ कमियां थीं कभी-कभी फ़ंक्शंस जितना ज़्यादा ज़्यादा ज़रूरी है (आप हर बार एक नई सी फाइल नहीं जोड़ना चाहते हैं) जब तक आप अपने कोड को रिफ़ैक्टर करने के लिए मेहनती नहीं होते (मैं नहीं हूं)। वर्तमान में मैं सी फ़ाइल में 1 से 3 फ़ंक्शंस रखता हूं और सभी सी फाइलों को डायरेक्टरी में कार्यक्षमता के लिए रखता हूं। हैडरफाइल के लिए मेरे पास Subfunctionality.h और Subfunctionality.h ताकि पूरे पैकेज की जरूरी न होने पर मैं सभी कार्यों को एक बार में शामिल कर सकता / सकती हूं या बस एक छोटा उपयोगिता फ़ंक्शन।


हेडर भाग के लिए, आपको आइटम को तार्किक समूहों में जोड़ना चाहिए और उस पर आधारित अपनी HEADER फ़ाइलें बनाना चाहिए। ऐसा लगता है और बहुत तार्किक IMHO है

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

Checkout glibc या Visual C ++ CRT स्रोत ट्री ...


आईएमएचओ, आपको आइटम को तार्किक समूहों में जोड़ना चाहिए और उस पर आधारित अपनी फ़ाइलें बनाना चाहिए।

जब मैं कार्य लेखन करता हूँ, तो अक्सर आधा दर्जन या तो ऐसा होता है जो कसकर एक दूसरे से संबंधित होते हैं। मैं उन्हें एक हेडर और कार्यान्वयन फ़ाइल में एक साथ रखता हूं।

जब मैं कक्षाएं लिखता हूं, तो मैं आमतौर पर एक शीर्ष हेडर और कार्यान्वयन फ़ाइल प्रति एक हेवीवेट वर्ग तक सीमित होता हूं। मैं कुछ सुविधा कार्यों या छोटे सहायक वर्गों में जोड़ सकता है

अगर मुझे लगता है कि एक कार्यान्वयन फ़ाइल हजारों लाइनों लंबी है, यह आमतौर पर एक संकेत है कि वहाँ बहुत अधिक है और मुझे इसे तोड़ने की जरूरत है





file-organization