কেন সি ++ এর জন্য পৃথক শিরোনামের ফাইল দরকার?


138

আমি কখনই বুঝতে পারি নি যে কেন সি ++ কে .cpp ফাইলের মতো একই ফাংশনগুলির সাথে পৃথক শিরোনাম ফাইলের প্রয়োজন। এটি ক্লাস তৈরি করে এবং তাদেরকে পুনরায় চুলকানো খুব কঠিন করে তোলে এবং এটি প্রকল্পে অপ্রয়োজনীয় ফাইল যুক্ত করে। এবং তারপরে হ্যাডার ফাইলগুলি অন্তর্ভুক্ত করার ক্ষেত্রে সমস্যা রয়েছে, তবে এটি ইতিমধ্যে অন্তর্ভুক্ত করা হয়েছে কিনা তা স্পষ্ট করে পরীক্ষা করে দেখতে হবে।

সি ++ 1998 সালে অনুমোদিত হয়েছিল, সুতরাং কেন এটি এভাবে ডিজাইন করা হয়েছে? একটি পৃথক শিরোনাম ফাইল থাকার কি কি সুবিধা আছে?


প্রশ্ন অনুসরণ করুন:

সংকলকটি কোড সহ .cpp ফাইলটি কীভাবে সন্ধান করবে, যখন আমি অন্তর্ভুক্ত সমস্তই .h ফাইল? এটি কি ধরে নিয়েছে যে .cpp ফাইলটির .h ফাইলের মতোই নাম রয়েছে, বা এটি আসলে ডিরেক্টরি গাছের সমস্ত ফাইলের মধ্য দিয়ে দেখে?


2
আপনি যদি একটি একক ফাইল সম্পাদনা করতে চান তবে শুধুমাত্র চেকআউট lzz (www.lazycplusplus.com)।
রিচার্ড কর্ডেন

উত্তর:


105

আপনি শিরোনামগুলি থেকে সংজ্ঞাগুলি পৃথক করার বিষয়ে জিজ্ঞাসা করছেন বলে মনে হচ্ছে, যদিও শিরোলেখ ফাইলগুলির জন্য অন্যান্য ব্যবহার রয়েছে।

উত্তরটি হ'ল সি ++ এর "দরকার নেই"। আপনি যদি সমস্ত কিছু ইনলাইন চিহ্নিত করেন (যা কোনও শ্রেণীর সংজ্ঞায় সংজ্ঞায়িত সদস্য ফাংশনগুলির জন্য যাইহোক স্বয়ংক্রিয় হয়), তবে আলাদা করার প্রয়োজন নেই। আপনি কেবল শিরোনাম ফাইলগুলিতে সমস্ত কিছু সংজ্ঞায়িত করতে পারেন।

যে কারণগুলি আপনি আলাদা করতে চাইতে পারেন তা হ'ল:

  1. বিল্ড টাইম উন্নতি করতে।
  2. সংজ্ঞাগুলির সংস্থান না করে কোডের সাথে লিঙ্ক করা।
  3. "ইনলাইন" সমস্ত কিছু চিহ্নিত করা এড়াতে।

যদি আপনার আরও সাধারণ প্রশ্নটি হয়, "কেন সি ++ জাভার সাথে অভিন্ন নয়?", তবে আমাকে জিজ্ঞাসা করতে হবে, "আপনি জাভার পরিবর্তে সি ++ কেন লিখছেন?" ;-p

আরও গুরুতরভাবে, যদিও, কারণটি হ'ল সি ++ সংকলকটি কেবল অন্য অনুবাদ ইউনিটে পৌঁছাতে পারে না এবং জাভ্যাক যেভাবে পারে এবং কীভাবে তার চিহ্নগুলি কীভাবে ব্যবহার করতে হয় তা নির্ধারণ করতে পারে না। সংযোগকারীটিকে লিঙ্ক সময়ে কী কী পাওয়া যাবে বলে আশা করা যায় তা সংজ্ঞায়িত করতে হেডার ফাইলটি প্রয়োজন

তাই #includeসোজা পাঠগত প্রতিস্থাপন করা হয়। আপনি যদি শিরোলেখ ফাইলগুলিতে সমস্ত কিছু সংজ্ঞায়িত করেন তবে প্রিপ্রসেসর আপনার প্রকল্পের প্রতিটি উত্স ফাইলের একটি বিশাল অনুলিপি এবং পেস্ট তৈরি করে এবং সংযোজকটিতে ফিড করে। ১৯৯৯ সালে সি ++ স্ট্যান্ডার্ডটি অনুমোদিত হয়েছিল এর সাথে এর কোন যোগসূত্র নেই, এটি সত্য যে সি ++ এর জন্য সংকলন পরিবেশটি সি এর সাথে এত বেশি ঘনিষ্ঠভাবে নির্মিত।

আপনার ফলোআপ প্রশ্নের উত্তর দেওয়ার জন্য আমার মন্তব্যগুলিতে রূপান্তর করা:

