সি / সি ++ এর মধ্যে শিরোনাম ফাইল অর্ডার অন্তর্ভুক্ত রয়েছে


287

কোন অর্ডারগুলিতে ফাইলগুলি অন্তর্ভুক্ত করা উচিত, অর্থাত্‍ একের আগে অন্য শিরোনাম যুক্ত করার কারণগুলি কী?

উদাহরণস্বরূপ, স্থানীয় ফাইলগুলি অন্তর্ভুক্ত করার আগে বা পরে সিস্টেম ফাইলগুলি, এসটিএল এবং বুস্ট যায়?


2
এবং নীচের উত্তরগুলির আধিক্য হ'ল কেন জাভা বিকাশকারীরা পৃথক শিরোনামের বিরুদ্ধে সিদ্ধান্ত নিয়েছিলেন। :-) কিছু সত্যই ভাল উত্তর, বিশেষত আপনার নিজের হেডার ফাইলগুলি একা দাঁড়িয়ে থাকতে পারে তা নিশ্চিত করার পরামর্শ particularly
ক্রিস কে

37
আমার কাছে এটি পছন্দ হয়েছে যে প্রশ্নগুলি যেগুলি 100+ ভোট রয়েছে এবং বেশ কিছু লোকের জন্য "গঠনমূলক নয়" হিসাবে বন্ধ হয়ে যায় তা অবাকভাবে আকর্ষণীয়।
আন্দ্রেয়াস

একটি অত্যন্ত বাঞ্ছনীয় পড়ুন: cplusplus.com/forum/articles/10627
Kalsan

3
@ মিঃআরটি, এসও দৃ strongly়ভাবে স্যুপ নাজি সম্প্রদায়কে স্মরণ করিয়ে দেয়: হয় আপনি কয়েকটি কঠোর নিয়ম অনুসরণ করেন, বা "আপনার পক্ষে সঠিক উত্তর / মন্তব্য নেই!"। তবুও, যদি কারও কারও সাথে প্রোগ্রামিং সম্পর্কিত কোনও সমস্যা থাকে তবে এটি (সাধারণত) প্রথম সাইট হয় ..
ইমাগো

উত্তর:


289

আমি মনে করি না যে এটি প্রস্তাবিত আদেশ রয়েছে যতক্ষণ না এটি সংকলন করে! বিরক্তিকর হ'ল যখন কিছু শিরোনামকে প্রথমে অন্য শিরোনাম অন্তর্ভুক্ত করা প্রয়োজন ... এটি শিরোনামের সাথে নয়, শিরোনামগুলির নিজেরাই এটি একটি সমস্যা।

আমার ব্যক্তিগত পছন্দটি হ'ল স্থানীয় থেকে গ্লোবাল, প্রতিটি বর্ণনানুক্রমিক ক্রমে, অর্থাৎ:

  1. এই সিপিপি ফাইলের সাথে সম্পর্কিত এইচ ফাইল (প্রযোজ্য ক্ষেত্রে)
  2. একই উপাদান থেকে শিরোনাম,
  3. অন্যান্য উপাদানগুলির শিরোনাম,
  4. সিস্টেম শিরোনাম

আমার ১. এর যুক্তিটি হ'ল এটি প্রমাণ করা উচিত যে প্রতিটি শিরোনাম (যার জন্য সিপিপি রয়েছে) #includeপূর্বশর্ত ছাড়াই ডি হতে পারে (টার্মিনাস টেকনিকাস: শিরোনামটি "স্ব-অন্তর্ভুক্ত")। এবং বাকিগুলি কেবল সেখান থেকে যৌক্তিকভাবে প্রবাহিত বলে মনে হচ্ছে।


16
আপনারা অনেকটা একইরকম, আমি বিশ্বব্যাপী স্থানীয় থেকে নীচে না গিয়ে উত্স ফাইলের সাথে সম্পর্কিত শিরোনামটি বিশেষ চিকিত্সা গ্রহণ করে না।
জন পুরে

