C ++ में .inl फ़ाइल का महत्व

108

.Inl फ़ाइल में घोषणाएँ होने के क्या फायदे हैं? मुझे उसी का उपयोग करने की आवश्यकता कब होगी?

c++

3

FWIW, मैं .inl फाइलों से नफरत करता हूं। अपने कोड को आवश्यकता से अधिक क्यों विभाजित करें?

— शोग

10

@ शोग 9: कार्यान्वयन से इंटरफ़ेस को अलग करने के लिए। मुझे हमेशा C # और Java फाइल से नफरत है, क्योंकि सभी मैसिज कार्यान्वयन विवरणों के कारण इंटरफ़ेस को पढ़ना इतना कठिन है।

— मार्टिन

8

@Martin - दुर्भाग्य से C ++ हमें दोनों दुनियाओं का एक बुरा संयोजन देता है - हेडर में कार्यान्वयन का इंटरफ़ेस और भाग, बाकी कार्यान्वयन में .cpp फ़ाइल। यहां तक कि अगर आप इनलाइन फ़ंक्शंस से बचते हैं (या उन्हें .inl फाइलों में डालते हैं) तो आपको इंटरफ़ेस को निजी सदस्यों के pesky विवरणों के साथ बंद करना होगा जब तक कि आप धार्मिक रूप से मुहावरे का उपयोग करने में सक्षम न हों।

— माइकल बूर

5

हाँ, मैंने कभी भी इस तर्क को नहीं समझा है कि कार्यान्वयन से इंटरफ़ेस अलग है। वे स्पष्ट रूप से नहीं। एक इंटरफ़ेस में सभी निजी सदस्य नहीं होने चाहिए।

— जुलफ ३१'०

@ लॉकीस्टारी: निष्पक्ष होने के लिए, जावा / सी # में बहुत अच्छी टूलिंग है जो इंटरफ़ेस की रूपरेखा को स्वचालित रूप से प्रदान करती है। कोई इसे दूसरे तरीके से डाल सकता है: C ++ में आपको मैन्युअल रूप से एक समस्या को हल करना होगा, जिसे कंप्यूटर द्वारा पूरी तरह से हल किया जा सकता है।

— bluenote10

139

.inlफ़ाइलें अनिवार्य नहीं हैं और संकलक के लिए कोई विशेष महत्व नहीं है। यह आपके कोड को संरचित करने का एक तरीका है जो मनुष्यों को एक संकेत प्रदान करता है जो इसे पढ़ सकते हैं।

मैं .inlदो मामलों में फ़ाइलों का उपयोग करता हूं :

इनलाइन कार्यों की परिभाषा के लिए।
फ़ंक्शन टेम्प्लेट की परिभाषाओं के लिए।

दोनों ही मामलों में, मैं कार्यों की घोषणाओं एक हेडर फाइल है, जो अन्य फ़ाइलों से शामिल किया गया है में, तो मैं डाल फ़ाइल हेडर फाइल के तल पर।#include.inl

मुझे यह पसंद है क्योंकि यह इंटरफ़ेस को कार्यान्वयन से अलग करता है और हेडर फ़ाइल को पढ़ने में थोड़ा आसान बनाता है। यदि आप कार्यान्वयन विवरण के बारे में परवाह करते हैं, तो आप .inlफ़ाइल खोल सकते हैं और इसे पढ़ सकते हैं। यदि आप नहीं करते हैं, तो आपके पास नहीं है।

— निक मेयर
स्रोत

2

दरअसल, यह ज्यादातर इंटरफ़ेस को कार्यान्वयन से अलग करने के बारे में है।

— पावेल मिनाएव जूल 30'09

1

मैंने भी .ipp और .ixx को इनलाइन परिभाषाओं के लिए इस्तेमाल किया है और। टेम्पलेट के लिए .tpp और .txx को देखा है।

— एपीग्रामग्राम

1

उदाहरण के लिए, जीएनयू मानक सी ++ लाइब्रेरी .tccटेम्पलेट कार्यान्वयन फ़ाइलों के लिए उपयोग करता है ।

— ०३ में मुसफिल

1

@NickMeyer .hpp glmऔर .inl का उपयोग उसी तरह करता है, जैसा आपने ऊपर बताया है। जानने के लिए अच्छा है, महान जवाब के लिए धन्यवाद :)

