* .h या * .hpp अपनी कक्षा की परिभाषाओं के लिए


551

मैंने हमेशा *.hअपनी कक्षा की परिभाषाओं के लिए एक फ़ाइल का उपयोग किया है , लेकिन कुछ बूस्ट लाइब्रेरी कोड पढ़ने के बाद, मैंने महसूस किया कि वे सभी उपयोग करते हैं *.hpp। मुझे हमेशा उस फ़ाइल एक्सटेंशन का लाभ मिला है, मुझे लगता है कि इसका मुख्य कारण यह है कि मुझे इसकी आदत नहीं है।

*.hppओवर का उपयोग करने के क्या फायदे और नुकसान हैं *.h?

जवाबों:


526

यहाँ C बनाम C ++ हेडर के विभिन्न नामकरण के कुछ कारण दिए गए हैं:

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

याद रखें, C C ++ नहीं है और यह तब तक मिक्स एंड मैच करना बहुत खतरनाक हो सकता है जब तक आपको पता न हो कि आप क्या कर रहे हैं। अपने स्रोतों का नामकरण आपको भाषाओं को अलग बताने में मदद करता है।


233

मैं .hpp का उपयोग करता हूं क्योंकि मैं चाहता हूं कि उपयोगकर्ता सी ++ हेडर और हेडर सी हेडर क्या हैं, इसे अलग करें।

यह महत्वपूर्ण हो सकता है जब आपका प्रोजेक्ट C और C ++ दोनों मॉड्यूल का उपयोग कर रहा हो: जैसे कि किसी और ने मुझे पहले समझाया था, आपको इसे बहुत सावधानी से करना चाहिए, और इसकी शुरुआत "अनुबंध" द्वारा होती है जिसे आप एक्सटेंशन के माध्यम से पेश करते हैं।

.hpp: C ++ हेडर

(या .hxx, या .hh, या जो भी हो)

यह शीर्षलेख केवल C ++ के लिए है।

यदि आप C मॉड्यूल में हैं, तो इसे शामिल करने का प्रयास भी न करें। आप इसे पसंद नहीं करेंगे, क्योंकि इसे सी-फ्रेंडली बनाने के लिए कोई प्रयास नहीं किया जाता है (बहुत अधिक खो जाएगा, जैसे फ़ंक्शन ओवरलोडिंग, नेमस्पेस, आदि)।

.एच: सी / सी ++ संगत या शुद्ध सी हेडर

यह हेडर प्रत्यक्ष या अप्रत्यक्ष रूप से सी स्रोत और सी ++ स्रोत दोनों के द्वारा शामिल किया जा सकता है।

यह सीधे शामिल हो सकता है, __cplusplusमैक्रो द्वारा संरक्षित किया जा रहा है :

  • जिसका अर्थ है कि, C ++ के दृष्टिकोण से, C- संगत कोड के रूप में परिभाषित किया जाएगा extern "C"
  • C के दृष्टिकोण से, सभी C कोड स्पष्ट रूप से दिखाई देंगे, लेकिन C ++ कोड छिपा होगा (क्योंकि यह C कंपाइलर में संकलित नहीं होगा)।

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

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

   #ifdef __cplusplus
      } // extern "C"
   #endif

#endif // MY_HEADER_H

या इसे संबंधित .hpp हेडर द्वारा अप्रत्यक्ष रूप से शामिल किया जा सकता है, इसे extern "C"घोषणा के साथ संलग्न करें ।

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

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

extern "C"
{
#include "my_header.h"
}

#endif // MY_HEADER_HPP

तथा:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_H

3
यह कई C ++ प्रोजेक्ट्स में काफी अस्वाभाविक है। .h फ़ाइलें बहुत संयुक्त राष्ट्र C'ish सामान के लिए उपयोग किया जाता है।
einpoklum

4
@einpoklum: बेशक। लेकिन मैं "मंकी सी मंकी डू" व्यवहार से बचने की कोशिश करता हूं। वर्तमान मामले में, दोनों एक्सटेंशन (और अन्य) उपलब्ध हैं, इसलिए मैं उन्हें वास्तव में गिनने की कोशिश करता हूं। ग्राहकों के साथ साझा किए गए कोड के साथ इस अनुबंध का होना बहुत उपयोगी है: हर कोई (यानी सैकड़ों डेवलपर्स) जानता है कि ".H" फ़ाइलों का उपयोग क्लाइंट द्वारा सी कंपाइलर का उपयोग किया जाना है, इसलिए वहाँ क्या हो सकता है या क्या नहीं है, इसके बारे में कोई गलत नहीं है नहीं। और हर एक (ग्राहकों सहित) को पता है कि ".HPP" फाइलें कभी भी C के अनुकूल नहीं होंगी। हर कोई जीतता है।
पियरसबल