সংকলকটিতে কোড সহ .cpp ফাইলটি কীভাবে সন্ধান করবে

এটি হ'ল, অন্তত এমন সময় নয় যা শিরোনাম ফাইলটি ব্যবহার করে এমন কোডটি সংকলন করে। যে ফাংশনগুলির সাথে আপনি লিঙ্ক করছেন তার এমনকি এখনও লেখার দরকার নেই, কম্পাইলারটি কোনও .cppফাইলের মধ্যে থাকবে তা জেনেও কিছু মনে করবেন না comp সংকলনের সময় কলিং কোডটি যা জানা দরকার তা ফাংশন ঘোষণায় প্রকাশ করা হয়। লিঙ্কের সময়ে আপনি .oফাইলগুলির একটি তালিকা বা স্থিতিশীল বা গতিশীল লাইব্রেরি সরবরাহ করবেন এবং কার্যত শিরোনাম একটি প্রতিশ্রুতি দেয় যে কার্যগুলির সংজ্ঞাগুলি কোথাও সেখানে থাকবে।


3
"আপনি যে কারণে পৃথক করতে চাইতে পারেন সেগুলি যুক্ত করার জন্য:" এবং আমি শিরোনাম ফাইলগুলির সবচেয়ে গুরুত্বপূর্ণ কাজটি হ'ল: কোড কাঠামো নকশাকে বাস্তবায়ন থেকে পৃথক করা, কারণ: এ। আপনি যখন এমন অনেক জটিল কাঠামোতে প্রবেশ করেন যা অনেকগুলি বিষয়কে জড়িত করে এটি হেডার ফাইলগুলির মধ্য দিয়ে যাওয়া এবং এটি কীভাবে একসাথে কাজ করে তা আপনার শিরোনামের মন্তব্য দ্বারা পরিপূরক করা খুব সহজ। বি। একজন ব্যক্তি সমস্ত অবজেক্টের কাঠামো সংজ্ঞায়নের বিষয়ে যত্ন নিচ্ছেন না এবং অন্য কেউ বাস্তবায়নের যত্ন নিচ্ছেন এটি জিনিসগুলিকে সংগঠিত রাখে। সর্বোপরি আমি মনে করি এটি জটিল কোডটিকে আরও পঠনযোগ্য করে তোলে।
আন্দ্রেস ক্যানেলা

একটি সহজ উপায়ে আমি শিরোনাম বনাম সিপিপি ফাইলগুলির বিচ্ছিন্নতার ইন্টারফেস বনাম বাস্তবায়ন যা মাঝারি / বড় প্রকল্পগুলির জন্য সত্যই সহায়তা করে তা পৃথক করা এর কার্যকারিতা সম্পর্কে ভাবতে পারি।
কৃষ্ণা ওজা

আমার উদ্দেশ্য ছিল যে (2), "সংজ্ঞা ছাড়াই কোডের বিরুদ্ধে লিঙ্ক" অন্তর্ভুক্ত করা হবে। ঠিক আছে, সুতরাং আপনার গিটার রেপোতে সংজ্ঞা সংজ্ঞা সহ এখনও অ্যাক্সেস থাকতে পারে তবে মূল বিষয়টি হল আপনি নিজের কোডটিকে তার নির্ভরতার বাস্তবায়ন থেকে আলাদাভাবে সংকলন করতে পারেন এবং তারপরে লিঙ্ক করতে পারেন। আক্ষরিক অর্থে আপনি যা চান তা হ'ল আলাদাভাবে বিল্ডিংয়ের জন্য কোনও উদ্বেগ না রেখে ইন্টারফেস / বাস্তবায়নকে আলাদা আলাদা ফাইলে বিভক্ত করা, তবে আপনি কেবল foo_interface.h এ foo_implementation.h অন্তর্ভুক্ত করে এটি করতে পারেন।
স্টিভ জেসপ

4
@ AndresCanella না এটি হয় না। এটি আপনার নিজের কোডটি না-পড়া পড়া এবং বজায় রাখে একটি দুঃস্বপ্ন। কোডটিতে কিছু কী করে তা সম্পূর্ণরূপে বুঝতে আপনার এন ফাইলের পরিবর্তে 2n ফাইলের মধ্য দিয়ে ঝাঁপিয়ে পড়া দরকার। এটি কেবল বিগ-ওহ স্বরলিপি নয়, 2 এন কেবলমাত্র এন এর তুলনায় অনেক পার্থক্য করে।
Bżażej মিশালিক