127
@ জন: আমি বলব যে এটি বেশ বিপরীত! :-) আমি যুক্তি দিয়ে বলব যে আপনার পদ্ধতিটি লুকানো নির্ভরশীলতাগুলি প্রবর্তন করতে পারে, যদি বলে যে myclass.cpp <string> এর পরে <myclass.h> অন্তর্ভুক্ত থাকে, মাইক্র্লাস এইচ স্ট্রিংয়ের উপর নির্ভর করে যে বিল্ড টাইম ধরার উপায় নেই; সুতরাং পরে যদি আপনি বা অন্য কারও সাথে মাইক্লাস এইচ অন্তর্ভুক্ত থাকে তবে স্ট্রিংয়ের দরকার নেই, আপনি সিআরপি বা শিরোনামে নিজেই ঠিক করতে হবে এমন একটি ত্রুটি পাবেন। তবে আমি জানতে আগ্রহী যে এটি কি দীর্ঘমেয়াদে আরও ভাল কাজ করবে বলে লোকেরা মনে করে ... আপনি কেন আপনার প্রস্তাবনা দিয়ে উত্তর পোস্ট করবেন না এবং আমরা দেখতে পাব কে "জিতবে"? ;-)
স্কুয়ার্ট

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

7
@ পলজ্যানসেন এটি একটি খারাপ অভ্যাস এবং এমন একটি কৌশল ব্যবহার করা ভাল যা এটির সাথে প্রস্ফুটিত হওয়ার সম্ভাবনা থাকে যাতে লুকিয়ে রাখার পরিবর্তে খারাপ অভ্যাসটি সংশোধন করা যায়। স্থানীয় গ্লোবাল
এফটিডব্লিউ

10
@ পলজ্যানসেন হ্যাঁ, আমি মানক আচরণকে ওভাররুলিংয়ের কথা উল্লেখ করছিলাম। এটি যেমন দুর্ঘটনা দ্বারা ঘটতে পারে যেমন উদাহরণস্বরূপ, ওডিআর ভাঙা দুর্ঘটনা দ্বারা ঘটতে পারে। সমাধান হ'ল এই জাতীয় দুর্ঘটনা ঘটে যখন লুকানো অনুশীলনগুলি ব্যবহার না করা, তবে সম্ভবত এমন অভ্যাসগুলি ব্যবহার করা যা সম্ভবত তাদের যতটা সম্ভব উচ্চস্বরে উড়িয়ে দেওয়া যায়, যাতে ভুলগুলি লক্ষ্য করা যায় এবং যত তাড়াতাড়ি সম্ভব স্থির করা যায়।
bames53

105

মনে রাখা বড় বিষয় হ'ল আপনার শিরোনামগুলি অন্যান্য শিরোনামগুলি প্রথমে অন্তর্ভুক্ত করার উপর নির্ভর করে না। এটির বীমা করার একটি উপায় হ'ল অন্য শিরোনামের আগে আপনার শিরোনামকে অন্তর্ভুক্ত করা।

"C ++" তে বিশেষভাবে চিন্তা করে এটি উল্লেখ করেছে, Lakos এর "বৃহত্তর স্কেল সি ++ সফ্টওয়্যার ডিজাইন" উল্লেখ করে:

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

এটি বলতে গেলে, নিম্নলিখিত ক্রমে অন্তর্ভুক্ত করুন:

  1. এই প্রয়োগের জন্য প্রোটোটাইপ / ইন্টারফেস শিরোনাম (যেমন, .h / .hh ফাইল যা এই .cpp / .cc ফাইলের সাথে সম্পর্কিত)।
  2. প্রয়োজন হিসাবে একই প্রকল্পের অন্যান্য শিরোনাম।
  3. অন্যান্য অ-মানক, নন-সিস্টেম লাইব্রেরি থেকে শিরোনাম (উদাহরণস্বরূপ, কিউটি, ইগেন, ইত্যাদি)।
  4. অন্যান্য "প্রায়-মানক" লাইব্রেরি থেকে শিরোনাম (উদাহরণস্বরূপ, বুস্ট)
  5. স্ট্যান্ডার্ড সি ++ শিরোনাম (উদাহরণস্বরূপ, আইস্ট্রিম, ফাংশনাল ইত্যাদি)
  6. স্ট্যান্ডার্ড সি শিরোনাম (উদাহরণস্বরূপ, সিএসটিডিন্ট, ডাইরেন্ট এইচ। ইত্যাদি)