4
@paercebal, ताकि आप सुझाव दे रहे हैं एच के बजाय , और .HPP से अधिक .hpp ?
ज्योफ सावेया

6
@GeofSawaya: नहीं, क्षमा करें। यह एक आदत है। लेख लिखते समय, मैं अपरकेस में एक्सटेंशन का उपयोग फ़ाइलों को उनके प्रकार से अलग करने के लिए करता हूं, जैसे ".HPP फाइलें"। लेकिन मेरी हार्ड डिस्क पर मौजूद वास्तविक फ़ाइलों के एक्सटेंशन हमेशा लोअरकेस में होते हैं, यहां तक ​​कि नाम में भी नहीं है, जैसे "MyClass.hpp" या "मॉड्यूल.hpp"
paercebal

4
धन्यवाद, @paercebal मुझे पांडित्य मिल रहा था
जिओफ़ सवेरा

48

मैंने हमेशा .hppहेडर को एक तरह का पोर्टमेन्ट्यू .hऔर .cppफाइल्स माना है ... एक हेडर जिसमें कार्यान्वयन विवरण भी होता है।

आमतौर पर जब मैंने .hppएक्सटेंशन के रूप में देखा (और उपयोग) किया है, तो कोई संगत .cppफ़ाइल नहीं है। जैसा कि दूसरों ने कहा है, यह एक कठिन और तेज़ नियम नहीं है, बस मैं .hppफ़ाइलों का उपयोग कैसे करूं ।


31

इससे कोई फर्क नहीं पड़ता कि आप किस एक्सटेंशन का उपयोग करते हैं। या तो एक ठीक है।

मैं *.hसी के लिए और *.hppसी ++ के लिए उपयोग करता हूं ।


23

EDIT [डैन निसेनबूम से जोड़ा गया सुझाव]:

एक कन्वेंशन के द्वारा .hpp फ़ाइलों का उपयोग तब किया जाता है जब प्रोटोटाइप हेडर में ही परिभाषित होते हैं। हेडर में इस तरह की परिभाषाएं टेम्पलेट के मामले में उपयोगी होती हैं, क्योंकि कंपाइलर प्रत्येक प्रकार के कोड को केवल टेम्पलेट इंस्टेंटेशन पर उत्पन्न करता है। इसलिए, यदि वे हेडर फ़ाइलों में परिभाषित नहीं हैं, तो उनकी परिभाषा अन्य संकलन इकाइयों से लिंक समय पर हल नहीं होगी। यदि आपका प्रोजेक्ट C ++ केवल प्रोजेक्ट है जो टेम्पलेट्स का भारी उपयोग करता है, तो यह सम्मेलन उपयोगी होगा।

इस कन्वेंशन का पालन करने वाले कुछ टेम्प्लेट लाइब्रेरी, हेडर को .hpp एक्सटेंशन के साथ संकेत देते हैं कि उनके पास .cpp फाइलें नहीं हैं।

एक और सम्मेलन सी हेडर के लिए .h और सी ++ के लिए .hpp का उपयोग करने के लिए है; एक अच्छा उदाहरण बढ़ावा पुस्तकालय होगा।

बूस्ट एफएक्यू से उद्धरण,

फ़ाइल एक्सटेंशन मानव और कंप्यूटर प्रोग्राम दोनों के लिए फ़ाइल के "प्रकार" का संचार करते हैं। '.H' एक्सटेंशन का उपयोग C हेडर फ़ाइलों के लिए किया जाता है, और इसलिए C ++ हेडर फ़ाइलों के बारे में गलत बात करता है। बिना एक्सटेंशन के उपयोग से कुछ भी नहीं होता है और यह निर्धारित करने के लिए फ़ाइल सामग्री के निरीक्षण को मजबूर करता है। '.Hpp' का उपयोग करते हुए, इसे सी ++ हेडर फ़ाइल के रूप में पहचानता है, और वास्तविक अभ्यास में अच्छी तरह से काम करता है। (रेनर डेके)