1
আমি দ্বিতীয় যে এটি একটি মিথ্যা যে শিরোনাম সাহায্য করে। উদাহরণস্বরূপ মিনিক্স উত্স পরীক্ষা করুন, এটি নিয়ন্ত্রণ করা কোথায় শুরু হয়, যেখানে জিনিসগুলি ঘোষিত / সংজ্ঞায়িত করা হয় সেখানে অনুসরণ করা এত শক্ত .. এটি যদি আলাদা গতিশীল মডিউলগুলির মাধ্যমে নির্মিত হয় তবে এটি একটি জিনিসের বুদ্ধি তৈরি করে হজমযোগ্য হবে তারপরে ঝাঁপিয়ে পড়ুন একটি নির্ভরতা মডিউল। পরিবর্তে, আপনাকে শিরোনাম অনুসরণ করতে হবে এবং এটি কোনও কোড লিখিতভাবে পড়তে পারে hell বিপরীতে, নোডেজগুলি পরিষ্কার করে দেয় যে কোনও ইফদেফ ছাড়াই কোথা থেকে আসে এবং আপনি কোথা থেকে এসেছেন তা সহজেই সনাক্ত করতে পারেন।
দিমিত্রি

91

সি ++ এটি সেভাবে করে কারণ সি এটি সেভাবে করেছিল তাই আসল প্রশ্নটি কেন সি সেভাবে এটি করেছিল? উইকিপিডিয়া এ সম্পর্কে একটু কথা বলে।

আরও নতুন সংকলিত ভাষা (যেমন জাভা, সি #) এগিয়ে ঘোষণাগুলি ব্যবহার করে না; সনাক্তকারীরা উত্স ফাইলগুলি থেকে স্বয়ংক্রিয়ভাবে স্বীকৃত হয় এবং ডায়নামিক লাইব্রেরি প্রতীক থেকে সরাসরি পড়ে। এর অর্থ হেডার ফাইলগুলির দরকার নেই।


13
+1 মাথায় পেরেক আঘাত করে। এটির জন্য সত্যিকার অর্থে একটি ভার্বোজ ব্যাখ্যা প্রয়োজন হয় না।
এমএসএলটাররা

6
এটি আমার পেরেকটি মাথায় আঘাত করেনি :( আমি এখনও দেখতে হবে কেন সি ++ কেন সামনের ঘোষণাগুলি ব্যবহার করতে হবে এবং কেন এটি উত্স ফাইলগুলি থেকে সনাক্তকারী সনাক্ত করতে পারে না এবং ডায়নামিক লাইব্রেরি প্রতীক থেকে সরাসরি পড়তে পারে না, এবং সি ++ কেন এটি করেছে? সি কেবল সেভাবে করেছে কারণ: পি
আলেকজান্ডার টেলর

3
এবং @ আলেকজান্ডার টেলর :) এর জন্য আপনি আরও ভাল প্রোগ্রামার হলেন :)
ডোনাল্ড বায়ার্ড

66

কিছু লোক হেডার ফাইলগুলিকে একটি সুবিধা হিসাবে বিবেচনা করে:

  • দাবি করা হয় যে এটি ইন্টারফেস এবং প্রয়োগের পৃথককরণকে সক্ষম / প্রয়োগ / সক্ষম করে - তবে সাধারণত, এটি ক্ষেত্রে হয় না। হেডার ফাইল বাস্তবায়ন বিবরণ পূর্ণ ফাংশন করতে পারেন (একটি বর্গ উদাহরণ সদস্য ভেরিয়েবল এমনকি যদিও তারা প্রকাশ্য ইন্টারফেসের অংশ নও হেডারের মধ্যে উল্লেখ করা আছে,), এবং, এবং প্রায়ই, ইনলাইন সংজ্ঞায়িত করা হয় মধ্যে বর্গ ঘোষণা শিরোনামে, আবার এই বিচ্ছেদটি ধ্বংস করছে ying
  • কখনও কখনও এটি সংকলন-সময় উন্নতি করতে বলা হয় কারণ প্রতিটি অনুবাদ ইউনিট স্বাধীনভাবে প্রক্রিয়া করা যেতে পারে। এবং এখনও সি ++ হ'ল অস্তিত্বের সবচেয়ে ধীরতম ভাষা এটি যখন সংকলনের সময় আসে times কারণটির একটি অংশ হ'ল একই শিরোনামের অনেকগুলি বারবার অন্তর্ভুক্তি। বিপুল সংখ্যক শিরোলেখ একাধিক অনুবাদ ইউনিট অন্তর্ভুক্ত রয়েছে, যার জন্য একাধিকবার পার্স করা প্রয়োজন।

শেষ পর্যন্ত, শিরোনামটি হ'ল 70 এর দশক থেকে সি নকশা করা হয়েছিল এমন একটি নিদর্শন। তারপরে কম্পিউটারগুলির খুব কম স্মৃতি ছিল এবং পুরো মডিউলটিকে কেবল মেমরির মধ্যে রাখা কোনও বিকল্প ছিল না। একটি সংকলককে শীর্ষে ফাইলটি পড়া শুরু করতে হবে এবং তারপরে উত্স কোডের মাধ্যমে লিনিয়ার প্রবর্তন করতে হয়েছিল। শিরোনাম প্রক্রিয়া এটি সক্ষম করে। সংকলকটিকে অন্যান্য অনুবাদ ইউনিট বিবেচনা করতে হবে না, এটি কেবল উপরে থেকে নীচে কোডটি পড়তে হবে।