— किंवदंतियों 2k

तो क्या यह हेडर जैसा है?

— एरोन फ्रेंके

90

निक मेयर सही है: कंपाइलर आपके द्वारा शामिल फ़ाइल के विस्तार की परवाह नहीं करता है, इसलिए ".h", ".hpp", ".hxx", ".hh", ".inl" जैसी चीज़ें। ".inc", आदि एक साधारण सम्मेलन है, यह स्पष्ट करने के लिए कि फाइलों में क्या निहित है।

सबसे अच्छा उदाहरण एसटीएल हेडर फाइलें हैं जिनका कोई विस्तार नहीं है।

आमतौर पर, ".inl" फाइलों में इनलाइन कोड होता है (इसलिए ".inl" एक्सटेंशन)।

जब आप हेडर कोड के बीच निर्भरता चक्र रखते हैं, तो ".inl" फाइलें एक आवश्यकता होती हैं ।

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

// A.hpp
struct A
{
    void doSomethingElse()
    {
       // Etc.
    }

    void doSomething(B & b)
    {
       b.doSomethingElse() ;
    }
} ;

तथा:

// B.hpp
struct B
{
    void doSomethingElse()
    {
       // Etc.
    }

    void doSomething(A & a)
    {
       a.doSomethingElse() ;
    }
} ;

आगे की घोषणा का उपयोग करने सहित, आपके पास यह संकलन करने का कोई तरीका नहीं है।

इसके बाद समाधान दो प्रकार की हेडर फ़ाइलों में परिभाषा और कार्यान्वयन को तोड़ता है:

hpp हेडर घोषणा / परिभाषा के लिए
inl हेडर कार्यान्वयन के लिए

जो निम्नलिखित उदाहरण में टूट जाता है:

// A.hpp

struct B ;

struct A
{
    void doSomethingElse() ;
    void doSomething(B & b) ;
} ;

तथा:

// A.inl
#include <A.hpp>
#include <B.hpp>

inline void A::doSomethingElse()
{
   // Etc.
}

inline void A::doSomething(B & b)
{
   b.doSomethingElse() ;
}

तथा:

// B.hpp

struct A ;

struct B
{
    void doSomethingElse() ;
    void doSomething(A & a) ;
} ;

तथा:

// B.INL
#include <B.hpp>
#include <A.hpp>

inline void B::doSomethingElse()
{
   // Etc.
}

inline void B::doSomething(A & a)
{
   a.doSomethingElse() ;
}

इस तरह, आप अपने स्रोत में जो भी ".inl" फ़ाइल शामिल कर सकते हैं, और यह काम करेगा।

फिर, शामिल फ़ाइलों के प्रत्यय नाम वास्तव में महत्वपूर्ण नहीं हैं, केवल उनके उपयोग।

— paercebal
स्रोत

5

यह अलगाव के वास्तविक लाभ (या आवश्यकता) की व्याख्या करता है, और उत्तर के रूप में चुना जाना चाहिए था।

— मुसफिल

यदि फ़ंक्शन इनलाइन नहीं था, तो आप कार्यान्वयन भाग के लिए मानक .cpp फ़ाइल को मानक कर सकते हैं?

— बुब्लफस

@ बब्लफस:: If the function were not inline, you would you standard .cpp file for the implementation part?संभवतः। टेम्पलेट कोड के उदाहरण हैं जो आमतौर पर .CPP फ़ाइलों में नहीं छिपाए जा सकते हैं, इसलिए उस स्थिति में .INL फ़ाइल अनिवार्य होगी।

— पियरसबल

32

चूंकि किसी और ने इसका उल्लेख नहीं किया है:

अपने इनलाइन फ़ंक्शंस को स्टोर करने के लिए .inl फ़ाइलों का उपयोग कंपाइल को गति देने के लिए उपयोगी हो सकता है।

यदि आप केवल घोषणाओं (.h) को शामिल करते हैं, जहाँ आपको घोषणाओं की आवश्यकता होती है, और केवल इनलाइन कार्यान्वयन (.inl) शामिल होते हैं, जहाँ आपको उनकी आवश्यकता होती है (अर्थात शायद केवल .cpp और अन्य .inl फ़ाइलों में, .h की), तो यह हो सकता है। आपके हेडर निर्भरता पर लाभकारी प्रभाव।