इसमें से कोई भी सच नहीं है, इससे कोई फर्क नहीं पड़ता कि फ़ाइल .h है या .hpp जब कोड पीढ़ी या लिंकिंग की बात आती है।
मार्क इंग्राम

क्या यह सिर्फ सम्मेलन की बात नहीं है? C ++ std लाइब्रेरी बिना किसी एक्सटेंशन के अपने सभी हेडर प्रदान करती है। ".hpp" का उपयोग करना केवल यह दर्शाता है कि प्रोटोटाइप एक ही फ़ाइल में परिभाषित किए गए हैं और कोई भी .cpp फ़ाइल नहीं होगी।
ProgramCpp

5
यह उत्तर उपयोगी है, मुझे लगता है, इस अपवाद के साथ कि यह एक बहुत ही सरल, लेकिन महत्वपूर्ण, वाक्यांश गायब है: "सम्मेलन द्वारा, भाषा के नियमों द्वारा नहीं" (कहीं)।
दान निसानबाम

13

मैंने हाल ही में *.hppc ++ हेडर के लिए उपयोग करना शुरू किया है ।

कारण यह है कि मैं अपने प्राथमिक संपादक के रूप में emacs का उपयोग करता हूं और जब आप किसी *.hफ़ाइल को लोड करते हैं, तो जब आप किसी फ़ाइल को लोड करते हैं और c ++ - मोड में स्वचालित रूप से सी-मोड में प्रवेश करते हैं *.hpp

इसके अलावा तथ्य यह है मैं चुनने के लिए कोई अच्छा कारण देखें *.hसे अधिक *.hppया इसके विपरीत।


7
व्यक्तिगत रूप से, मुझे लगता है कि C हेडर में भी C ++ हाइलाइटिंग एक अच्छा विचार है। मैं उस स्थिति के दोनों सिरों पर रहा हूँ जहाँ कोई व्यक्ति C ++ से आपके C शीर्षलेख को शामिल करना चाहता है, लेकिन यह एक C ++ कीवर्ड को एक पैरामीटर नाम के रूप में उपयोग करता है ...
स्टीव जेसप

12

मैं इसका जवाब एक अनुस्मारक के रूप में दे रहा हूं, इसी ओपी के "user1949346" उत्तर पर अपनी टिप्पणी (बिंदुओं) को इंगित करने के लिए।


तो पहले से ही जवाब दिया: या तो रास्ता ठीक है। अपने स्वयं के छापों के जोर देकर पीछा किया।

परिचयात्मक, जैसा कि पिछले नामित टिप्पणियों में भी कहा गया है, मेरी राय है कि C++हेडर एक्सटेंशन को प्रस्तावित किया जाता है .hयदि वास्तव में इसके खिलाफ कोई कारण नहीं है।

चूंकि ISO / IEC दस्तावेज़ हेडर फ़ाइलों के इस अंकन का उपयोग करते हैं और .hppउनके भाषा दस्तावेज़ों में कोई स्ट्रिंग मिलान भी नहीं होता है C++

लेकिन मैं अब एक उचित कारण के लिए लक्ष्य कर रहा हूं कि दोनों में से कोई भी तरीका ठीक है, और विशेष रूप से यह स्वयं की भाषा का विषय क्यों नहीं है।

तो अब हम शुरू करें।

C++प्रलेखन (मैं वास्तव में संस्करण N3690 से संदर्भ ले रहा हूँ) को परिभाषित करता है एक शीर्ष लेख निम्न सिंटैक्स के अनुरूप नहीं है:

2.9 हैडर के नाम

header-name:
    < h-char-sequence >
    " q-char-sequence "
h-char-sequence:
    h-char
    h-char-sequence h-char
h-char:
    any member of the source character set except new-line and >
q-char-sequence:
    q-char
    q-char-sequence q-char
q-char:
    any member of the source character set except new-line and "

तो जैसा कि हम इस भाग से निकाल सकते हैं, हेडर फ़ाइल नाम कुछ भी हो सकता है जो स्रोत कोड में मान्य है। '\n'पात्रों को छोड़कर और अगर यह इसे शामिल करने पर निर्भर करता है, तो इसे शामिल <>करने की अनुमति नहीं है >। या दूसरे तरीके से अगर इसे शामिल किया गया है तो इसे ""शामिल करने की अनुमति नहीं है "