এবং সি ++ পিছনের সামঞ্জস্যের জন্য এই সিস্টেমটিকে ধরে রেখেছে।

আজ, এটি কোন মানে করে না। এটি অদক্ষ, ত্রুটি-প্রবণ এবং অতি-জটিল omp যদি সেখানে আলাদা ইন্টারফেস এবং বাস্তবায়নে অনেক ভালো উপায় আছে যে উদ্দেশ্য ছিল।

যাইহোক, সি ++ 0 এক্স এর একটি প্রস্তাব ছিল একটি উপযুক্ত মডিউল সিস্টেম যুক্ত করা, কোডটি .NET বা জাভা এর মতো সংকলন করে বৃহত্তর মডিউলগুলিতে, একসাথে এবং শিরোনাম ছাড়াই। এই প্রস্তাবটি সি ++ 0x এ কাটেনি, তবে আমি বিশ্বাস করি এটি এখনও "আমরা এটি পরে করতে চাই" বিভাগে রয়েছি। সম্ভবত একটি টিআর 2 বা অনুরূপ।


এই পৃষ্ঠায় সেরা উত্তর। ধন্যবাদ!
চক লে বাট

29

আমার (সীমাবদ্ধ - আমি সাধারনত সি বিকাশকারী নই) বোঝার জন্য, এটি সিতে নিযুক্ত। মনে রাখবেন যে ক্লাস বা নেমস্পেসগুলি কী তা সি জানেন না, এটি কেবল একটি দীর্ঘ প্রোগ্রাম। এছাড়াও, ফাংশনগুলি ব্যবহার করার আগে আপনাকে তাদের ঘোষণা করতে হবে।

উদাহরণস্বরূপ, নিম্নলিখিতগুলির একটি সংকলক ত্রুটি দেওয়া উচিত:

void SomeFunction() {
    SomeOtherFunction();
}

void SomeOtherFunction() {
    printf("What?");
}

ত্রুটিটি এমন হওয়া উচিত যে "SomeOथरFunction ঘোষণা করা হয়নি" কারণ আপনি এটি ঘোষণার আগেই এটি কল করেছেন। এটি ঠিক করার একটি উপায় হ'ল সামোর ফাংশনের উপরে সামোথার ফাংশনটি সরানো। আরেকটি পদ্ধতি হ'ল প্রথমে ফাংশনগুলির স্বাক্ষর ঘোষণা করা:

void SomeOtherFunction();

void SomeFunction() {
    SomeOtherFunction();
}

void SomeOtherFunction() {
    printf("What?");
}

এটি সংকলকটি জানতে দেয়: কোডটির কোথাও দেখুন, সোমারোথার ফাংশন নামে একটি ফাংশন রয়েছে যা শূন্য করে দেয় এবং কোনও পরামিতি নেয় না। সুতরাং যদি আপনি হিটটার কোডর যা সামোথার ফাংশনকে কল করতে চেষ্টা করে, আতঙ্কিত হবেন না এবং পরিবর্তে এটি সন্ধান করুন।

এখন, কল্পনা করুন যে আপনার কাছে দুটি পৃথক .c ফাইলে সামু ফাংশন এবং সামোথার ফাংশন রয়েছে। তারপরে আপনাকে সামার.কে "সামোরআউট.আর.সি." অন্তর্ভুক্ত করতে হবে। এখন, সামোথর সি.কে কিছু "ব্যক্তিগত" ফাংশন যুক্ত করুন। যেহেতু সি ব্যক্তিগত ফাংশনগুলি জানে না, সেই ফাংশনটি সামার সি.এস. তেও উপলব্ধ।

এখানেই .h ফাইলগুলি আসে: তারা .c ফাইল থেকে 'রফতানি' করতে চান এমন সমস্ত ফাংশন (এবং ভেরিয়েবল) নির্দিষ্ট করে যা অন্যান্য .c ফাইলগুলিতে অ্যাক্সেস করা যায়। এইভাবে, আপনি পাবলিক / প্রাইভেট স্কোপের মতো কিছু অর্জন করতে পারেন। এছাড়াও, আপনি এই উত্স কোডটি আপনার উত্স কোডটি ভাগ না করেই অন্য লোককে দিতে পারেন - .h ফাইলগুলি সংকলিত .lib ফাইলগুলির বিরুদ্ধেও কাজ করে।

সুতরাং মূল কারণটি হ'ল সুবিধার জন্য, উত্স কোড সুরক্ষার জন্য এবং আপনার অ্যাপ্লিকেশনটির অংশগুলির মধ্যে কিছুটা ডিকপলিং।