এই শৃঙ্খলে অন্তর্ভুক্ত হওয়ার সাথে যদি কোনও শিরোনামের সমস্যা থাকে, তবে তাদের সমাধান করুন (যদি আপনার হয়) বা সেগুলি ব্যবহার করবেন না। ক্লিনার শিরোনাম লেখেন না এমন লাইব্রেরি বয়কট করুন।

গুগলের সি ++ স্টাইল গাইডটি প্রায় বিপরীত যুক্তি দেখায়, সত্যিকার অর্থে কোনও ন্যায়সঙ্গতি নেই; আমি ব্যক্তিগতভাবে লাকোসের পদ্ধতির পক্ষে থাকি।


13
এখন পর্যন্ত, গুগল সি ++ স্টাইল গাইড লাকোসের পরামর্শ অনুসরণ করে প্রথমে সম্পর্কিত শিরোনাম ফাইলটি অন্তর্ভুক্ত করার পরামর্শ দেয়।
ফিলিপ বার্তেক

আপনি প্রথম সম্পর্কিত শিরোনামের চেয়ে বেশি কিছু পাবেন না কারণ একবার আপনি আপনার ইন-প্রজেক্ট শিরোনামকে অন্তর্ভুক্ত শুরু করলে আপনি প্রচুর সিস্টেমের নির্ভরতা টানতে যাচ্ছেন।
মীখা

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

49

আমি দুটি সহজ নিয়ম অনুসরণ করি যা বিপুল সংখ্যক সমস্যা এড়ায়:

  1. সমস্ত শিরোনাম (এবং প্রকৃতপক্ষে কোনও উত্স ফাইল) তাদের যা প্রয়োজন তা অন্তর্ভুক্ত করা উচিত। তাদের জিনিস সহ তাদের ব্যবহারকারীর উপর নির্ভর করা উচিত নয়
  2. সংযোজন হিসাবে, সমস্ত শিরোনামে রক্ষীদের অন্তর্ভুক্ত থাকা উচিত যাতে তারা উপরোক্ত নিয়ম 1-এর অতিরিক্ত-উচ্চাভিলাষী প্রয়োগের মাধ্যমে একাধিকবার অন্তর্ভুক্ত না হয়।

আমি এর গাইডলাইনগুলিও অনুসরণ করি:

  1. বিভাজক রেখার সাথে প্রথমে সিস্টেমের শিরোনাম (stdio.h, ইত্যাদি) অন্তর্ভুক্ত করুন।
  2. তাদের যৌক্তিকভাবে গ্রুপ করুন।

অন্য কথায়:

#include <stdio.h>
#include <string.h>

#include "btree.h"
#include "collect_hash.h"
#include "collect_arraylist.h"
#include "globals.h"

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


6
+1 "সমস্ত শিরোনাম (এবং প্রকৃতপক্ষে কোনও উত্স ফাইলগুলি) তাদের যা প্রয়োজন তা অন্তর্ভুক্ত করা উচিত They জিনিসগুলি সহ তাদের ব্যবহারকারীর উপর নির্ভর করা উচিত নয়" " তবুও অনেক লোক এই অন্তর্নিহিত অন্তর্ভুক্তি আচরণের উপর নির্ভর করে, উদাহরণস্বরূপ, NULL এর সাথে এবং <cstddef> অন্তর্ভুক্ত করে না। এই কোডটি পোর্ট করার চেষ্টা করার সময় এবং NULL তে সংকলন ত্রুটিগুলি পেয়ে যাওয়ার কারণে এটি খুব বিরক্তিকর (একটি কারণ আমি কেবল এখন 0 ব্যবহার করি)।
stinky472