दूसरे शब्दों में: यदि आपके पास फ़ाइलनामों का समर्थन करने वाला वातावरण है prettyStupidIdea.>, जैसे कि:

#include "prettyStupidIdea.>"

मान्य होगा, लेकिन:

#include <prettyStupidIdea.>>

अमान्य होगा। उसी के आसपास दूसरा रास्ता।

और भी

#include <<.<>

एक मान्य समावेशी हेडर फ़ाइल नाम होगा।

यहां तक ​​कि यह इसके अनुरूप होगा C++, यह एक बहुत ही सुंदर विचार होगा, थो।

और यही कारण .hppहै कि मान्य भी है।

लेकिन यह भाषा के लिए निर्णय लेने वाली समितियों का परिणाम नहीं है!

इसलिए उपयोग करने के बारे में चर्चा करना इस बारे में करने के .hppसमान है .cc, .mmया इस विषय पर अन्य पोस्ट में मैंने कभी और क्या पढ़ा है।

मुझे स्वीकार करना होगा कि मेरे पास कोई सुराग नहीं है जहां 1.hpp से आया था , लेकिन मैं कुछ पार्सिंग टूल, आईडीई या किसी अन्य चीज़ के आविष्कारक से शर्त लगा सकता हूं जो इस विचार से आया था कि कुछ आंतरिक प्रक्रियाओं का अनुकूलन करने के लिए या केवल कुछ का आविष्कार करने के लिए (शायद उनके लिए भी जरूरी है) ) नए नामकरण सम्मेलनों।C++

लेकिन यह भाषा का हिस्सा नहीं है।

और जब भी कोई इसे इस तरह इस्तेमाल करने का फैसला करता है। यह हो सकता है क्योंकि वह इसे सबसे अधिक पसंद करता है या क्योंकि वर्कफ़्लो के कुछ अनुप्रयोगों को इसकी आवश्यकता होती है, यह कभी भी 2 भाषा की आवश्यकता नहीं है। तो जो कोई भी कहता है कि "पीपी इसलिए है क्योंकि इसका उपयोग सी ++ के साथ किया जाता है", बस भाषाओं की परिभाषा के संबंध में गलत है।

C ++ पिछले पैराग्राफ का सम्मान करने वाली किसी भी चीज़ की अनुमति देता है। और अगर कोई ऐसी चीज है जिसका उपयोग करने के लिए समिति ने प्रस्तावित किया है, तो यह उपयोग कर रहा है .hक्योंकि यह आईएसओ दस्तावेज़ के सभी उदाहरणों में मुकदमा दायर किया गया है।

निष्कर्ष:

जब तक आपको .hओवर .hppया वाइज़ वर्सा के उपयोग की कोई आवश्यकता नहीं दिखती / महसूस नहीं होती , आपको परेशान नहीं होना चाहिए। क्योंकि दोनों मानक के संबंध में समान गुणवत्ता का वैध हेडर नाम होगा। और इसलिए कुछ भी है कि आवश्यकता है आप उपयोग करना .hया .hppमानक जो भी अन्य अतिरिक्त प्रतिबंधों का खंडन किया जा सकता है की एक अतिरिक्त प्रतिबंध नहीं है नहीं एक दूसरे के साथ अनुरूप हैं। लेकिन जैसा कि ओपी ने किसी भी अतिरिक्त भाषा प्रतिबंध का उल्लेख नहीं किया है, यह सवाल का एकमात्र सही और स्वीकार्य जवाब है

* " .h या * .अपनी कक्षा की परिभाषाओं के लिए। "

दोनों समान रूप से सही और लागू होते हैं जब तक कि कोई बाहरी प्रतिबंध मौजूद न हो।


1 जो मैं जानता हूं, जाहिरा तौर पर, यह बढ़ावा देने वाला ढांचा है जो उस .hppविस्तार के साथ आया है ।

2 बेशक मैं यह नहीं कह सकता कि कुछ भविष्य के संस्करण इसके साथ क्या लाएंगे!


7