যদিও সি ছিল। সি ++ ক্লাস এবং প্রাইভেট / পাবলিক মডিফায়ার প্রবর্তন করেছে, সুতরাং আপনি এখনও তাদের প্রয়োজন কিনা জানতে চাইতে পারেন, সি ++ এএফআইএকে এখনও তাদের ব্যবহারের আগে ফাংশনগুলির ডিক্লেয়ারেশন প্রয়োজন। এছাড়াও, অনেক সি ++ বিকাশকারীরা সি সিভিলোপারও ছিলেন বা তাদের ধারণা এবং অভ্যাসগুলি সি ++ এ নিয়েছিলেন - কেন ভাঙা হয়নি?


5
সংকলক কেন কোডটির মাধ্যমে চলতে পারে না এবং সমস্ত ফাংশন সংজ্ঞা খুঁজে পায় না? এটি এমন কিছুর মতো মনে হয় যা সংকলকটিতে প্রোগ্রাম করা বেশ সহজ হবে।
মারিয়াস

3
যদি আপনার কাছে উত্স থাকে, যা আপনার প্রায়শই থাকে না। সংকলিত সি ++ কার্যকরভাবে মেশিন কোড যা লোড করতে এবং কোডটি লিঙ্ক করার জন্য পর্যাপ্ত অতিরিক্ত অতিরিক্ত তথ্য। তারপরে, আপনি এন্ট্রি পয়েন্টে সিপিইউ নির্দেশ করুন এবং এটি চালাতে দিন। এটি মূলত জাভা বা সি # থেকে আলাদা, যেখানে কোডটি কোনও বিষয়বস্তুতে মেটাডেটা যুক্ত মধ্যস্থতাকারী বাইটকোডে সংকলিত হয়।
দেবসোলার

আমি অনুমান করছি যে 1972 সালে, এটি সংকলকটির জন্য একটি ব্যয়বহুল অপারেশন হতে পারে।
মাইকেল Stum

হুবহু মাইকেল স্টাম যা বলেছিলেন। যখন এই আচরণটি সংজ্ঞায়িত করা হয়েছিল, তখন একক অনুবাদ ইউনিটের মাধ্যমে একটি লিনিয়ার স্ক্যানই কেবল ব্যবহারিকভাবে প্রয়োগ করা যেতে পারে।
জলফ

3
হ্যাঁ - টেপ ভর টোরেজ সহ 16 টি তেতো সংকেত সংকলনহীন।
এমএসএলটার 14

11

প্রথম সুবিধা: আপনার যদি শিরোনাম ফাইল না থাকে তবে আপনাকে উত্স ফাইলগুলি অন্য উত্স ফাইলগুলিতে অন্তর্ভুক্ত করতে হবে। এটি অন্তর্ভুক্ত ফাইল পরিবর্তিত হলে ফাইলগুলি সহ আবার সংকলিত হতে পারে।

দ্বিতীয় সুবিধা: এটি বিভিন্ন ইউনিট (বিভিন্ন বিকাশকারী, দল, সংস্থা ইত্যাদি) এর মধ্যে কোডটি ভাগ না করে ইন্টারফেসগুলি ভাগ করার অনুমতি দেয়)


1
আপনি কি তা বোঝাচ্ছেন, যেমন সি # 'তে আপনাকে অন্যান্য উত্স ফাইলে উত্স ফাইল অন্তর্ভুক্ত করতে হবে'? কারণ আপনি অবশ্যই না। দ্বিতীয় সুবিধার জন্য, আমি মনে করি এটি খুব ভাষা নির্ভর করে: আপনি
ড। ডিল্ফি

আপনাকে যেভাবেই হোক পুরো প্রকল্পটি পুনরায় কম্পাইল করতে হবে, তাই প্রথম সুবিধাটি কি সত্যিই গণনা করবে?
মারিয়াস

ঠিক আছে, তবে আমি মনে করি না যে এটি কোনও ভাষা বৈশিষ্ট্য। সংজ্ঞা "সমস্যা" এর আগে সি ঘোষণার সাথে মোকাবেলা করা আরও ব্যবহারিক কিছু। এটা তোলে মত কেউ বিখ্যাত উক্তি :) "যে একটি বাগ একটি বৈশিষ্ট্য যে না" হয়
স্নায়ু

@ মারিয়াস: হ্যাঁ, এটি সত্যিই গণনা করা। পুরো প্রকল্পটির সংযোগ করা এবং পুরো প্রকল্পটি সংযোগ স্থাপনের সাথে আলাদা from প্রকল্পের # টি ফাইলের আকার বাড়ার সাথে সাথে সমস্তগুলি সংকলন করে সত্যই বিরক্তিকর হয়। @ স্প্রেড: আপনি ঠিক বলেছেন, তবে আমি সি ++ অন্য ভাষার সাথে তুলনা করিনি। আমি উত্স এবং শিরোনাম ফাইলগুলি ব্যবহার করে কেবল উত্স ফাইলগুলি তুলনা করেছি।
erelender