20
আপনি প্রথমে সিস্টেম শিরোনাম কেন অন্তর্ভুক্ত করবেন? আপনার প্রথম নিয়মের কারণে কেন অন্যদিকে এটি আরও ভাল।
ঝাসে

আপনি যদি ফিচার টেস্ট ম্যাক্রো ব্যবহার করেন তবে আপনার প্রথমটি অন্তর্ভুক্ত সম্ভবত কোনও আদর্শ লাইব্রেরির শিরোনাম হওয়া উচিত নয়। অতএব, সাধারণতার জন্য, আমি বলব "স্থানীয় প্রথমে, পরে বিশ্বব্যাপী" নীতিটি সর্বোত্তম।
হামিজাইল 30:38

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

22

দেয়ালে আমার নিজের ইট যুক্ত করতে।

  1. প্রতিটি শিরোনামকে স্বাবলম্বী হওয়া দরকার, যা কেবলমাত্র প্রথমে অন্তত একবার অন্তর্ভুক্ত করা হলে তা পরীক্ষা করা যেতে পারে
  2. প্রতীকগুলি (ম্যাক্রো, প্রকার, ইত্যাদি) প্রবর্তন করে ত্রুটিযুক্ত কোনও শিরোনামটির অর্থ ভুল করে পরিবর্তন করা উচিত নয়

সুতরাং আমি সাধারণত এটি যেতে:

// myproject/src/example.cpp
#include "myproject/example.h"

#include <algorithm>
#include <set>
#include <vector>

#include <3rdparty/foo.h>
#include <3rdparty/bar.h>

#include "myproject/another.h"
#include "myproject/specific/bla.h"

#include "detail/impl.h"

প্রতিটি গ্রুপ পরের থেকে একটি ফাঁকা রেখার দ্বারা পৃথক:

  • প্রথমে এই সিপিপি ফাইলের সাথে সম্পর্কিত শিরোনাম (স্যানিটি পরীক্ষা)
  • সিস্টেম শিরোনাম
  • তৃতীয় পক্ষের শিরোনামগুলি নির্ভরতা আদেশ দ্বারা সংগঠিত
  • প্রকল্পের শিরোনাম
  • প্রকল্পের ব্যক্তিগত শিরোনাম

এছাড়াও মনে রাখবেন যে, সিস্টেম শিরোলেখগুলি বাদে প্রতিটি ফাইলের নাম স্থানের নাম সহ একটি ফোল্ডারে থাকে, কেবল এ কারণে তাদের এগুলি ট্র্যাক করা সহজ।