यह कई इंटरेक्टिव कक्षाओं के साथ बड़ी परियोजनाओं पर एक महत्वपूर्ण जीत हो सकती है।

— एंडी जे बुकानन
स्रोत

7

+1: दुनिया निश्चित रूप से एक अलग जगह है जब आप लाखों लाइनों और हजारों फ़ाइलों का प्रबंधन कर रहे हैं।

— गेटोरफैक्स

इसलिए आपको हेडर फ़ाइलों में .inl शामिल नहीं करना चाहिए? मेरे मन में हमेशा यह भावना थी कि इनलाइन फ़ाइलों को नीचे रखा जाना चाहिए क्योंकि इनलाइन कार्यों के लिए घोषणा की आवश्यकता होती है और कार्यान्वयन को एक बार में पहुंच योग्य होना चाहिए।

— आइसबोन 1000

1

Icebone1000 उन सभी मॉड्यूल्स में शामिल नहीं है जिनमें हेडर आवश्यक रूप से इनलाइन फ़ंक्शंस का उपयोग करना चाहते हैं, इसलिए उन्हें कार्यान्वयन में पढ़ने के लिए कोई ज़रूरत नहीं है, यदि वे उपयोग नहीं किए जाते हैं तो उन्हें मौजूद होने की आवश्यकता नहीं है।

— एंडी जे बुकानन

1

मुझे समझ में नहीं आता है कि यह कैसे तेज हो सकता है, क्योंकि संकलक को अनुवाद इकाइयों को शामिल करने और संयोजित करने के लिए अधिक काम करना होगा।

— निकोस

1

@ निकोस मुझे लगता है कि वह आपके हेडलाइन फ़ाइलों में आपके सभी इनलाइन कार्यों को डालने के लिए तेजी से सापेक्ष था।

— कॉफीटेबल एस्प्रेसो

3

मेरे अनुभव में, .inl फ़ाइलों का उपयोग इनलाइन फ़ंक्शंस को परिभाषित करने के लिए किया जाता है। जब वे एक .inl फ़ाइल में होते हैं, तो फ़ाइल को इनलाइन फ़ंक्शंस प्राप्त करने के लिए हेडर में और नियमित कार्य परिभाषाएँ प्राप्त करने के लिए एक .c फ़ाइल में शामिल किया जा सकता है।

इस तरह एक ही स्रोत अधिक आसानी से संकलक के साथ काम कर सकता है जिसमें इनलाइन फ़ंक्शन सपोर्टस के साथ-साथ संकलक भी नहीं हैं।

वे आमतौर पर सीधे C कोड के साथ उपयोग किए जाते हैं, अक्सर C ++ कोड के साथ नहीं होते हैं क्योंकि सभी C ++ कंपाइलर इनलाइन फ़ंक्शन का समर्थन करते हैं।

— माइकल बूर
स्रोत

मैं सी समर्थन पाने के लिए ऐसा करने में बात नहीं देखता। C के लिए, आप केवल सशर्त रूप से #define inline static, और शीर्ष लेख में अपने इनलाइन फ़ंक्शन को परिभाषित करेंगे।

— पावेल मिनाएव जूल 30'09

मुझे लगता है कि यह बाइनरी में समाप्त होने से एक ही फ़ंक्शन की कई प्रतियों से बचा जाता है। मैं सिर्फ इतना कह रहा हूं कि मैंने देखा है .inl फाइलों ने इस तरह से उपयोग किया है, ऐसा नहीं है कि यह एकमात्र तकनीक (या सबसे अच्छा) है।

— माइकल बूर

1

मेरा मानना है कि यह "हेडर" फ़ाइल के लिए सिर्फ एक नामकरण सम्मेलन है जिसमें इनलाइन कोड शामिल है। ऐसा इसलिए है कि .h फ़ाइलों में परिभाषाएँ हो सकती हैं और .inl फ़ाइलों में इनलाइन कोड होता है जो टेम्प्लेट के लिए आवश्यक होता है।

मुझे विश्वास नहीं है कि फ़ाइल के उद्देश्य को स्पष्ट करने के लिए नामकरण सम्मेलन की तुलना में इसमें अधिक कुछ भी नहीं है

— jcoder
स्रोत