मैं C ++ के लिए पसंद करता हूं। यह संपादकों और अन्य प्रोग्रामरों को स्पष्ट करने के लिए कि यह C हैडर फ़ाइल के बजाय C ++ हैडर है।


6

C ++ ("C Plus Plus") .cpp के रूप में समझ में आता है

एक .hpp एक्सटेंशन के साथ हेडर फाइल रखने से समान तार्किक प्रवाह नहीं होता है।


6

आप अपनी पसंद के अनुसार कॉल कर सकते हैं।

बस उस पूर्ण नाम को निर्दिष्ट करने की आवश्यकता है #include

मेरा सुझाव है कि यदि आप C के साथ काम करते हैं .hऔर जब C ++ का उपयोग करना है.hpp

यह अंत में सिर्फ एक सम्मेलन है।


5

कोडगियर C ++ बिल्डर हेडर फ़ाइलों के लिए .hpp का उपयोग करता है जो स्वचालित रूप से डेल्फी स्रोत फ़ाइलों से उत्पन्न होता है, और .h फाइलें आपकी "स्वयं" हेडर फ़ाइलों के लिए।

इसलिए, जब मैं C ++ हैडर फाइल लिख रहा होता हूं, तो मैं हमेशा इस्तेमाल करता हूं।


5

90 के दशक की शुरुआत में मेरी एक नौकरी में, हमने क्रमशः स्रोत और हेडर फ़ाइलों के लिए .cc और .hh का उपयोग किया था। मैं अभी भी सभी विकल्पों पर इसे पसंद करता हूं, शायद इसलिए कि यह टाइप करना सबसे आसान है।


5

Bjarne Stroustrup और Herb Sutter ने अपने C ++ कोर दिशानिर्देशों में इस प्रश्न का विवरण दिया है: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGidelines.md#S-source जो नवीनतम परिवर्तनों का भी उल्लेख कर रहा है। मानक विस्तार में (C ++ 11, C ++ 14, आदि)

SF.1: कोड फ़ाइलों के लिए एक .cpp प्रत्यय का उपयोग करें और यदि आपके Y प्रोजेक्ट पहले से ही किसी अन्य सम्मेलन के आदेश का पालन नहीं करता है, तो इंटरफ़ेस फ़ाइलों के लिए .h

यह लंबे समय तक चलने वाला सम्मेलन है। लेकिन संगति अधिक महत्वपूर्ण है, इसलिए यदि आपका प्रोजेक्ट कुछ और उपयोग करता है, तो उसका पालन करें। ध्यान दें

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

विशिष्ट नाम .h और .cpp की आवश्यकता नहीं है (केवल एक डिफ़ॉल्ट के रूप में अनुशंसित) और अन्य नाम व्यापक उपयोग में हैं। उदाहरण हैं .hh, .C, और .cxx ऐसे नामों का बराबर उपयोग करें। इस दस्तावेज़ में, हम हेडर और कार्यान्वयन फ़ाइलों के लिए शॉर्टहैंड के रूप में .h और .cpp> को संदर्भित करते हैं, भले ही वास्तविक विस्तार अलग हो सकता है।

आपकी आईडीई (यदि आप एक का उपयोग करते हैं) में घुटनों के बारे में मजबूत राय हो सकती है।

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


4

जैसा कि यहाँ कई पहले ही उल्लेख कर चुके हैं, मैं भी हेडर-केवल पुस्तकालयों के लिए .hpp का उपयोग करना पसंद करता हूँ जो टेम्पलेट कक्षाओं / कार्यों का उपयोग करते हैं। मैं .cpp सोर्स फाइल्स या शेयर्ड या स्टैटिक लाइब्रेरीज़ के साथ हेडर फाइल्स के लिए .h का उपयोग करना पसंद करता हूँ।

मेरे द्वारा विकसित किए गए अधिकांश पुस्तकालय टेम्पलेट आधारित हैं और इस प्रकार केवल हेडर होने की आवश्यकता होती है, लेकिन जब मैं अनुप्रयोग लिखता हूं तो कार्यान्वयन से अलग घोषणा की जाती है और .h और .cpp फ़ाइलों के साथ समाप्त हो जाती है।


3

सौभाग्य से, यह सरल है।

यदि आप C ++ के साथ काम कर रहे हैं तो आपको .hpp एक्सटेंशन का उपयोग करना चाहिए और आपको C या C ++ को मिलाने के लिए .h का उपयोग करना चाहिए।