সি # অন্যের মধ্যে উত্স ফাইলগুলি অন্তর্ভুক্ত করে না, তবে আপনাকে এখনও মডিউলগুলি উল্লেখ করতে হবে - এবং এটি আপনার কোডটি যে চিহ্নগুলি ব্যবহার করে তার চিহ্নগুলি বিশ্লেষণ করতে সংকলকটি উত্স ফাইলগুলি (বা বাইনারিগুলিতে প্রতিবিম্বিত করে) তোলে makes
gbjbaanb

5

সংকলকটি অন্যান্য মডিউলগুলির মধ্যে ফাংশন এবং ভেরিয়েবলের জন্য টাইপ তথ্য সম্পর্কে জানার জন্য কম্পাইলারের যে সীমাবদ্ধতাগুলি রয়েছে তার ফলস্বরূপ শিরোনাম ফাইলগুলির প্রয়োজনীয়তার ফলাফল। সংকলিত প্রোগ্রাম বা লাইব্রেরিতে অন্যান্য সংকলন ইউনিটগুলিতে সংজ্ঞায়িত কোনও অবজেক্টকে আবদ্ধ করতে সংকলকটির প্রয়োজনীয় প্রকারের তথ্য অন্তর্ভুক্ত নয়।

এই সীমাবদ্ধতার জন্য ক্ষতিপূরণ দেওয়ার জন্য, সি এবং সি ++ ঘোষণার অনুমতি দেয় এবং এই ঘোষণাগুলিগুলিকে মডিউলগুলিতে অন্তর্ভুক্ত করা যেতে পারে যা প্রিপ্রসেসসরের # অন্তর্ভুক্ত নির্দেশিকার সাহায্যে এগুলি ব্যবহার করে।

অন্যদিকে জাভা বা সি # এর মতো ভাষাতে কম্পাইলারের আউটপুট (শ্রেণি-ফাইল বা সমাবেশ) বাঁধাইয়ের জন্য প্রয়োজনীয় তথ্য অন্তর্ভুক্ত। অতএব, মডিউলের ক্লায়েন্টদের অন্তর্ভুক্ত করার জন্য স্বতন্ত্র ঘোষণাগুলি বজায় রাখার আর দরকার নেই।

বাইন্ডিং তথ্য সংকলক আউটপুটে অন্তর্ভুক্ত না করার কারণটি সহজ: রানটাইমের সময় এটি প্রয়োজন হয় না (সংকলনের সময় কোনও প্রকারের চেকিং ঘটে)। এটা ঠিক জায়গা নষ্ট করবে। মনে রাখবেন যে সি / সি ++ এমন সময় থেকে এসেছে যেখানে এক্সিকিউটেবল বা লাইব্রেরির আকারটি কিছুটা গুরুত্বপূর্ণ হয়ে যায়।


আমি আপনার সাথে একমত. : আমি এখানে অনুরূপ ধারণা পেয়েছিলাম stackoverflow.com/questions/3702132/...
smwikipedia

4

সি ++ এর জন্য সি এর পরিকাঠামোতে আধুনিক প্রোগ্রামিং ভাষার বৈশিষ্ট্যগুলি যুক্ত করার জন্য ডিজাইন করা হয়েছিল, অকারণে সি সম্পর্কে এমন কোনও কিছু পরিবর্তন না করে যা ভাষা সম্পর্কে বিশেষত ছিল না।

হ্যাঁ, এই মুহুর্তে (প্রথম সি ++ স্ট্যান্ডার্ডের 10 বছর পরে এবং এটির গুরুত্ব সহকারে ব্যবহার শুরু হয়েছে 20 বছর পরে) কেন এটির সঠিক মডিউল সিস্টেম নেই তা জিজ্ঞাসা করা সহজ। স্পষ্টতই আজ ডিজাইন করা কোনও নতুন ভাষা সি ++ এর মতো কাজ করবে না। তবে এটি সি ++ এর বিন্দু নয়।

সি ++ এর বিষয়টি হ'ল বিবর্তনীয়, বিদ্যমান অনুশীলনের একটি মসৃণ ধারাবাহিকতা, কেবলমাত্র তার ব্যবহারকারী সম্প্রদায়ের জন্য পর্যাপ্তরূপে কাজ করে এমন জিনিসগুলি (খুব বেশি) ভাঙা ছাড়াই নতুন ক্ষমতা যুক্ত করা।

এর অর্থ হল যে এটি কিছু জিনিসকে আরও শক্ত করে তোলে (বিশেষত লোকেদের জন্য একটি নতুন প্রকল্প শুরু করা) এবং কিছু জিনিস অন্যান্য ভাষাগুলির চেয়ে কিছু সহজ করে (বিশেষত বিদ্যমান কোড বজায় রাখার জন্য)।