2
যাতে অন্যান্য হেডার ফাইলগুলি সেগুলি দ্বারা প্রভাবিত না হয়। এই সিস্টেমের শিরোলেখগুলি যা সংজ্ঞায়িত করে (উভয় এক্স অন্তর্ভুক্ত করে এবং উইন্ডোজ উভয়ই #defineঅন্য কোডের সাথে জড়িত তা সম্পর্কে খারাপ ) এবং অন্তর্নিহিত নির্ভরতা রোধ করার জন্য উভয়ই । উদাহরণস্বরূপ, যদি আমাদের কোড বেস শিরোনাম ফাইলটি foo.hসত্যই নির্ভর করে <map>তবে যে কোনও জায়গায় এটি .ccফাইলগুলিতে ব্যবহৃত <map>হয়েছিল, ইতিমধ্যে অন্তর্ভুক্ত হওয়ার ঘটনা ঘটেছে, আমরা সম্ভবত লক্ষ্য করব না। যতক্ষণ না কেউ foo.hপ্রথমটি অন্তর্ভুক্ত না করে অন্তর্ভুক্ত করার চেষ্টা করেছিল <map>। এবং তারপরে তারা বিরক্ত হবেন।

@ 0 এ0 ডি: দ্বিতীয় ক্রমটি এখানে ক্রমটিতে সমস্যা নয়, কারণ প্রত্যেকটির .hকমপক্ষে একটি .cppরয়েছে যার মধ্যে এটি প্রথমে অন্তর্ভুক্ত রয়েছে (প্রকৃতপক্ষে, আমার ব্যক্তিগত কোডে ইউনিট পরীক্ষার সাথে সম্পর্কিত এটি প্রথমে অন্তর্ভুক্ত রয়েছে, এবং উত্স কোডটি তার অধিকারী গ্রুপে অন্তর্ভুক্ত রয়েছে) )। প্রভাবিত না হওয়ার বিষয়ে, যদি কোনও শিরোলেখ অন্তর্ভুক্ত করে <map>তবে এর পরে অন্তর্ভুক্ত সমস্ত শিরোনাম যেভাবেই প্রভাবিত হয়, সুতরাং এটি আমার কাছে হেরে যাওয়া যুদ্ধ বলে মনে হয়।
ম্যাথিউ মিঃ

1
অবশ্যই, তাই আমি নিয়মিত ঘুরতে যাই এবং পুরানো কোড (বা আরও নতুন কোড) সংশোধন করি যার জন্য একটি অপ্রয়োজনীয় অন্তর্ভুক্ত থাকে কারণ এটি কেবল বিল্ড টাইম আপ চালায়।

@MatthieuM। আমি আপনার পয়েন্ট এক পিছনে যুক্তি জানতে চাই Header corresponding to this cpp file first (sanity check)#include "myproject/example.h"সমস্ত অন্তর্ভুক্ত শেষে সরানো হয় সেখানে বিশেষ কিছু আছে ?
এমএনএস 23'16

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

16

আমি সুপারিশ:

  1. আপনি তৈরি করছেন এমন সিসি মডিউলটির শিরোনাম। (আপনার প্রকল্পের প্রতিটি শিরোনামের আপনার প্রকল্পের অন্যান্য শিরোনামের উপর অন্তর্নিহিত নির্ভরতা নেই তা নিশ্চিত করতে সহায়তা করে))
  2. সি সিস্টেম ফাইল।
  3. সি ++ সিস্টেম ফাইল।
  4. প্ল্যাটফর্ম / ওএস / অন্যান্য শিরোনাম ফাইল (যেমন উইন 32, জিটিকে, ওপেনজিএল)।
  5. আপনার প্রকল্পের অন্যান্য শিরোনাম ফাইল।

এবং অবশ্যই, প্রতিটি বিভাগের মধ্যে বর্ণানুক্রমিক ক্রম, যেখানে সম্ভব।

#includeআপনার হেডার ফাইলগুলিতে অপ্রয়োজনীয় গুলি এড়াতে সর্বদা ফরওয়ার্ড ডিক্লেয়ারেশন ব্যবহার করুন ।


+1, তবে বর্ণমালা কেন? এমন কিছু মনে হয় যা আপনাকে আরও ভাল বোধ করতে পারে তবে এর কোনও ব্যবহারিক সুবিধা নেই।
বেন

9
বর্ণানুক্রমিক একটি স্বেচ্ছাসেবী ক্রম, তবে একটি সহজ। আপনার বর্ণমালা করতে হবে না, তবে আপনাকে কিছু ক্রম বাছাই করতে হবে যাতে প্রত্যেকে এটি ধারাবাহিকভাবে করে। আমি খুঁজে পেয়েছি এটি সদৃশগুলি এড়াতে সহায়তা করে এবং সংযুক্তিগুলি আরও সহজ করে তোলে। এবং যদি আপনি মহৎ পাঠ্য ব্যবহার করেন তবে এফ 5 আপনার জন্য সেগুলি অর্ডার করবে।
আই_আম_জোরফ

14