2

मैं .h का उपयोग करता हूं क्योंकि यही Microsoft उपयोग करता है, और उनका कोड जनरेटर क्या बनाता है। अनाज के खिलाफ जाने की जरूरत नहीं है।


हर जगह नहीं, बहुत सारे उदाहरणों में (eq WINDDK) वे इस्तेमाल करते हैं ।hpp
marsh-wiggle

13
C ++ में आने पर मैं Microsoft को 'दाना' नहीं कहूंगा।
डेवलेपर

@ यह तब है जब वह आपका काम है। और यहां तक ​​कि अगर यह नहीं है, तो यह एक लोकप्रिय लोकप्रिय संकलक है।
मार्क रैनसम

@MarkRansom मैं सी। IMO VC ++ का उपयोग करने के Microsoft के इतिहास का अधिक उल्लेख कर रहा था जो एक उत्कृष्ट संकलक है।
डेवलपर

1
@developerbmw मैं कहूंगा कि MSVC विंडोज कार्यक्रमों के लिए अनाज है, और जीसीसी व्यक्तिगत रूप से * निक्स कार्यक्रमों के लिए अनाज है। वे उन प्लेटफार्मों के लिए सबसे अधिक अन्य संकलक हैं, जो मेरे ज्ञान के अनुरूप होने की कोशिश करते हैं।
जस्टिन टाइम - मोनिका

1

"द सी ++ प्रोग्रामिंग लैंग्वेज, थर्ड एडिशन बाय बजरन स्ट्रॉस्ट्रुप", nº1 को C ++ पुस्तक को पढ़ना चाहिए, वह * .h का उपयोग करता है। तो मुझे लगता है कि सबसे अच्छा अभ्यास * .h का उपयोग करना है।

हालाँकि, * .hpp ठीक भी है!


1
यदि किसी ने किसी चीज़ के बारे में एक किताब लिखी है जो उसने दूसरों से सीखी है जो उसने दूसरे से सीखी है (शायद उसी के साथ किस्मत में) किताब, किसी ऐसे व्यक्ति द्वारा लिखी गई, जिसके पास शायद प्राथमिक स्रोत उपलब्ध था, तो यह वह है जो कुछ भी कर रहे हैं, लेकिन उसके लिए कोई निशान नहीं सबसे अच्छा अभ्यास मधुमक्खी।
dhein

बस उल्लेख करने के लिए: मैंने वास्तव में यह डाउट किया था। लेकिन मैंने इसे उखाड़ फेंका होगा, अगर उसने कहा कि "आईएसओ / आईईसी एन 3690" या "सी सी + प्रोग्रामिंग लैंग्वेज के किसी अन्य सी + ड्राफ्ट, बजरने स्ट्रॉस्ट्रुप द्वारा तीसरा संस्करण"। हालांकि यह एक मान्य बिंदु होता, क्योंकि .hppभाषा द्वारा स्वयं इसका कोई उल्लेख नहीं है ।
धेन

9
@ फैज़िस क्या आप जानते हैं कि बज़्ने स्ट्रॉस्ट्रुप ने सी ++ का आविष्कार किया था?
१०:३० बजे

@tumtumtum: प्रशंसा की, मुझे इस बारे में जानकारी नहीं थी। लेकिन वैसे भी, उस मामले में भी, इसका अभी भी कॉमिटेटी का दस्तावेज, मानक को बनाए रखता है, जिसे लेने की पुनरावृत्ति है। भले ही वह भाषा का आविष्कारक हो, यह उसका निर्णय नहीं है। तो, जबकि यह इस उत्तर को अधिक स्पष्ट करता है, फिर भी यह एक उचित तर्क नहीं है।
दिीन

1

औजारों और मनुष्यों के लिए कुछ अलग करना आसान है । बस।

पारंपरिक उपयोग में (बढ़ावा, आदि), .hppविशेष रूप से C ++ हेडर है। दूसरी ओर, .hगैर-सी ++ के लिए है - केवल हेडर (मुख्य रूप से सी)। सामग्री की भाषा का ठीक-ठीक पता लगाने के लिए आम तौर पर कठिन है क्योंकि कई गैर-तुच्छ मामले हैं, इसलिए यह अंतर अक्सर तैयार-टू-उपयोग टूल को लिखने में आसान बनाता है। मनुष्यों के लिए, एक बार सम्मेलन प्राप्त करने के बाद, यह याद रखना भी आसान है और उपयोग में आसान है।