সুতরাং C ++ সি # তে রূপান্তরিত হওয়ার প্রত্যাশার চেয়ে (যা আমাদের কাছে ইতিমধ্যে সি # রয়েছে অর্থহীন হবে), কেন কেবল কাজের জন্য সঠিক সরঞ্জামটি বেছে নিচ্ছেন না? নিজেই, আমি একটি আধুনিক ভাষায় নতুন কার্যকারিতার উল্লেখযোগ্য অংশগুলি লেখার চেষ্টা করি (আমি সি # ব্যবহার করতেই চাই), এবং আমার প্রচুর পরিমাণে বিদ্যমান সি ++ রয়েছে যা আমি সি ++ এ রাখছি কারণ এটি পুনরায় লেখার কোনও সত্যিকারের মূল্য থাকবে না সব। তারা যাইহোক যাইহোক খুব সুন্দরভাবে সংহত করে, তাই এটি মূলত ব্যথাহীন।


আপনি কীভাবে সি # এবং সি ++ একীভূত করবেন? সিওএমের মাধ্যমে?
পিটার মর্টেনসেন

1
তিনটি প্রধান উপায় আছে, "সেরা" আপনার বিদ্যমান কোডের উপর নির্ভর করে। আমি তিনটি ব্যবহার করেছি। আমি যেটি সবচেয়ে বেশি ব্যবহার করি তা হ'ল সিওএম কারণ আমার বিদ্যমান কোডটি এর চারপাশে ইতিমধ্যে তৈরি করা হয়েছিল, সুতরাং এটি কার্যত বিরামবিহীন, আমার পক্ষে খুব ভাল কাজ করে। কিছু অদ্ভুত জায়গায় আমি সি ++ / সিএলআই ব্যবহার করি যা আপনার ইতিমধ্যে সিওএম ইন্টারফেস নেই এমন কোনও পরিস্থিতির জন্য অবিশ্বাস্যভাবে মসৃণ সংহতকরণ দেয় (এবং আপনি এটি বিদ্যমান সিওএম ইন্টারফেসগুলি ব্যবহার করার ক্ষেত্রে পছন্দ করতে পারেন)। অবশেষে পি / ইনভেক রয়েছে যা মূলত আপনাকে কোনও ডিএলএল থেকে উদ্ভূত যে কোনও সি-জাতীয় ফাংশনটি কল করতে দেয়, তাই আপনাকে সরাসরি সি # থেকে কোনও উইন 32 এপিআই কল করতে দেয়।
ড্যানিয়েল আর্উইকার 15

4

ঠিক আছে, সি ++ 1998 সালে অনুমোদিত হয়েছিল, তবে এটি এর চেয়ে অনেক বেশি সময় ধরে ব্যবহৃত হয়েছিল এবং অনুমোদনটি মূলত কাঠামো চাপিয়ে দেওয়ার পরিবর্তে বর্তমান ব্যবহার স্থির করে চলেছিল। এবং যেহেতু সি ++ সি ভিত্তিক ছিল এবং সি এর শিরোনাম ফাইল রয়েছে তাই সি ++ এগুলিও রয়েছে।

হেডার ফাইলগুলির প্রধান কারণ হ'ল ফাইলগুলির পৃথক সংকলন সক্ষম করা এবং নির্ভরতা হ্রাস করা।

বলুন যে আমার কাছে foo.cpp রয়েছে এবং আমি বারডা / বারকপিপি ফাইলগুলি থেকে কোডটি ব্যবহার করতে চাই।

আমি foo.cpp এ "বার। H" অন্তর্ভুক্ত করতে পারি, এবং তারপরে প্রোগ্রাম এবং foo.cpp সংকলন করতে পারলেও বার.cpp উপস্থিত না থাকলেও। শিরোনাম ফাইলটি কম্পাইলারের প্রতিশ্রুতি হিসাবে কাজ করে যে বার। H এর ক্লাসগুলি / ফাংশনগুলি রান-টাইমে উপস্থিত থাকবে এবং এর এটি ইতিমধ্যে জেনে রাখা সমস্ত কিছু রয়েছে।

অবশ্যই, যদি আমি যখন আমার প্রোগ্রামটি লিঙ্ক করার চেষ্টা করি তখন বার। H এর ফাংশনগুলির যদি মৃতদেহ না থাকে তবে এটি লিঙ্ক করবে না এবং আমি একটি ত্রুটি পেয়ে যাব।

একটি পার্শ্ব প্রতিক্রিয়া হ'ল আপনি আপনার উত্স কোডটি প্রকাশ না করেই ব্যবহারকারীদের একটি শিরোনাম ফাইল দিতে পারেন।

অন্যটি হ'ল যদি আপনি আপনার কোডটি * .cpp ফাইলে প্রয়োগ করেন তবে শিরোনামটি একেবারে পরিবর্তন না করেন তবে আপনার কেবলমাত্র * .cpp ফাইলটি ব্যবহার করে এমন সমস্ত কিছুর পরিবর্তে সংকলন করতে হবে। অবশ্যই, আপনি যদি শিরোলেখ ফাইলটিতে অনেকগুলি প্রয়োগ করেন তবে এটি কম কার্যকর হয়।


3