আমি দৃ sure়ভাবে নিশ্চিত যে এটি সান ওয়ার্ল্ডের কোথাও প্রস্তাবিত অনুশীলন নয়, তবে আমি চাই যে লাইন পদ্ধতিতে ফাইলের নাম দৈর্ঘ্য অন্তর্ভুক্ত থাকে, একই দৈর্ঘ্যের মধ্যে বর্ণসূচকভাবে সাজানো হয়। তাই ভালো:

#include <set>
#include <vector>
#include <algorithm>
#include <functional>

অন্তর্ভুক্তি-আদেশ নির্ভরতার লজ্জা এড়াতে আপনার নিজের শিরোনামগুলি অন্য লোকের আগে অন্তর্ভুক্ত করা ভাল ধারণা।


3
আমি আমার শিরোনামগুলিকে দ্বিতীয়, তৃতীয় এবং পরে প্রথম অক্ষরের সমন্বিত কী ব্যবহার করে বাছাই করতে চাই :-) সুতরাং আপনার উদাহরণের জন্য ভেক্টর, সেট, অ্যালগরিদম, কার্যকরী।
paxdiablo

@ প্যাক্সিয়াব্লো, টিপটির জন্য ধন্যবাদ। আমি এটি ব্যবহার করার বিষয়ে বিবেচনা করছি, তবে আমি উদ্বিগ্ন যে এটি ফাইলের নামগুলির স্তূপটি অস্থিতিশীল রেখে সম্ভবত শেষ হতে পারে। কেহ জানে যদি এটি ঘটে তবে কী অন্তর্ভুক্ত থাকতে পারে - এমনকি এমনকি windows.h
clstrfsck

40
অনুসারে সাজানো দৈর্ঘ্য ? বাতুলতা!
জেমস ম্যাকনেলিস

1
প্রথমটির জন্য +1। এটি আসলে বোধগম্য হয়, যদি আপনার চোখের সাহায্যে কোনও ফাইলের মধ্যে শিরোনাম শনাক্ত করতে হয় তবে এটি বর্ণানুক্রমিক চেয়ে অনেক ভাল।
কুগেল

6

এটি বিষয়গত নয়। নিশ্চিত করুন যে আপনার শিরোনামগুলি #includeনির্দিষ্ট ক্রমে ডি হওয়ার উপর নির্ভর করে না । আপনি নিশ্চিত হতে পারেন যে আপনি এসটিএল বা বুস্ট শিরোনাম অন্তর্ভুক্ত করবেন না কেন তা বিবেচনা করে না।


1
আমি কোনও অন্তর্নিহিত নির্ভরতা ধরে
নিচ্ছিলাম

হ্যাঁ, তবে সংকলক এই অনুমানটি তৈরি করতে পারে না, সুতরাং # অন্তর্ভুক্ত <এ>, <বি> সংকলন না হওয়া পর্যন্ত # অন্তর্ভুক্ত <বি>, <এ> এর মতো কখনও হয় না।
মিখাইল

4

প্রথমে .cpp এর সাথে সম্পর্কিত শিরোনাম অন্তর্ভুক্ত করুন ... অন্য কথায়, অন্য কিছু যুক্ত করার আগে source1.cppঅন্তর্ভুক্ত করা উচিত source1.h। কেবলমাত্র ব্যতিক্রমটি আমি ভাবতে পারি যে যখন এমএসভিসি ব্যবহার করে প্রাক-সংকলিত শিরোনামগুলির সাথে কোন ক্ষেত্রে আপনাকে অন্তর্ভুক্ত করতে বাধ্য করা হয়stdafx.h অন্য কোনও কিছুর আগে ।