हालाँकि, मैं चाहता हूँ कि कन्वेंशन अपने आप हमेशा काम न करे, जैसा कि अपेक्षित था।

  • यह भाषाओं के विनिर्देशन से मजबूर नहीं है , न ही C और न ही C ++। कई परियोजनाएं मौजूद हैं जो सम्मेलन का पालन नहीं करती हैं। एक बार जब आपको उन्हें मिलाने (मिलाने) की आवश्यकता होती है, तो यह परेशानी हो सकती है।
  • .hppखुद ही एकमात्र विकल्प नहीं है। क्यों .hhया नहीं .hxx? (वैसे भी, आपको आमतौर पर फ़ाइल नाम और पथ के बारे में कम से कम एक पारंपरिक नियम की आवश्यकता होती है।)

मैं व्यक्तिगत रूप से .hऔर .hppअपने C ++ प्रोजेक्ट्स में दोनों का उपयोग करता हूं। मैं ऊपर दिए गए अधिवेशन का अनुसरण नहीं करता क्योंकि:

  • परियोजनाओं के प्रत्येक भाग द्वारा उपयोग की जाने वाली भाषाओं को स्पष्ट रूप से प्रलेखित किया गया है। C और C ++ को एक ही मॉड्यूल (डायरेक्टरी) में मिलाने का कोई मौका नहीं। इस नियम के अनुरूप हर 3 वें पुस्तकालय की आवश्यकता होती है।
  • अनुरूपित भाषा विनिर्देशों और परियोजनाओं द्वारा प्रयुक्त भाषा बोलियों को भी प्रलेखित किया गया है। (वास्तव में, मैं मानक सुविधाओं और बग फिक्स (भाषा मानक पर) के स्रोत का भी उपयोग करता हूं । संकलक संगतता) महत्वपूर्ण (जटिल और समय लेने वाली) हो सकती है, खासकर एक परियोजना में जो पहले से ही लगभग शुद्ध सी ++ में है। इसे संभालने के लिए फ़ाइलनाम बहुत कमजोर हैं।
  • समान सी ++ बोली के लिए भी, अंतर के लिए उपयुक्त अधिक महत्वपूर्ण गुण हो सकते हैं। उदाहरण के लिए, नीचे दिए गए सम्मेलन को देखें।
  • फ़ाइलनाम मूल रूप से नाजुक मेटाडेटा के टुकड़े हैं। सम्मेलन के उल्लंघन का पता लगाना इतना आसान नहीं है। सामग्री को स्थिर करने के लिए, एक उपकरण को अंततः केवल नामों पर निर्भर नहीं होना चाहिए। एक्सटेंशन के बीच का अंतर केवल एक संकेत है। इसका उपयोग करने वाले उपकरणों से हर समय समान व्यवहार की उम्मीद नहीं की जानी चाहिए, उदाहरण के लिए .hgithub.com पर फाइलों का पता लगाना । ( इन स्रोत फ़ाइलों के बेहतर मेटाडेटा होने के लिए शेबंग जैसी टिप्पणियों में कुछ हो सकता है , लेकिन यह फ़ाइल नाम की तरह पारंपरिक भी नहीं है, इसलिए सामान्य रूप से भी विश्वसनीय नहीं है।)

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


0

स्रोत फ़ाइल के विस्तार का आपके बिल्ड सिस्टम के लिए अर्थ हो सकता है, उदाहरण के लिए, आपके पास फ़ाइल .cppया .cफ़ाइल के लिए आपके मेकाइल में एक नियम हो सकता है , या आपका कंपाइलर (जैसे Microsoft cl.exe) एक्सटेंशन के आधार पर फ़ाइल को C या C ++ के रूप में संकलित कर सकता है।