মূল হিসাবে একই ফাংশনগুলির সাথে এটির জন্য পৃথক শিরোনাম ফাইলের প্রয়োজন নেই। এটি কেবল তখনই প্রয়োজন যখন আপনি একাধিক কোড ফাইল ব্যবহার করে কোনও অ্যাপ্লিকেশন বিকাশ করেন এবং যদি আপনি এমন কোনও ফাংশন ব্যবহার করেন যা আগে ঘোষিত হয়নি।

এটি সত্যিই একটি সুযোগ সমস্যা।


1

সি ++ 1998 সালে অনুমোদিত হয়েছিল, সুতরাং কেন এটি এভাবে ডিজাইন করা হয়েছে? একটি পৃথক শিরোনাম ফাইল থাকার কি কি সুবিধা আছে?

প্রথমবারের জন্য প্রোগ্রামগুলি পরীক্ষা করার সময়, শিরোনামের ফাইলগুলি খুব দরকারী হয়ে ওঠে, শিরোনামের ফাইলগুলি পরীক্ষা করা (কেবলমাত্র একটি পাঠ্য সম্পাদক ব্যবহার করে) আপনাকে অন্যান্য ভাষাগুলির তুলনায়, যেখানে ক্লাস দেখার জন্য অত্যাধুনিক সরঞ্জামগুলি ব্যবহার করতে হবে এবং অন্যান্য ভাষাগুলির তুলনায় আপনাকে প্রোগ্রামটির আর্কিটেকচারের ওভারভিউ দেয় and তাদের সদস্য কাজ।


1

আমি মনে করি বাস্তব (ঐতিহাসিক) হেডার ফাইল পিছনে কারণ কম্পাইলার ডেভেলপারদের জন্য সহজ মত উপার্জন হয় ... কিন্তু তারপর, হেডার ফাইল না সুবিধা প্রদান করে।
পরীক্ষা করে দেখুন এই আগের পোস্ট আরো আলোচনার জন্য ...


1

ভাল, আপনি শিরোনাম ফাইল ছাড়াই সি ++ পুরোপুরি বিকাশ করতে পারেন। আসলে কিছু লাইব্রেরি যা নিবিড়ভাবে টেমপ্লেট ব্যবহার করে শিরোনাম / কোড ফাইলের দৃষ্টান্ত ব্যবহার করে না (বুস্ট দেখুন)। তবে সি / সি ++ এ আপনি এমন কিছু ব্যবহার করতে পারবেন না যা ঘোষিত হয়নি। এর সাথে মোকাবিলা করার একটি ব্যবহারিক উপায় হ'ল হেডার ফাইলগুলি ব্যবহার করা। এছাড়াও, আপনি ভাগ করে নেওয়ার কোড / প্রয়োগের বাইরে ইন্টারফেস ভাগ করে নেওয়ার সুবিধা অর্জন করতে পারেন। এবং আমি মনে করি এটি সি স্রষ্টাদের দ্বারা কল্পনা করা হয়নি: আপনি যখন ভাগ করা শিরোনাম ফাইল ব্যবহার করেন তখন আপনাকে বিখ্যাতটি ব্যবহার করতে হবে:

#ifndef MY_HEADER_SWEET_GUARDIAN
#define MY_HEADER_SWEET_GUARDIAN

// [...]
// my header
// [...]

#endif // MY_HEADER_SWEET_GUARDIAN

এটি আসলে কোনও ভাষা বৈশিষ্ট্য নয় বরং একাধিক অন্তর্ভুক্তির মোকাবেলার একটি ব্যবহারিক উপায়।

সুতরাং, আমি মনে করি যখন সি তৈরি হয়েছিল, তখন ফরওয়ার্ড ডিক্লেয়ারেশনের সাথে সমস্যাগুলি হ্রাস করা হয়নি এবং এখন সি ++ এর মতো উচ্চ স্তরের ভাষা ব্যবহার করার সময় আমাদের এই ধরণের জিনিসগুলি মোকাবেলা করতে হবে।

আমাদের দরিদ্র সি ++ ব্যবহারকারীদের জন্য আর একটি বোঝা ...


1

আপনি যদি সংকলকটি অন্য ফাইলগুলিতে স্বয়ংক্রিয়ভাবে সংজ্ঞায়িত চিহ্নগুলি সন্ধান করতে চান তবে আপনাকে প্রোগ্রামারকে সেই ফাইলগুলি পূর্বনির্ধারিত স্থানে রাখতে বাধ্য করতে হবে (যেমন জাভা প্যাকেজ কাঠামো প্রকল্পের ফোল্ডার কাঠামো নির্ধারণ করে)। আমি হেডার ফাইলগুলি পছন্দ করি। এছাড়াও আপনি যে লাইব্রেরি ব্যবহার করেন সেগুলির উত্স বা বাইনারিগুলিতে সংকলক দ্বারা প্রয়োজনীয় তথ্য রাখার জন্য কিছু অভিন্ন পদ্ধতি প্রয়োজন।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.