2010-02-23 8 views
8

वर्तमान में, मैं जावा में प्रोग्राम करता हूं और मैवेन का उपयोग थोड़ा सा करता हूं। इसलिए मैं नामकरण योजनाओं और फ़ोल्डर संरचनाओं का आदी हो गया हूं जिनका मैंने पिछले 4 या 5 वर्षों में उपयोग किया है।मैं अपने सी ++ प्रोग्राम को कैसे लेआउट करूं? (मुझे .h और .cpp फ़ाइलों को कहां रखना चाहिए?)

जैसा कि मैंने हाल ही में सी ++ सीखना शुरू कर दिया है, मुझे एहसास है कि मुझे नहीं पता कि मेरी सभी फाइलें कहां रखी जाएंगी। क्या मुझे नेमस्पेस द्वारा सब कुछ तोड़ना चाहिए, या यह किस स्तर में है? जहां, उदाहरण के लिए, क्या मैं यूआई को समर्पित फाइलों की एक श्रृंखला रखूंगा, जैसा कि डेटा स्टोर करने में मदद करने के लिए फाइलों से जुड़ा हुआ है?

क्या इस तरह की चीज के लिए कोई मानक है?

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

+0

आप किस प्रकार के पर्यावरण का उपयोग कर रहे हैं? – ihtkwot

+0

प्रोग्राम आउटपुट कहां रखना है, यह एक अलग मामला है और संभवतः एक अलग प्रश्न के रूप में बेहतर पूछा जाता है। –

+0

@gf अच्छा बिंदु। इसे संपादित किया। – Stephano

उत्तर

5

निम्नलिखित बहुत विशिष्ट उदाहरण है ...

third-party library 
    release 
    obj 
    debug 
    obj 
    include 
    src 
    sublib 1 
    sublib 2 

mylibrary 
    release 
    obj 
    debug 
    obj 
    include 
    src 
    sublib 1 
    sublib 2 

myapp 
    release 
    obj 
    debug 
    obj 
    subapp 1 
    subapp 2 

mylittleapp 
    release 
    obj 
    debug 
    obj 

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

फ़ोल्डरों में "शामिल" होना चाहिए आईएमओ में केवल शीर्षलेख होना चाहिए जो अन्य परियोजनाओं द्वारा शामिल किया जाएगा - आंतरिक शीर्षलेख "src" फ़ोल्डर में हैं।

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

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

असल में, नेमस्पेस नामकरण विवादों से परहेज करने का एक तरीका है। वे अनिवार्य रूप से abstractions या कार्यात्मक ब्लॉक या कुछ भी के साथ संबद्ध नहीं है। किसी विशेष प्रोजेक्ट के भीतर, आप यह सुनिश्चित कर सकते हैं कि नाम संघर्ष न करें। "Std" नेमस्पेस के साथ, एक नामस्थान में लॉट डालना ठीक है।

जैसा कि आप कहते हैं, हालांकि, यह एक निश्चित उत्तर नहीं है - निश्चित रूप से मामूली विविधताएं और काफी अलग दृष्टिकोण हैं।

1

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

1

मैं विषय के लिए एक निर्देशिका थीम के आधार पर अपनी परियोजनाओं को तोड़ने,:

menu_planner 
    src 
    recipes 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    ingredients 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    references 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    meals 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    menus 
     debug -- contains debug object files and libraries 
     release -- contains release object files and libraries 
     obsolete -- contains obsolete source files 
    docs 
    designs 

मेरे सी के साथ अनुभव और सी ++ मेरे लिए पता चला है कि हैडर और स्रोत फ़ाइलें एक ही निर्देशिका में होना चाहिए। अक्सर, हेडर फ़ाइल ढूंढना अधिक कठिन होता है जब यह स्रोत फ़ाइल के समान निर्देशिका में नहीं होता है।

प्रति अवधारणा (फ़ोल्डर) प्रति अवधारणा एक अच्छा विचार है। जटिल या परिसर की कोई भी अवधारणा एकाधिक फ़ोल्डर्स या अवधारणाओं में विभाजित की जानी चाहिए।

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

हालांकि, कार्यस्थलों (ए.के.ए. दुकानों) में अलग-अलग शैली के नियम हो सकते हैं जिनका पालन किया जाना चाहिए।

0

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

http://codednotes.blogspot.com/2014/01/organising-headers-and-source-files.html

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