क्योंकि आपको #includeनिर्देशन में संपूर्ण फ़ाइल नाम प्रदान करना है , हेडर फ़ाइल एक्सटेंशन अप्रासंगिक है। .cयदि आप चाहें, तो आप किसी अन्य स्रोत फ़ाइल में एक फ़ाइल शामिल कर सकते हैं , क्योंकि यह सिर्फ एक पाठात्मक शामिल है। आपके कंपाइलर के पास प्रीप्रोसेस्ड आउटपुट को डंप करने का विकल्प हो सकता है जो यह स्पष्ट कर देगा (Microsoft: /Pफाइल /Eको प्रीप्रोसेस करने के लिए stdout, प्रीप्रोसेस करने के लिए , डायरेक्ट्री /EPको छोड़ना #line, /Cटिप्पणियों को बनाए रखने के लिए)

आप .hppउन फ़ाइलों के लिए उपयोग करना चुन सकते हैं जो केवल C ++ वातावरण के लिए प्रासंगिक हैं, अर्थात वे उन सुविधाओं का उपयोग करते हैं जो C में संकलित नहीं होंगे।


0

किसी विशेष विस्तार से कोई लाभ नहीं है, इसके अलावा आपके लिए एक अलग अर्थ हो सकता है, संकलक और / या आपके उपकरण। header.hएक वैध हेडर है। header.hppएक वैध हेडर है। header.hhएक वैध हेडर है। header.hxएक वैध हेडर है। h.headerएक वैध हेडर है। this.is.not.a.valid.headerइनकार में एक वैध हेडर है। ihjkflajfajfklafएक वैध हेडर है। जब तक नाम संकलक द्वारा ठीक से पार्स किया जा सकता है, और फ़ाइल सिस्टम इसका समर्थन करता है, यह एक वैध हेडर है, और इसके विस्तार का एकमात्र लाभ यह है कि कोई भी इसमें पढ़ता है।

कहा जा रहा है, विस्तार के आधार पर सही अनुमान लगाने में सक्षम होना बहुत उपयोगी है, इसलिए आपकी हेडर फ़ाइलों के लिए आसानी से समझने योग्य नियमों का उपयोग करना बुद्धिमानी होगी। व्यक्तिगत रूप से, मैं ऐसा कुछ करना पसंद करता हूं:

  1. यदि पहले से कोई दिशा-निर्देश हैं, तो भ्रम को रोकने के लिए उनका पालन करें।
  2. यदि प्रोजेक्ट की सभी स्रोत फ़ाइलें समान भाषा के लिए हैं, तो उपयोग करें .h। कोई अस्पष्टता नहीं है।
  3. यदि कुछ हेडर कई भाषाओं के साथ संगत हैं, जबकि अन्य केवल एक ही भाषा के साथ संगत हैं, तो एक्सटेंशन सबसे अधिक प्रतिबंधात्मक भाषा पर आधारित हैं, जो हेडर के साथ संगत है। C, C या C ++ दोनों के साथ .hसंगत हेडर मिलता है , जबकि C ++ के साथ हैडर संगत होता है, लेकिन C किसी प्रकार का C .hppया नहीं मिलता है .hh

यह, ज़ाहिर है, लेकिन एक्सटेंशन को संभालने के कई तरीकों में से एक है , और अगर चीजें सीधी लगती हैं, तो भी आप अपनी पहली छाप पर भरोसा नहीं कर सकते। उदाहरण के लिए, मैंने .hसामान्य हेडर के लिए उपयोग करने का उल्लेख किया है , और .tppहेडर के लिए जिसमें केवल अस्थायी वर्ग सदस्य फ़ंक्शंस की परिभाषाएँ होती हैं, .hफ़ाइलों के साथ टेम्पर्ड क्लासेस को परिभाषित करने वाली .tppफ़ाइलें जिनमें उनके सदस्य फ़ंक्शंस परिभाषित होते हैं ( .hहेडर के बजाय सीधे दोनों शामिल होते हैं। समारोह की घोषणा और परिभाषा)। एक और उदाहरण के लिए, एक अच्छा कई लोग हमेशा हेडर की भाषा को उसके विस्तार में दर्शाते हैं, यहां तक ​​कि जब अस्पष्टता का कोई मौका नहीं होता है; उनके लिए, .hहमेशा एक C हैडर और .hpp(या) होता है.hh ,) होता है.hxxआदि) हमेशा C ++ हैडर होता है। और फिर भी, कुछ लोग .h"हेडर को एक स्रोत फ़ाइल से जुड़े" और .hpp"हेडर इन सभी फ़ंक्शन इनलाइन के साथ हेडर" के लिए उपयोग करते हैं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.