যুক্তিযুক্ত:source1.h অন্য যে কোনও ফাইলের পূর্বে অন্তর্ভুক্ত করা নিশ্চিত করে যে এটি নির্ভরতা ছাড়াই এটি একা দাঁড়িয়ে থাকতে পারে। যদি source1.hপরবর্তী তারিখের উপর নির্ভরতা অবলম্বন করে, সংকলকটি আপনাকে তত্ক্ষণাত প্রয়োজনীয় ফরোয়ার্ড ঘোষণাগুলি যুক্ত করতে সতর্ক করবে source1.h। এর ফলে এটি নিশ্চিত করে যে শিরোনামগুলি তাদের নির্ভরশীলদের দ্বারা যে কোনও ক্রমে অন্তর্ভুক্ত করা যায়।

উদাহরণ:

source1.h

class Class1 {
    Class2 c2;    // a dependency which has not been forward declared
};

source1.cpp

#include "source1.h"    // now compiler will alert you saying that Class2 is undefined
                    // so you can forward declare Class2 within source1.h
...

এমএসভিসি ব্যবহারকারী: আমি দৃ strongly ়ভাবে প্রাক-সংকলিত শিরোনাম ব্যবহার করার পরামর্শ দিচ্ছি। সুতরাং, #includeস্ট্যান্ডার্ড শিরোনাম (এবং অন্যান্য শিরোনাম যা কখনও বদলাবে না) এর জন্য সমস্ত নির্দেশিকা সরান stdafx.h


2

সর্বাধিক নির্দিষ্ট থেকে অন্তত সুনির্দিষ্ট থেকে অন্তর্ভুক্ত করুন .cpp এর জন্য সংশ্লিষ্ট .hpp দিয়ে শুরু করুন, যদি এরকম কোনও উপস্থিত থাকে। এইভাবে, শিরোনাম ফাইলগুলির মধ্যে কোনও লুকানো নির্ভরতা যা স্বয়ংসম্পূর্ণ নয় তা প্রকাশিত হবে।

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


1

এটি স্ট্যান্ডার্ডের বাইরে অনেক উপাদান সহ সি / সি ++ বিশ্বে একটি কঠিন প্রশ্ন।

আমি মনে করি শিরোনামের মতো, শিরোনামের ফাইল অর্ডারটি যতক্ষণ সঙ্কলিত হয় ততক্ষণ কোনও গুরুতর সমস্যা নয়।

আমার ধারণাগুলি হ'ল: যদি এই সমস্ত শিরোলেখগুলিতে চিহ্নগুলির বিরোধ না হয় তবে কোনও আদেশ ঠিক আছে, এবং ত্রুটিযুক্ত .h এর সাথে # অন্তর্ভুক্ত লাইন যুক্ত করে শিরোনাম নির্ভরতার বিষয়টি পরে ঠিক করা যেতে পারে।

আসল ঝামেলা দেখা দেয় যখন কিছু শিরোনাম উপরে থাকে তার অনুসারে (# শর্তাদি পরীক্ষা করে) তার ক্রিয়া পরিবর্তন করে।

উদাহরণস্বরূপ, VS2005 এর stddef.h এ, রয়েছে:

#ifdef  _WIN64
#define offsetof(s,m)   (size_t)( (ptrdiff_t)&(((s *)0)->m) )
#else
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

এখন সমস্যা: যদি আমার কাছে একটি কাস্টম শিরোলেখ ("কাস্টম এইচ") থাকে যা বেশ কয়েকটি পুরানো offsetofতাদের সিস্টেম শিরোনামে সরবরাহ করে না এমনগুলি সহ অনেকগুলি সংকলক ব্যবহার করতে হয় তবে আমার শিরোনামে আমার লেখা উচিত:

#ifndef offsetof
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

এবং ব্যবহারকারীকে সমস্ত সিস্টেমের শিরোনামের #include "custom.h" পরে তা নিশ্চিত করে বলুন , অন্যথায়, offsetofstddef.h এর রেখাটি ম্যাক্রো পুনঃনির্ধারণ ত্রুটিটি চাপিয়ে দেবে।

আমরা আমাদের কর্মজীবনে এরকম আর কোনও মামলা না দেখার জন্য প্রার্থনা করি।

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