কেন "নেমস্পেস স্ট্যান্ড ব্যবহার করা হচ্ছে"; খারাপ অনুশীলন বিবেচনা?

2638

আমি অন্যদের দ্বারা বলা হয়েছে করেছি যে লেখা using namespace std;কোডে ভুল, এবং আমি ব্যবহার করা উচিত যে std::coutএবং std::cinসরাসরি পরিবর্তে।

কেন using namespace std;একটি খারাপ অভ্যাস হিসাবে বিবেচিত হয় ? এটি কি অদক্ষ নয় বা এটি অস্পষ্ট ভেরিয়েবলগুলি ঘোষণার ঝুঁকির (নামগুলি স্থানের মধ্যে একটি ফাংশন হিসাবে একই নামটি ভাগ করে নেওয়া এমন ভেরিয়েবল std)? এটি কর্মক্ষমতা প্রভাবিত করে?

c++  namespaces  std  using-directives  c++-faq 
— akbiggs
সূত্র
512
আপনি যা করতে পারেন তা ভুলে যাবেন না: "std :: cout ব্যবহার করে;" যার অর্থ আপনাকে এসডিডি :: কাউট টাইপ করতে হবে না, তবে একই সাথে পুরো স্টাডি নাম স্থানটি আনবেন না।
— বিল
2
@ এ পেইড নার্ড গুগল-স্টাইলগাইড.googlecode.com/svn/trunk/… লিঙ্কটি আর কাজ করে না। দেখে মনে হচ্ছে নতুন লিঙ্কটি google.github.io/styleguide/cppguide.html#Other_C++_ বৈশিষ্ট্যগুলি
— এমসিজি
64
হেডার ফাইলগুলিতে ফাইল স্কোপে 'নেমস্পেস স্টাডি ব্যবহার করে' ব্যবহার করা বিশেষত খারাপ। সবগুলি অন্তর্ভুক্ত করার পরে ফাইল স্কোপে এটি উত্স ফাইলগুলিতে (* .cpp) ব্যবহার করা ততটা খারাপ নয়, কারণ এর প্রভাবটি একক অনুবাদ ইউনিটে সীমাবদ্ধ। এমনকি কম সমস্যাযুক্ত এটি ফাংশন বা ক্লাসের অভ্যন্তরে ব্যবহার করছে, কারণ এর প্রভাব কেবল ফাংশন বা শ্রেণির ক্ষেত্রের মধ্যে সীমাবদ্ধ।
— sh-
5
আমি নির্দেশ ব্যবহার ব্যবহার করতে নিরুৎসাহিত কিন্তু নির্দিষ্ট নামব্যবধান চাই std::literals::chrono_literals, Poco::Data:Keywords, Poco::Unitsএবং স্টাফ যে লিটারেল বা পাঠযোগ্যতা ঠাট সাথে মোকাবিলা করতে হবে। যখনই এটি শিরোনাম বা বাস্তবায়ন ফাইলের মধ্যে থাকে। আমার ধারণা মতো কোনও ফাংশন স্কোপে এটি ঠিক আছে, তবে আক্ষরিক এবং স্টাফগুলি বাদ দিয়ে এটি কার্যকর নয়।
— লুডোভিচ জেনোহাতে লাগোয়ার্ডেট
7
@ জোন: বিশেষত নেডস্পেসের সাথে এটির কিছুই করার নেই। আমার জোর বোঝানো "হেডার ফাইলগুলিতে ফাইল স্কোপে" থাকা উচিত। এটিকে পরামর্শ হিসাবে রাখার জন্য: হেডার ফাইলগুলিতে ফাইল স্কোপে "নেমস্পেস ব্যবহার করে" (স্ট্যান্ড বা অন্যান্য) ব্যবহার করবেন না। এটি প্রয়োগকারী ফাইলগুলিতে ব্যবহার করা ঠিক আছে। অস্পষ্টতার জন্য দুঃখিত।
— sh-

উত্তর:

2229

এটি মোটেই পারফরম্যান্সের সাথে সম্পর্কিত নয়। তবে এটি বিবেচনা করুন: আপনি ফু ও বার নামে দুটি গ্রন্থাগার ব্যবহার করছেন:

using namespace foo;
using namespace bar;

সবকিছু ঠিকঠাক কাজ করে এবং আপনি Blah()ফু ও Quux()বার থেকে কল করতে পারেন সমস্যা ছাড়াই। তবে একদিন আপনি ফু 2.0 এর একটি নতুন সংস্করণে আপগ্রেড করবেন, এটি এখন একটি ফাংশন বলে Quux()। এখন আপনার একটি বিরোধ হয়েছে: Foo 2.0 এবং বার উভয়ই Quux()আপনার বিশ্বব্যাপী নেমস্পেসে আমদানি করে। এটি ঠিক করার জন্য কিছু প্রচেষ্টা নিতে চলেছে, বিশেষত যদি ফাংশনটির পরামিতিগুলি মেলে।

আপনি যদি ব্যবহার করেন foo::Blah()এবং bar::Quux(), তবে এর ভূমিকাটি foo::Quux()একটি অ-ইভেন্ট হতে পারে।

— গ্রেগ হিউগিল
সূত্র
435
আমি সবসময় পাইথনের "আমদানি বিগ_হঙ্কিন_নামকে bhn" পছন্দ করেছি যাতে আপনি কেবল "বিগ_হোঁকিন_নাম.সামিংথিং" না করে "bhn.someoming" ব্যবহার করতে পারেন - টাইপিংয়ের কাজটি হ্রাস করে। সি ++ এর কি কিছু আছে?
— paxdiablo
764
@ প্যাক্স নেমস্পেস আইও = বুস্ট :: ফাইল সিস্টেম;
— আরাক
152
আমি মনে করি এটি "সংশোধন করার কিছু প্রচেষ্টা" বলা বাহুল্য বিষয়গুলি ove আপনার কাছে নতুন foo :: Quux এর কোনও উদাহরণ নেই, সুতরাং বার :: Quux এর সাহায্যে আপনার বর্তমান সমস্ত ব্যবহার বন্ধ করে দিন।
— ম্যাটিটি
289
যার অযোগ্য নাম স্ট্যান্ড টাইপের সাথে সংঘর্ষ হয় সেগুলির সাথে কি কোনও বুদ্ধিমান ব্যক্তি লাইব্রেরি তৈরি করতে পারে?
— এরিককালেন
94
@ টোমা: সমস্যাটি #defineহ'ল এটি নিজের নামস্থানগুলিতে সীমাবদ্ধ রাখে না, পুরো কোড বেসের উপরে পদদলিত হয়। একটি নেমস্পেসের উপনামটি যা আপনি চান তা।
— এসবিআই
1390

গ্রেগ লিখেছেন এমন সমস্ত কিছুর সাথে আমি একমত , তবে আমি যুক্ত করতে চাই: এটি গ্রেগের চেয়েও খারাপ হতে পারে!

লাইব্রেরি ফু 2.0 2.0 একটি ফাংশন প্রবর্তন করতে পারে Quux(), এটি আপনার কোডগুলির Quux()কয়েক bar::Quux()বছরের জন্য কল করা কোডের তুলনায় একটি স্পষ্টতই ভাল মিল । তারপরেও আপনার কোডটি এখনও সংকলন করে , তবে এটি নিঃশব্দে ভুল ফাংশনটিকে কল করে এবং godশ্বর-জ্ঞাত-কী। এটি জিনিসগুলি পেতে পারে হিসাবে হিসাবে খারাপ।

মনে রাখবেন যে stdনামস্থান শনাক্তকারী, যার মধ্যে অনেক টন হয়েছে খুব সাধারণ বেশী (মনে list, sort, string, iterator, অত্যধিক, ইত্যাদি) যা খুবই সম্ভাবনা রয়েছে অন্য কোড প্রদর্শিত করতে।

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

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

এক দশকে, এই প্রকল্পের কোডটি কয়েক মিলিয়ন লাইনের হয়ে উঠেছে। যেহেতু এই আলোচনাগুলি বার বার আসে, তাই আমি একবার কৌতূহল usingছিলাম যে প্রকল্পে কতক্ষণ (অনুমোদিত) ফাংশন-স্কোপ ব্যবহার করা হত। আমি এর উত্সগুলি গ্রেপড করেছিলাম এবং কেবল যেখানে এটি ব্যবহার করা হয়েছিল সেখানে এক বা দুই ডজন জায়গা পেয়েছি। আমার কাছে এটি ইঙ্গিত করে যে, একবার চেষ্টা করার পরে, বিকাশকারীরা std::প্রতি 100 কেএলওসি এমনকি যেখানে এটি ব্যবহারের অনুমতি দেওয়া হয়েছিল সেখানে একবারে নির্দেশিকা ব্যবহার করে নিয়োগ করার পক্ষে যথেষ্ট বেদনাদায়ক খুঁজে পান না।

নীচের লাইন: স্পষ্টভাবে প্রত্যেকটি উপসর্গ ব্যবহার করা কোনও ক্ষতি করে না, অভ্যস্ত হওয়ার খুব সামান্য লাগে এবং উদ্দেশ্যমূলক সুবিধা রয়েছে has বিশেষত, এটি সংকলক এবং মানব পাঠকদের দ্বারা কোডটি ব্যাখ্যা করা সহজ করে - এবং কোড লেখার সময় সম্ভবত এটিই প্রধান লক্ষ্য হওয়া উচিত।

— এসবিআই
সূত্র
140
এটি কোডের ঘনত্বকে উল্লেখযোগ্যভাবে ক্ষতি করে যা আপনি একটি একক লাইনে প্যাক করতে পারেন। আপনি আপনার কোডটি খুব দীর্ঘ বাতাসের পথে লিখে শেষ করেছেন; যা পাঠযোগ্যতা হ্রাস করে। ব্যক্তিগতভাবে, আমি মনে করি সংক্ষিপ্ত (তবে খুব ছোট নয়) কোডটি আরও বেশি পঠনযোগ্য হতে পারে (যেহেতু এখানে পড়ার মতো জিনিস কম থাকে, এবং এতে বিভ্রান্ত হওয়ার জন্য কম জিনিস থাকে)।
— মিথ্যা রায়ান
91
অনুমান করুন যে আপনি সি ++ এর একটি স্ট্যান্ডার্ড stringক্লাস করার আগে পুরানো দিনগুলি মিস করেছিলেন এবং মনে হয় প্রতিটি লাইব্রেরির নিজস্ব রয়েছে। আপনাকে কী বলব: আমরা আমাদের কোডটি দিয়ে লিখতে থাকব std::এবং আপনি grep -v std:: | vimযখন আমাদের কোডটি ব্রাউজ করছেন তখন আপনি তা চালাতে পারেন । অথবা আপনি আপনার সম্পাদককে এমন std::একটি কীওয়ার্ড শিখিয়ে দিতে পারেন যা পটভূমির রঙের মতোই রঙিন হতে হয়। যাই হোক না কেন কাজ করে.
— মাইক ডিসিমোন
79
আমি মোটেই std::ক্ষতিকারক বলে মনে করি না । এটি খুব গুরুত্বপূর্ণ তথ্য বহন করে (যথা "স্ট্যান্ডার্ড লাইব্রেরির অংশের পরে যা কিছু আসে") এবং এটি এখনও একটি দুর্দান্ত সংক্ষিপ্ত এবং কমপ্যাক্ট উপসর্গ Most বেশিরভাগ সময় এটি কোনও সমস্যা হয় না Sometimes কখনও কখনও আপনার কোডের কয়েকটি লাইন থাকে যেখানে আপনাকে stdনেমস্পেসে নির্দিষ্ট চিহ্নগুলি উল্লেখ করতে হবে এবং তারপরে usingসেই নির্দিষ্ট ক্ষেত্রের একটি বিবৃতি সমস্যাটি সুন্দরভাবে সমাধান করে But তবে সাধারণ ক্ষেত্রে এটি কোনও গোলমাল নয়, এটি অস্পষ্টতা অপসারণের পাশাপাশি মূল্যবান তথ্য
— জানায়
146
আমি যখনই দেখি std::, আমি জানি এটি std::সম্পর্কে চিন্তা না করেই হতে চলেছে । যদি আমি দেখতে stringবা listবা mapনিজেরাই, আমি একটি বিট ভাবছি।
— মতিন উলহাক
67
@ লাইআরয়ান তারপরে ভাগ্যের লাইব্রেরি লেখার জন্য ভাগ্য ভালো থাকুন না কেন কখনও কিছু নামকরণ করা vector, transformবা distance। এবং এটি স্ট্যান্ডার্ড লাইব্রেরিতে ব্যবহৃত প্রচুর প্রচলিত নামগুলির উদাহরণ examples এগুলিকে ভয়ের বাইরে ব্যবহার না করার বা সি -++ এর একটি অবিচ্ছেদ্য অঙ্গ যে নেমস্পেস বৈশিষ্ট্যটির পক্ষপাতদুষ্ট মতামত, সেগুলি পাল্টে উত্পাদনশীল is
— খ্রিস্টান রাউ
419

using namespaceআপনার ক্লাসের শিরোলেখ ফাইলগুলিতে স্থাপন করার সমস্যাটি হ'ল এটি যে আপনার ক্লাসগুলি ব্যবহার করতে চায় (আপনার শিরোনামের ফাইলগুলি অন্তর্ভুক্ত করে) তাদের সেই অন্যান্য নেমস্পেসগুলি 'ব্যবহার' করতে (অর্থাৎ সমস্ত কিছু দেখে) বাধ্য করতে বাধ্য করে।

তবে আপনি নিজের (ব্যক্তিগত) * .cpp ফাইলগুলিতে ব্যবহারের বিবৃতিটি নির্দ্বিধায় ফেলতে পারেন।

সাবধান হন যে কিছু লোক আমার এই মত "নির্দ্বিধায়" কথাটির সাথে একমত নয় - কারণ যদিও একটি usingসিপিপি ফাইলে একটি বিবৃতি শিরোনামের চেয়ে ভাল (কারণ এটি আপনার শিরোনামের ফাইল অন্তর্ভুক্ত করে এমন লোকগুলিকে প্রভাবিত করে না), তারা মনে করে এটি এখনও নেই ভাল (কারণ কোডের উপর নির্ভর করে এটি ক্লাসের প্রয়োগ আরও বজায় রাখা আরও কঠিন করে তুলতে পারে)। এই সি ++ সুপার-এফএকিউ এন্ট্রি বলছে,

লিগ্যাসি সি ++ কোড এবং নেমস্পেসে স্থানান্তরকে সহজ করার জন্য ব্যবহারের নির্দেশটি বিদ্যমান, তবে আপনার সম্ভবত এটি নিয়মিতভাবে ব্যবহার করা উচিত নয়, কমপক্ষে আপনার নতুন সি ++ কোডে নয়।

FAQ দুটি বিকল্প প্রস্তাব করে:

  • একটি ব্যবহারের ঘোষণা:

    using std::cout; // a using-declaration lets you use cout without qualification
cout << "Values:";

  • সবে এসটিডি টাইপ করা:

    std::cout << "Values:";
— ChrisW
সূত্র
1
অবশ্যই আপনার কখনই গ্লোবাল কাউটের অবস্থা ধরে নেওয়া উচিত নয়, পাছে কেউ স্ট্যান্ড করেছেন: কোট << স্টাডি :: হেক্স এবং পরে স্ট্যান্ড :: পুনরুদ্ধার_কাউট_স্টেটে ব্যর্থ হয়েছে। তবে এটি সম্পূর্ণ অন্য ফ্যাটবার্গ।
— Moz
233

আমি সম্প্রতি ভিজ্যুয়াল স্টুডিও 2010 সম্পর্কে একটি অভিযোগে দৌড়েছি । দেখা গেল যে সমস্ত উত্স ফাইলগুলিতে এই দুটি লাইন ছিল:

using namespace std;
using namespace boost;

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

অতএব, এড়ানো এড়ানো using namespace X;ভবিষ্যতের প্রুফিংয়ের একটি ফর্ম, গ্রন্থাগারগুলি এবং / অথবা ব্যবহৃত হেডার ফাইলগুলিতে পরিবর্তনটি নিশ্চিত করার একটি উপায় কোনও প্রোগ্রাম ভাঙ্গা যাচ্ছে না।

— ডেভিড থর্নলি
সূত্র
14
এই. বুস্ট এবং স্টাডির প্রচুর ওভারল্যাপ রয়েছে - বিশেষত সি ++ 11 থেকে।
— einpoklum
1
আমি এটি একবার করেছিলাম এবং কঠোরভাবে একটি পাঠ শিখেছি। এখন আমি কোনও usingফাংশন সংজ্ঞার বাইরে কখনও ব্যবহার করি না এবং খুব কমই ব্যবহার করি using namespace।
— ফেরুক্সিও
210

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

সারসংক্ষেপ

নেমস্পেসের ব্যবহারগুলি আপনার সুবিধার জন্য, অন্যের উপর চাপ দেওয়ার জন্য নয়: কোনও # অন্তর্ভুক্ত নির্দেশিকার আগে কোনও ব্যবহারের ঘোষণা বা কোনও ব্যবহার নির্দেশিকা কখনই লিখবেন না।

প্রত্নতাত্ত্বিক: শিরোনাম ফাইলগুলিতে, নির্দেশাবলী ব্যবহার করে বা ঘোষণা ব্যবহার করে নেমস্পেস-লেভেলটি লিখবেন না; পরিবর্তে, সমস্ত নাম স্পষ্টতই নেমস্পেস-যোগ্যতা অর্জন করুন। (দ্বিতীয় নিয়মটি প্রথম থেকে অনুসরণ করা হয়, কারণ হেডাররা কখনই বুঝতে পারে না যে তাদের পরে অন্যান্য শিরোনাম কী অন্তর্ভুক্ত হতে পারে))

আলোচনা

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

— mattnewport
সূত্র
4
এখানে আরও একটি প্রোগ্রামারের মতামত, তবে আমি এই শব্দের সাথে 100% সম্মত হয়েছি যে শব্দটি usingকখনই শিরোনামে উপস্থিত না হওয়া উচিত, আমি using namespace xyz;আপনার কোডের যে কোনও জায়গায় রাখার জন্য বিনামূল্যে লাইসেন্স সম্পর্কে তেমন নিশ্চিত নই , বিশেষত যদি xyzহয় std। আমি using std::vector;ফর্মটি ব্যবহার করি , যেহেতু এটি নামস্থান থেকে কেবলমাত্র একটি উপাদানকে সিউডো-গ্লোবাল স্কোপে টানায়, ফলে সংঘর্ষের ঝুঁকি অনেক কম far
— dgnuff
2
অরবিটে @ লাইটনেস রেস আপনি অবশ্যই আপনার মতের অধিকারী। আপনি যদি এই উত্তরে প্রদত্ত পরামর্শের সাথে একমত না হন তবে ব্যাখ্যা করার কিছু চেষ্টা করা থাকলে আরও সহায়ক হত। বিশেষত এটি বুঝতে আগ্রহী হবে যে যদি নাম ব্যবহারের ক্ষেত্রগুলি 'ব্যবহার' করা খারাপ হয় তবে তা কী? কেন কেবল স্টাডি :: কাউটের পরিবর্তে জিনিসগুলিকে স্টডি_কাউট রাখবেন না ... সি ++ / নেমস্পেসের নির্মাতারা যখন তাদের তৈরি করতে বিরক্ত করেছিলেন তখন অবশ্যই তাদের কিছু ধারণা থাকতে হবে।
— nyholku
1
@ কোনহোলকু: দরকার নেই - অন্যান্য উত্তরগুলির বেশিরভাগই আমার একই কারণে দেয়। এছাড়াও দয়া করে ":)" নোট করতে দ্বিধা করবেন না আমি আমার মন্তব্যে যুক্ত হয়েছি! এবং যে আমি বলিনি যে নেমস্পেসগুলি খারাপ।
— অরবিট
হ্যাঁ, আমি লক্ষ্য করেছি যে :) তবে আইএমও উত্তর সর্বাধিক (যে এই ageষি পরামর্শের বিরুদ্ধে যায়) বিপথগামী (নয় যে আমি এখন কোনও সংখ্যাগরিষ্ঠতা তৈরি করি তা নয়) majority যদি আপনি সম্মত হন যে নেমস্পেসটি 'খারাপ নয়' তবে আপনি এই উত্তরটির সাথে একমত না হলে আপনি যেখানে উপযুক্ত বলে মনে করছেন তা বলতে পারেন?
— nyholku
আমি কিন্তু সাহায্য মনে করেন যে করতে পারবে না using namespaceমন্দ মত হল gotoমন্দ। উভয়ের বৈধ ব্যবহার রয়েছে তবে 1000 এর মধ্যে 999 বার এগুলি ভুল ব্যবহার করা হবে। সুতরাং, হ্যাঁ, using namespaceউত্সটির সাহায্যে আপনি অন্যান্য নামগুলির স্থান স্পষ্ট করে দূষিত করবেন না। তবে এটি আপনাকে "মজাদার" বিরুদ্ধে রক্ষা করবে না যা using namespace Foo+ using namespace Barআপনি কল করার সাথে সাথে উদ্ভূত হয়েছে (অন্তর্নিহিত ফু: :) baz(xyz)এবং হঠাৎ করে কোড ভাঙা (কোনও পরিবর্তন ছাড়াই) Bar::baz()কোথাও যুক্ত হওয়ার কারণে , যা কেবল আরও ভাল হবে বলে মনে হয় ম্যাচ (এবং এভাবে এখন পরিবর্তে ডাকা হয়)
— চারনএক্স
122

usingগ্লোবাল স্কোপ, বিশেষত শিরোনামে নির্দেশের ব্যবহার করা উচিত নয় । যাইহোক, এমন পরিস্থিতি রয়েছে যেখানে এটি শিরোনাম ফাইলটিতেও উপযুক্ত:

template <typename FloatType> inline
FloatType compute_something(FloatType x)
{
    using namespace std; // No problem since scope is limited
    return exp(x) * (sin(x) - cos(x * 2) + sin(x * 3) - cos(x * 4));
}

এটি সুস্পষ্ট যোগ্যতার ( std::sin, std::cos...) এর চেয়ে আরও ভাল , কারণ এটি সংক্ষিপ্ত এবং ব্যবহারকারী সংজ্ঞায়িত ভাসমান পয়েন্টের ধরণের ( যুক্তি-নির্ভর নির্ভরতা (এডিএল) এর মাধ্যমে) এর সাথে কাজ করার ক্ষমতা রাখে ।

— robson3.14
সূত্র
9
আমি দুঃখিত, তবে আমি এর সাথে দৃ strongly়ভাবে একমত নই।
— বিলি ওনিল
4
@ বিলি: ইউজারলিব :: কোস (ইউজারলিব :: সুপারিন্ট) কে কল করার পক্ষে আর কোনও উপায় নেই। প্রতিটি বৈশিষ্ট্যের একটি ব্যবহার আছে।
— ঝ্যান লিংস
17
@ জ্যান: অবশ্যই আছে। using std::cos;, using std::sinইত্যাদি ইত্যাদি বিষয়টি হ'ল সমস্যাটি হ'ল যে কোনও ভালভাবে ডিজাইন userlibকরা তাদের নিজস্ব নামের জায়গার পাশাপাশি থাকবে sinএবং cosতাই এটি আপনাকে সত্যিই সহায়তা করে না। (যদি না using namespace userlibএই টেম্পলেটটির আগে না থাকে এবং এটি ঠিক ততটা খারাপ using namespace std- এবং সেটার সুযোগটি সীমাবদ্ধ নেই Furthermore) তদুপরি, আমি এর মতো একমাত্র ফাংশনটি কখনই ঘটতে দেখি swapএবং এরকম ক্ষেত্রে আমি কেবলমাত্র একটি টেম্পলেট তৈরি করার পরামর্শ দেব বিশেষত্ব std::swapএবং সম্পূর্ণ সমস্যা এড়ানো।
— বিলি ওনিল
11
@ বিলিওনিল: template<typename T> void swap(MyContainer<T>&, MyContainer<T>&)(কোনও ফাংশন টেমপ্লেট আংশিক বিশেষায়িতকরণ (এফটিপিএস) নেই, তাই কখনও কখনও আপনার পরিবর্তে ওভারলোডিং অবলম্বন করা প্রয়োজন
— এসবিআই
38
@BillyONeal: আপনার মন্তব্য ভুল - আপনার বর্ণনা দেওয়া পরিস্থিতিটির আছে (7-বার-upvoted!) ঠিক কি ADL কভার পরিকল্পিত ছিল। সংক্ষেপে, যদি xএক বা একাধিক "যুক্ত নেমস্পেসস" থাকে (যেমন এটি সংজ্ঞায়িত করা থাকে namespace userlib) তবে এর আগে যে কোনও ফাংশন কল মনে হচ্ছে সেগুলি অতিরিক্তভাবে সেই নামের জায়গাগুলিতে সন্ধান cos(x)করবে - আগে কোনও প্রয়োজন ছাড়াই । Zan Lynx ঠিক আছে (এবং সি ++ নামের চেহারা বাইজেন্টাইন ...)using namespace userlib;
— j_random_hacker
97

বিশ্বব্যাপী এটি ব্যবহার করবেন না

কেবলমাত্র বিশ্বব্যাপী ব্যবহৃত হলে এটি "খারাপ" হিসাবে বিবেচিত হয় । কারণ:

  • আপনি যে নেমস্পেসে প্রোগ্রামিং করছেন সেগুলি আপনি বিশৃঙ্খলা করে।
  • যখন আপনি অনেকগুলি ব্যবহার করেন তখন কোনও নির্দিষ্ট শনাক্তকারী কোথা থেকে আসে তা দেখতে পাঠকদের অসুবিধা হবে using namespace xyz।
  • আপনার উত্স কোডের অন্যান্য পাঠকদের জন্য যা কিছু সত্য তা একেবারে ঘন ঘন পাঠকের পক্ষে আরও সত্য: নিজেই। দু'বছরের মধ্যে ফিরে আসুন এবং একবার দেখুন ...
  • যদি আপনি কেবল তার সম্পর্কে কথা বলেন তবে using namespace stdআপনি যে সমস্ত জিনিস দখল করেছেন সে সম্পর্কে আপনি সচেতন নাও হতে পারেন - এবং আপনি যখন অন্যটি যুক্ত করেন #includeবা একটি নতুন সি ++ রিভিশনে স্থানান্তরিত করেন তখন আপনি নাম দ্বন্দ্ব পেতে পারেন যা আপনি জানেন না।

আপনি এটি স্থানীয়ভাবে ব্যবহার করতে পারেন

এগিয়ে যান এবং এটি স্থানীয়ভাবে (প্রায়) অবাধে ব্যবহার করুন। এটি অবশ্যই আপনাকে পুনরাবৃত্তি হতে বাধা দেয় std::- এবং পুনরাবৃত্তিটিও খারাপ।

স্থানীয়ভাবে এটি ব্যবহারের জন্য একটি প্রতিমা

C ++ 03 এ একটি প্রতিমা ছিল - বয়লারপ্লেট কোড - swapআপনার ক্লাসগুলির জন্য কোনও ক্রিয়াকলাপ বাস্তবায়নের জন্য। এটি প্রস্তাবিত হয়েছিল যে আপনি আসলে স্থানীয় ব্যবহার করুন using namespace std- বা কমপক্ষে using std::swap:

class Thing {
    int    value_;
    Child  child_;
public:
    // ...
    friend void swap(Thing &a, Thing &b);
};
void swap(Thing &a, Thing &b) {
    using namespace std;      // make `std::swap` available
    // swap all members
    swap(a.value_, b.value_); // `std::stwap(int, int)`
    swap(a.child_, b.child_); // `swap(Child&,Child&)` or `std::swap(...)`
}

এটি নিম্নলিখিত যাদুটি করে:

  • সংকলকটি এর std::swapজন্য value_অর্থাত্ পছন্দ করবে void std::swap(int, int)।
  • আপনার যদি ওভারলোড void swap(Child&, Child&)প্রয়োগ করা হয় তবে সংকলকটি এটি চয়ন করবে।
  • আপনার যদি ওভারলোড না থাকে তবে সংকলকটি ব্যবহার করবে void std::swap(Child&,Child&)এবং এগুলির সেরা অদলবদল করার চেষ্টা করবে ।

সি ++ 11 এর সাথে এই প্যাটার্নটি আর ব্যবহার করার কোনও কারণ নেই। std::swapসম্ভাব্য ওভারলোড খুঁজে পেতে এবং এটি চয়ন করতে এর বাস্তবায়ন পরিবর্তন করা হয়েছিল।

— towi
সূত্র
5
"একটি সম্ভাব্য ওভারলোড খুঁজে পেতে এবং এটি চয়ন করার জন্য std :: swap এর বাস্তবায়ন পরিবর্তন করা হয়েছিল।" - কি? আপনি কি এ ব্যাপারে নিশ্চিত? যদিও এটি সত্য যে swapপ্রথমে একটি কাস্টম সরবরাহ করা সি ++ 11 এ আর অতটা গুরুত্বপূর্ণ নয়, যেহেতু std::swapনিজেই আরও নমনীয় (পদক্ষেপ শব্দার্থ ব্যবহার করে)। তবে std::swapস্বয়ংক্রিয়ভাবে আপনার নিজস্ব কাস্টম অদলবদলটি বেছে নেওয়া, এটি আমার কাছে একেবারেই নতুন (এবং আমি সত্যই এটি বিশ্বাস করি না)।
— খ্রিস্টান রাউ
@ ক্রিশ্চিয়ানো রাঃ আমি তাই মনে করি, হ্যাঁ। আমি কোথাও এটি পড়েছি। আমরা সর্বদা হাওয়ার্ডকে জিজ্ঞাসা করতে পারি , তার জানা উচিত। আমি এখন খনন এবং খনন করছি ...
— তোয়াই
14
এমনকি অদলবদলের ক্ষেত্রেও পরিষ্কার (এবং ধন্যবাদ আরও সাধারণ) বুদ্ধিমান লেখার using std::swap;পরিবর্তে লিখতে হয় using namespace std;। আরও নির্দিষ্ট আইডিয়মের কম পার্শ্ব প্রতিক্রিয়া রয়েছে এবং তাই কোডটি আরও রক্ষণাবেক্ষণযোগ্য করে তোলে।
— অ্যাড্রিয়ান ম্যাকার্থি
11
চূড়ান্ত বাক্যটি ভুল। সি ++ এ 11 তে স্ট্যান্ড অদলবদল পদক্ষেপটি আনুষ্ঠানিকভাবে কল করার সঠিক উপায় হিসাবে আশীর্বাদ swapপেয়েছিল এবং স্ট্যান্ডার্ডের অন্যান্য বিভিন্ন স্থানকে তারা এমনভাবে ফোন করার জন্য পরিবর্তন করা হয়েছিল swap(উপরে বর্ণিত এনবি using std::swapসঠিকভাবে নয়, নয় using namespace std)। কিন্তু std::swapনিজেই প্রবলভাবে ছিল না অন্য কিছু খুঁজে পেতে পরিবর্তিত swapএবং এটি ব্যবহার। যদি std::swapডাকা হয়, তবে std::swapব্যবহার হয়।
— জোনাথন ওয়াকলি
3
এটি using std::swapস্থানীয়ভাবে টাইপ করা বুদ্ধিমানের কাজ হতে পারে যদিও একই সাথে স্ব-ডকুমেন্টিং কোড তৈরি করার সময় স্থানীয় নেমস্পেসকে হ্রাস করতে। আপনি পুরো স্ট্যান্ড নেমস্পেসে খুব কমই আগ্রহী, তাই আপনার আগ্রহী অংশগুলি বেছে নিন
— লন্ডিন
79

আপনি সঠিক হেডার ফাইল ইম্পোর্ট আপনি হঠাৎ নাম মত আছে hex, left, plusবা countআপনার গ্লোবাল সুযোগ। আপনি যদি অবহিত না হন তবে std::এই নামগুলি অন্তর্ভুক্ত করলে এটি অবাক হতে পারে । আপনি যদি স্থানীয়ভাবে এই নামগুলি ব্যবহার করার চেষ্টা করেন তবে এটি বেশ কিছু বিভ্রান্তির কারণ হতে পারে।

সমস্ত মানক স্টাফ যদি তার নিজস্ব নামস্থানে থাকে তবে আপনার কোড বা অন্যান্য লাইব্রেরির সাথে নাম সংঘর্ষের বিষয়ে আপনাকে চিন্তা করতে হবে না।

— হেলায়
সূত্র
12
+1 উল্লেখ নেই distance। এখনও আমি অ-যোগ্যতাসম্পন্ন নাম যেখানেই ব্যবহারিকভাবে সম্ভাবনা পছন্দ করি, যেহেতু এটি আমার জন্য পঠনযোগ্যতা বৃদ্ধি করে। অধিকন্তু, আমি এই সত্যটি মনে করি যে আমরা সাধারণত মৌখিক বক্তৃতায় জিনিসগুলিকে যোগ্যতা অর্জন করি না এবং সম্ভাব্য অস্পষ্টতাগুলি সমাধান করতে সময় কাটাতে ইচ্ছুক, তার অর্থ এই যে এর যোগ্যতা ছাড়াই যে কী কথা বলছে তা বুঝতে সক্ষম হওয়ার মূল্য রয়েছে এবং উত্সটিতে প্রয়োগ করা হয়েছে কোড যার অর্থ এটি এমনভাবে কাঠামোযুক্ত হয়েছে যে এটি যোগ্যতা ছাড়াই এমন কি এটি পরিষ্কার।
— চিয়ার্স এবং এইচটিএইচ - Alf
ন্যায্য, যদিও, আপনি যদি না অন্তর্ভুক্ত না করেন তবে আপনার বেশিরভাগের নেই <iomanip>। তবুও, ভাল পয়েন্ট।
— einpoklum
48

আর একটি কারণ অবাক।

আমি যদি দেখি cout << blah, পরিবর্তে std::cout << blahআমার মনে হয়: এটি কি cout? এটা কি স্বাভাবিক cout? এটা কি বিশেষ কিছু?

— মার্টিন বেকেট
সূত্র
25
এটা কি একটি তামাশা? আমি সত্যি বলতে পারি না। যদি তা না হয় তবে আমি ব্যক্তিগতভাবে ধরে নিয়ে যাব যে আপনি যদি কোডটিতে বিশ্বাস না করেন তবে এটি ব্যক্তিগত মেঘ কোড, আইএমও এর বাইরে হবে Y ... এবং আপনি যদি কোডটিতে বিশ্বাস না করেন তবে আপনি কেন এটি প্রথম স্থানে ব্যবহার করছেন? নোট করুন যে আমি "বিশ্বাসের সমস্ত কিছু বলছি না!" তবে আপনি যদি গিটহাবের কিছু পরিচিত গ্রন্থাগার বা কোনও কিছুর সাথে লেনদেন করেন তবে এটি কিছুটা দূরে পাওয়াও মনে হয়।
— ব্রেন্ট রাইটেনহাউস
28
@ ব্রেন্টরিটেনহাউস coutএকটি খারাপ উদাহরণ কারণ প্রত্যেকে এটি স্বীকৃতি দেয়। কিন্তু futureএকটি আর্থিক অ্যাপ্লিকেশন কল্পনা করুন। কোনও নির্দিষ্ট তারিখে কিছু কেনা বেচার চুক্তি কি? না এটা না। কোডটি যদি বলে যে std::futureআপনি এত সহজে বিভ্রান্ত হবেন না।
— জেমস হলিস
2
@ ব্রেন্টরেটেনহাউস সম্ভবত কিছুটা খারাপ উদাহরণ হতে পারে, কমপক্ষে চারটি পৃথক গ্রন্থাগার রয়েছে যার মধ্যে কোট রয়েছে। হতে পারে "এটি কি স্ট্যান্ডার্ড লাইব্রেরি? Libstdc ++? Stl? অন্য কিছু?" এবং না, সবাই জানেন না std :: cout, অন্তত অন্তর্নিহিতভাবে, আমরা প্রাপ্ত 7 টি নতুন কর্মীর মধ্যে 6 জন তা জানে না। কারণ শিক্ষার পাঠ্যক্রম শিক্ষায় ব্যবহার করে না। আমাকে প্রিন্টফেস তাড়াতে হবে। বা ডিবাগস () - কিউটি থেকে।
— সুইফ্ট - শুক্রবার পাই
1
সত্যি? এটি সি ++ এর উপর অনেকগুলি বইয়ের প্রথম অধ্যায়ের প্রথম উদাহরণে খুব বেশি কিছু, যদি এটি (সন্নিবেশ অপারেটরের ব্যবহার সহ) থাকে তবে কেবলমাত্র সি ++ কিছু নতুন সংস্থা জানেন।
— ম্যাকেনজম
@ এমকেনজম আমি এলোমেলো হ্রাস করতে কোনও বই বা বক্তৃতা নোটগুলিতে রেখেছি, তবে কোডে নেই
— মার্টিন বেকেট
45

অভিজ্ঞ প্রোগ্রামাররা যা কিছু সমস্যা সমাধান করে তা ব্যবহার করে এবং যা কিছু নতুন সমস্যা সৃষ্টি করে তা এড়িয়ে চলে এবং তারা সঠিক কারণের জন্য শিরোনাম-ফাইল-স্তর-নির্দেশকে এড়িয়ে চলে।

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

এই ভাল কারণগুলি কি কি ? কখনও কখনও প্রোগ্রামাররা স্পষ্টতই ADL বন্ধ করতে চায়, অন্য সময় তারা বন্ধ করতে চায়।

সুতরাং নিম্নলিখিতটি ঠিক আছে:

  1. ফাংশনগুলির বাস্তবায়নের অভ্যন্তরে ফাংশন-স্তরের ব্যবহার-নির্দেশনা এবং ব্যবহার-ঘোষণা
  2. উত্স ফাইলের অভ্যন্তরে উত্স-ফাইল-স্তর ব্যবহার-ঘোষণা
  3. (কখনও কখনও) উত্স-ফাইল-স্তর-নির্দেশাবলী ব্যবহার করে
— আলেকজান্ডার পোলেক্টোভ
সূত্র
43

আমি একমত যে এটি বিশ্বব্যাপী ব্যবহার করা উচিত নয়, তবে এটি স্থানীয়ভাবে ব্যবহার করা এতটা খারাপ নয় namespace। এখানে "দ্য সি ++ প্রোগ্রামিং ল্যাঙ্গুয়েজ" এর একটি উদাহরণ রয়েছে :

namespace My_lib {

    using namespace His_lib; // Everything from His_lib
    using namespace Her_lib; // Everything from Her_lib

    using His_lib::String; // Resolve potential clash in favor of His_lib
    using Her_lib::Vector; // Resolve potential clash in favor of Her_lib

}

এই উদাহরণে, আমরা তাদের রচনা থেকে উদ্ভূত সম্ভাব্য নাম সংঘর্ষ এবং অস্পষ্টতা সমাধান করেছি।

সেখানে স্পষ্টভাবে ঘোষিত নামগুলি (যেমন-ঘোষণা দ্বারা ঘোষিত নামগুলি সহ His_lib::String) ব্যবহার-নির্দেশিকা ( using namespace Her_lib) দ্বারা অন্য স্কোপে অ্যাক্সেসযোগ্য হয়ে যাওয়া নামগুলির চেয়ে অগ্রাধিকার গ্রহণ করে ।

— Oleksiy
সূত্র
29

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

তবে আমি যদি প্রায়শই 'cout' এবং 'cin' ব্যবহার করি তবে আমি লিখি: using std::cout; using std::cin;.cpp ফাইলে (কখনও এটি শিরোনামের ফাইলে যেমন প্রচার হয় না #include)। আমি মনে করি যে কোনও বুদ্ধিমান কখনও স্রোতের নাম coutবা নাম রাখিবে না cin। ;)

— Yelonek
সূত্র
7
এটা একটা স্থানীয় ব্যবহার করছে ঘোষণা , একটি ব্যবহার থেকে একটি ভিন্ন জিনিস নির্দেশ ।
— এসবিআই
25

কোডটি দেখতে এবং এটি কী করে তা জানতে পেরে দুর্দান্ত। যদি আমি দেখি std::coutযে coutএটি stdগ্রন্থাগারের স্রোত । আমি যদি দেখি coutতবে জানি না। এটি গ্রন্থাগারের প্রবাহ হতে পারে । বা একই ফাংশনে দশ লাইন বেশি হতে পারে । অথবা একটি ফাইলের নাম পরিবর্তনশীল । এটা কিছু হতে পারে।coutstdint cout = 0;staticcout

এখন একটি মিলিয়ন লাইন কোড বেস নিন, যা বিশেষত বড় নয় এবং আপনি একটি বাগ অনুসন্ধান করছেন, যার অর্থ আপনি জানেন যে এই দশ মিলিয়ন লাইনে একটি লাইন রয়েছে যা এটি করার কথা বলে তা করে না। cout << 1;একটি static intনাম পড়তে পারে cout, এটি একটুখানি করে বামে স্থানান্তরিত করতে পারে এবং ফলাফলটি ফেলে দিতে পারে। একটি বাগ খুঁজছেন, আমাকে এটি পরীক্ষা করে দেখতে হবে। আপনি কি দেখতে পাচ্ছেন যে আমি সত্যিই দেখতে পছন্দ করি std::cout?

এটি এমন একটি জিনিস যা আপনি যদি শিক্ষক হন এবং জীবিকা নির্বাহের জন্য কোনও কোড লিখতে বা বজায় রাখতে না হয় তবে এটি সত্যিই ভাল ধারণা বলে মনে হয়। আমি কোডটি দেখতে পছন্দ করি যেখানে (1) আমি জানি এটি কী করে; এবং, (2) আমি আত্মবিশ্বাসী যে এটি লেখার ব্যক্তি এটি জানেন কী।

— gnasher729
সূত্র
4
আপনি কীভাবে জানবেন যে "std :: cout << 1" স্টাড্ড নেমস্পেসে স্ট্যাটিক ইন্ট নামের কাউট পড়ছে না একে একে বদলে এবং ফলাফল ফেলে দিচ্ছে? এছাড়াও আপনি কীভাবে জানেন যে "<<" কী করে;) ??? ... মনে হচ্ছে এই উত্তরটি 'ব্যবহার' এড়াতে ভাল ডেটা পয়েন্ট নয়।
— nyholku
4
যদি কেউ একটি পূর্ণসংখ্যার হিসাবে std :: cout এর নতুন সংজ্ঞা দেয়, তবে আপনার সমস্যাটি প্রযুক্তিগত নয়, তবে সামাজিক - কারও কাছে এটি রয়েছে। (এবং আপনার সম্ভবত # নির্ধারিত সত্য মিথ্যা ইত্যাদির জন্য সমস্ত শিরোলেখ পরীক্ষা করা উচিত)
— জেরেমি ফ্রাইজনার
2
যখন আমি কাউট দেখি তখন আমি জানি যে এটি সর্বদা :: stout :: cout। আমি যদি ভুল হয়ে থাকি তবে এই ব্যক্তির সমস্যা যিনি এই কোডটি লিখেছেন, তা আমার নয় :)
— টিয়েন ডু
22

জটিলতা পরিচালনার জন্যই এটি। নেমস্পেসটি ব্যবহার করে এমন জিনিসগুলিকে টানবে যা আপনি চান না এবং এটি সম্ভবত ডিবাগ করা আরও শক্ত করে তোলে (আমি সম্ভবত বলি)। সমস্ত জায়গাতেই স্ট্যান্ড :: ব্যবহার করা পড়া বেশি শক্ত (আরও বেশি পাঠ্য এবং এগুলি)।

কোর্সের জন্য ঘোড়া - আপনার জটিলতা পরিচালনা করুন আপনি কীভাবে সেরা এবং সক্ষম বোধ করতে পারেন।

— প্রীত সংঘ
সূত্র
18

বিবেচনা

// myHeader.h
#include <sstream>
using namespace std;


// someoneElses.cpp/h
#include "myHeader.h"

class stringstream {  // Uh oh
};

এটি একটি সহজ উদাহরণ নোট করুন। আপনার যদি 20 টি সহ অন্তর্ভুক্ত ফাইল এবং অন্যান্য আমদানি থাকে তবে সমস্যাটি বের করার জন্য আপনার কাছে এক টন নির্ভরতা থাকতে হবে। এটির নিকৃষ্টতর বিষয় হ'ল আপনি সংঘাতের সংজ্ঞা অনুসারে অন্যান্য মডিউলগুলিতে সম্পর্কযুক্ত ত্রুটি পেতে পারেন।

এটি ভয়াবহ নয়, তবে আপনি এটি হেডার ফাইলগুলিতে বা বিশ্বব্যাপী নেমস্পেসে ব্যবহার না করে নিজের মাথাব্যথা বাঁচিয়ে রাখবেন। এটি খুব সীমিত স্কোপগুলিতে করা ঠিক আছে তবে আমার ফাংশনগুলি কোথা থেকে আসছে তা পরিষ্কার করতে অতিরিক্ত পাঁচটি অক্ষর টাইপ করতে আমার কখনও সমস্যা হয়নি।

— রন ওয়ারহোলিক
সূত্র
18

  1. আপনার চেয়ে আলাদা স্টাইল এবং সেরা অনুশীলনের মতামত রয়েছে এমন লোকদের দ্বারা লিখিত কোডটি আপনাকে পড়তে সক্ষম হতে হবে।

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

— ডাস্টিন গেটেজ
সূত্র
17

একই সাথে অনেকগুলি নেমস্পেস ব্যবহার করা স্পষ্টতই বিপর্যয়ের একটি রেসিপি তবে জাস্ট নেমস্পেস stdএবং একমাত্র নেমস্পেস ব্যবহার করেstd করা আমার মতে এতটা বড় বিষয় নয় কারণ পুনরায় সংজ্ঞা শুধুমাত্র আপনার নিজের কোড দ্বারা ঘটতে পারে ...

সুতরাং কেবল তাদের "int" বা "শ্রেণি" এর মতো সংরক্ষিত নাম হিসাবে ফাংশন বিবেচনা করুন এবং এটিই।

লোকেরা এটি সম্পর্কে এতটা বেঁচে থাকা বন্ধ করে দেওয়া উচিত। আপনার শিক্ষক ঠিক পাশাপাশি ছিলেন। কেবলমাত্র একটি নেমস্পেস ব্যবহার করুন; নাম স্থানটি প্রথম স্থান ব্যবহারের সম্পূর্ণ পয়েন্ট। আপনার একই সাথে একাধিক ব্যবহার করার কথা নয়। যদি না এটি আপনার নিজস্ব হয়। সুতরাং আবার, নতুন সংজ্ঞা হবে না।

— user2645752
সূত্র
সংঘর্ষ তৈরি করা যেমন শক্ত - ছোট স্ট্রিংগুলির মতো নয় min, endএবং নেমস্পেসে lessউপস্থিত হয় appear std::তবে আরও, এখন std::এতে হাজার হাজার চিহ্ন রয়েছে, পাঠকের পক্ষে এটি জানতে কার্যকর যে তারা হয়ত জানেন না এমন একটি নতুন প্রতীক কোথা থেকে এসেছে।
— টম সওয়ারলি
স্ট্যান্ডিং নেমস্পেসটি বিদ্যমান কারণ আপনি, আপনার সহকর্মীরা, বা মিডলওয়্যারগুলি আপনি ব্যবহার করেন এমন লোকেরা সর্বদা নেমস্পেসের ভিতরে ফাংশন রাখার বিষয়ে জ্ঞানী হয় না। সুতরাং আপনি সমস্ত এসটিডি :: এবং অন্য কোনও কিছুই আমদানি করতে পারবেন না, যখন এখনও স্টাডে থাকাকালীন সময়ে বলুন, স্ট্যান্ড :: মিনিট এবং অন্য কারও লিগ্যাসি :: মিনিট () এর মধ্যে সংঘর্ষের আহ্বান জানাতে হবে।
— আইকেন ড্রাম
14

আমি এখানে অন্যদের সাথে একমত, তবে আমি পঠনযোগ্যতা সম্পর্কিত উদ্বেগগুলি সমাধান করতে চাই - আপনি কেবল আপনার ফাইল, ফাংশন বা শ্রেণির ঘোষণার শীর্ষে টাইপডেফগুলি ব্যবহার করে এগুলি এড়াতে পারেন।

আমি সাধারণত এটি আমার শ্রেণির ঘোষণাপত্রে ব্যবহার করি কারণ শ্রেণীর পদ্ধতিগুলি একই রকমের ডেটা (সদস্যদের) নিয়ে কাজ করে এবং টাইপডিফ এমন একটি নাম নির্ধারণের সুযোগ যা ক্লাসের প্রসঙ্গে অর্থবহ। এটি ক্লাস পদ্ধতির সংজ্ঞাগুলিতে পাঠযোগ্যতার সহায়তা করে ability

// Header
class File
{
   typedef std::vector<std::string> Lines;
   Lines ReadLines();
}

এবং বাস্তবায়নে:

// .cpp
Lines File::ReadLines()
{
    Lines lines;
    // Get them...
    return lines;
}

উল্টোদিকে:

// .cpp
vector<string> File::ReadLines()
{
    vector<string> lines;
    // Get them...
    return lines;
}

বা:

// .cpp
std::vector<std::string> File::ReadLines()
{
    std::vector<std::string> lines;
    // Get them...
    return lines;
}
— কার্ল
সূত্র
কেবল একটি ছোট্ট মন্তব্য, যখন টাইপিডেফ দরকারী তখন আমি টাইপফ ব্যবহার করার পরিবর্তে লাইন্সকে উপস্থাপন করে এমন একটি ক্লাস তৈরি করার বিষয়টি বিবেচনা করব।
— আইয়াল সলনিক
14

উদ্বেগকে স্পষ্ট করার একটি দৃ concrete় উদাহরণ। আপনার দু'টি গ্রন্থাগার রয়েছে fooএবং barপ্রত্যেকটির নিজস্ব নামের স্থান রয়েছে এমন পরিস্থিতিটি কল্পনা করুন :

namespace foo {
    void a(float) { /* Does something */ }
}

namespace bar {
    ...
}

এখন যাক আপনি নীচের মত আপনার নিজের প্রোগ্রামে fooএবং barএকসাথে ব্যবহার করুন :

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

এই মুহুর্তে সবকিছু ঠিক আছে। আপনি যখন আপনার প্রোগ্রামটি চালান এটি 'কিছু করে'। তবে পরে আপনি আপডেট করেন barএবং বলুন যে এটির মতো হয়ে গেছে:

namespace bar {
    void a(float) { /* Does something completely different */ }
}

এই মুহুর্তে আপনি একটি সংকলক ত্রুটি পাবেন:

using namespace foo;
using namespace bar;

void main() {
    a(42);  // error: call to 'a' is ambiguous, should be foo::a(42)
}

সুতরাং 'এ' বোঝাতে চাইলে আপনাকে কিছু রক্ষণাবেক্ষণ করতে হবে foo::a। যে অবাঞ্ছিত, কিন্তু সৌভাগ্যবশত এটা বেশ সহজ (ঠিক যোগ foo::করা সমস্ত কল সামনে aদ্ব্যর্থক হিসাবে কম্পাইলার চিহ্ন)।

তবে এমন বিকল্প দৃশ্যের কল্পনা করুন যেখানে বার পরিবর্তে এর মতো দেখতে পরিবর্তিত হয়েছে:

namespace bar {
    void a(int) { /* Does something completely different */ }
}

এই মুহুর্তে আপনার কলটি a(42)হঠাৎ bar::aপরিবর্তে বাঁধাfoo::a করে 'কিছু' এবং এটি 'সম্পূর্ণ আলাদা কিছু' করে। কোন সংকলক সতর্কতা বা কিছুই। আপনার প্রোগ্রামটি নিঃশব্দে আগের চেয়ে সম্পূর্ণ আলাদা কিছু শুরু করে।

আপনি যখন কোনও নেমস্পেস ব্যবহার করেন আপনি এমন দৃশ্যের ঝুঁকি নিয়ে থাকেন, এ কারণেই লোকেরা নামের স্থান ব্যবহার করে অস্বস্তি বোধ করে। একটি নেমস্পেসে যত বেশি জিনিস, দ্বন্দ্বের ঝুঁকি তত বেশি, তাই লোকেরা stdঅন্য নামের জায়গাগুলির চেয়ে নেমস্পেস (সেই নামের জায়গার সংখ্যার কারণে) ব্যবহার করে আরও বেশি অস্বস্তি বোধ করতে পারে ।

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

— কেভিন
সূত্র
দ্বিতীয় দৃশ্যটি আমার জন্য চুক্তিটি করে। আবার কোনও নামস্থান নেই। হুডের নিচে সনাক্ত করা কার্যকরভাবে কার্যক্ষমতায় এ জাতীয় সূক্ষ্ম পরিবর্তনগুলি হতে পারে না।
— নিরাপদ_ম্লোক
13

একটি নেমস্পেস একটি নামকৃত সুযোগ। নেমস্পেসগুলি সম্পর্কিত ঘোষণাগুলি গোষ্ঠী করতে এবং পৃথক আইটেমকে পৃথক রাখতে ব্যবহার করা হয়। উদাহরণস্বরূপ, পৃথকভাবে দু'টি উন্নত গ্রন্থাগার বিভিন্ন আইটেমের উল্লেখ করতে একই নাম ব্যবহার করতে পারে তবে ব্যবহারকারী এখনও উভয় ব্যবহার করতে পারেন:

namespace Mylib{
    template<class T> class Stack{ /* ... */ };
    // ...
}

namespace Yourlib{
    class Stack{ /* ... */ };
    // ...
}

void f(int max) {
    Mylib::Stack<int> s1(max); // Use my stack
    Yourlib::Stack    s2(max); // Use your stack
    // ...
}

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

void f(int max) {
    using namespace Mylib; // Make names from Mylib accessible
    Stack<int> s1(max); // Use my stack
    Yourlib::Stack s2(max); // Use your stack
    // ...
}

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

উত্স: বাজরান স্ট্রাস্ট্রাপের সি ++ প্রোগ্রামিং ভাষার একটি সংক্ষিপ্তসার

— রোহন সিং
সূত্র
4
অত্যন্ত আকর্ষণীয় যে এই উত্তরটি যে উত্তর
— -২০ ... ভাইজার্ন স্ট্রোস্ট্রুপ -২০১ earned
@nyholku: দেখুন এই ।
— এসবিআই
10

একটি উদাহরণ যেখানে using namespace stdগণনার অস্পষ্টতার কারণে সংকলন ত্রুটি ছুড়ে দেয়, এটি আলগোরিদম লাইব্রেরিতেও একটি ফাংশন।

#include <iostream>

using namespace std;

int count = 1;
int main() {
    cout << count << endl;
}
— Nithin
সূত্র
2
::count--সমস্যা সমাধান. সাধারণত আপনার কাছে অন্য কোথাও স্ট্যান্ডের নেমস্পিড থেকে বেশি স্টাফ থাকবে, নেমস্পেসের নির্দেশিকা ব্যবহারের মাধ্যমে আপনার টাইপিং সাশ্রয় হতে পারে।
— পিএসকোকিক
এখানে আসল সমস্যাটি হ'ল সি ++ তে এখনও নামস্থান-কম গ্লোবাল রয়েছে। এটি, এবং সত্য যে 'এটি' পদ্ধতিগুলিতে অন্তর্নিহিত, এর ফলে আমি অনেকগুলি বাগ এবং সমস্যার কারণ এমনকি এগুলিও গণনা করতে পারি না, এমনকি সঠিক 'গণনা' পরিবর্তনশীলও। ;)
— আইকেন ড্রাম
9

এটি আপনার সফ্টওয়্যার বা প্রকল্পের কার্যকারিতা খারাপ করে না। আপনার উত্স কোডের শুরুতে নেমস্পেসের অন্তর্ভুক্তি খারাপ নয়। অন্তর্ভুক্তিusing namespace stdনির্দেশের আপনার প্রয়োজনীয়তা এবং আপনি সফ্টওয়্যার বা প্রকল্পের বিকাশ করার পদ্ধতি অনুসারে পরিবর্তিত হয়।

namespace stdC ++ স্ট্যান্ডার্ডের ফাংশন এবং ভেরিয়েবল রয়েছে। আপনি যখন প্রায়শই সি ++ স্ট্যান্ডার্ড ফাংশন ব্যবহার করবেন তখন এই নেমস্পেসটি কার্যকর।

যেমন এই পৃষ্ঠায় উল্লেখ করা হয়েছে :

নেমস্পেস স্টাডি ব্যবহার করে স্টেটমেন্টটি সাধারণত খারাপ অভ্যাস হিসাবে বিবেচিত হয়। এই বিবৃতিটির বিকল্প হ'ল স্কোপ অপারেটর (: :) ব্যবহার করে প্রত্যেকবার যখন আমরা কোনও প্রকার ঘোষণা করি তখন নামটি নির্দিষ্ট করে to

এবং এই মতামত দেখুন :

যখন আপনি নেমস্পেসের ভারী ব্যবহার করবেন এবং নিশ্চিত হন যে কোনও কিছুই সংঘর্ষে নেবে না তা নিশ্চিত হয়ে আপনার উত্স ফাইলে "নেমস্পেস স্টাডি" ব্যবহার করতে কোনও সমস্যা নেই।

কিছু লোক বলেছিল যে এটি using namespace stdআপনার উত্স ফাইলগুলিতে অন্তর্ভুক্ত করা একটি খারাপ অভ্যাস কারণ আপনি সেই নেমস্পেস থেকে সমস্ত ফাংশন এবং ভেরিয়েবলগুলি প্রার্থনা করছেন। আপনি যখন একই নামের সাথে একটি নতুন ফাংশনটি সংজ্ঞায়িত করতে চান namespace stdতবে এতে ফাংশনটি ওভারলোড হবে এবং এটি সংকলন বা সম্পাদন করার কারণে সমস্যা তৈরি করতে পারে। এটি আপনার প্রত্যাশার মতো সংকলন বা সম্পাদন করবে না।

যেমন এই পৃষ্ঠায় উল্লেখ করা হয়েছে :

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

...

এখন উন্নয়নের পরবর্তী পর্যায়ে, আমরা কাউটের আরও একটি সংস্করণ ব্যবহার করতে চাই যা "foo" নামে পরিচিত কিছু লাইব্রেরিতে কাস্টম প্রয়োগ করা হয় (উদাহরণস্বরূপ)

...

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

— CryogenicNeo
সূত্র
8

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

— ওয়াটসন ড
সূত্র
7

"কেন 'নেমস্পেস স্ট্যান্ড ব্যবহার করছি;' সি ++ এ খারাপ অভ্যাস হিসাবে বিবেচিত? "

আমি এটিকে অন্য উপায়ে রেখেছি: কেন পাঁচটি অতিরিক্ত অক্ষর টাইপ করা কারও দ্বারা জটিল হিসাবে বিবেচিত?

উদাহরণস্বরূপ বিবেচনা করুন সংখ্যাগত সফ্টওয়্যার একটি টুকরো লেখার। আমি কেন "গ্লোবাল নেমস্পেসকে" সাধারণ "স্টাড :: ভেক্টর" কে "ভেক্টর" এ কেটে যখন "ভেক্টর" সমস্যা ডোমেইনের অন্যতম গুরুত্বপূর্ণ ধারণাটি বোধ করি তা কেন দূষিত বিবেচনা করব?

— Solkar
সূত্র
19
এটি কেবল 5 অতিরিক্ত অক্ষর নয়; প্রতিটি সময় আপনি স্ট্যান্ডার্ড লাইব্রেরিতে যে কোনও অবজেক্টের প্রকারটি উল্লেখ করেন এর জন্য অতিরিক্ত পাঁচটি অক্ষর। কোনটি যদি আপনি খুব বেশি স্ট্যান্ডার্ড লাইব্রেরি ব্যবহার করেন তবে প্রায়শই হবে be সুতরাং এটি একটি আসল আকারের প্রোগ্রামে আরও হাজার হাজার অতিরিক্ত চরিত্রবাদী। সম্ভবত ভাষায় 'ব্যবহারের' নির্দেশনা যুক্ত করা হয়েছিল যাতে এটি ব্যবহার করা যায় ...
— জেরেমি ফ্রাইজনার
5
এটি প্রতিবার 5 টি অতিরিক্ত অক্ষর নয়, এটি 5 টি অক্ষর এবং সম্ভবত একটি মেনু টানতে এবং আপনার পছন্দের সম্পাদকের সন্ধান এবং প্রতিস্থাপনের জন্য একটি দম্পতি মাউস ক্লিক করে।
— ডেভওয়ালি
1
পঠনযোগ্যতার। cout << hex << setw(4) << i << endl;চেয়ে পড়তে সহজ হয়std::cout << std::hex << std::setw(4) << i << std::endl;
— oz1cz
16
এবং আরও খারাপ: std::map<std::string,std::pair<std::string,std::string>>তুলনায় ভয়াবহ map<string,pair<string,string>>।
— oz1cz
4
এটি একটি ভাল অনুশীলন হ'ল যেভাবেই আপনার এসটিএল কনটেইনারগুলি টাইপড করা উচিত: স্ট্যান্ডার্ড :: আসলেই কিছু আসে যায় না। এবং সি ++ 11 আমাদের জন্য অটো কীওয়ার্ড এনেছিল যা পুনরায় আইট্রেটারগুলি ব্যবহার করার সময় জিনিসগুলিকে আরও সহজ করে তোলে।
— জাজলিন
7

আমি অন্যদের সাথে একমত - এটি নাম সংঘর্ষ, অস্পষ্টতা জিজ্ঞাসা করছে এবং তারপরে সত্যটি কম স্পষ্ট হয়। আমি এর ব্যবহার দেখতে পাচ্ছি using, তবে আমার ব্যক্তিগত পছন্দটি এটি সীমাবদ্ধ করা। আমি আরও দৃ pointed়ভাবে বিবেচনা করব কিছু অন্যরা কী বলেছিল:

আপনি যদি একটি ফাংশন নাম মোটামুটি ভাল নাম হতে পারে এটি করতে চান, কিন্তু আপনি শুধুমাত্র এটা খুঁজে পেতে চান stdনামস্থান (অথবা বিপরীত - আপনি সব কল যে পরিবর্তন করতে চান না নামস্থানে std, নামস্থান X, ...), তাহলে আপনি কীভাবে এটি করার প্রস্তাব করবেন?

আপনি এটি করার জন্য একটি প্রোগ্রাম লিখতে পারেন, তবে আপনার প্রকল্পটি বজায় রাখতে কোনও প্রোগ্রাম লেখার চেয়ে নিজের প্রকল্পে নিজেই সময় কাটানো ভাল হবে না?

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

উপরের সাথে কিছুটা সম্পর্কিত এবং অন্যরা কী বলেছে এটি অন্য একটি জিনিস আছে। যদিও এটি খারাপ অনুশীলন হতে পারে, আমি মাঝে মাঝে std::nameস্ট্যান্ডার্ড লাইব্রেরি সংস্করণ এবং প্রোগ্রাম-নির্দিষ্ট প্রয়োগের জন্য নাম সংরক্ষণ করি । হ্যাঁ, প্রকৃতপক্ষে এটি আপনাকে কামড়াতে পারে এবং আপনাকে কঠোর কামড় দিতে পারে, তবে এটিই নেমে আসে যে আমি এই প্রকল্পটি শুরু থেকেই শুরু করেছি এবং আমি এর জন্য কেবলমাত্র প্রোগ্রামার। উদাহরণ: আমি ওভারলোড করে std::stringএটিকে কল করি string। আমার সহায়ক সংযোজন রয়েছে। ছোট অংশের নামগুলির প্রতি আমার সি এবং ইউনিক্স (+ লিনাক্স) প্রবণতার কারণে আমি এটি কিছু অংশে করেছি।

তদতিরিক্ত, আপনার নামের স্থানের উপাধি থাকতে পারে। এখানে এটি কার্যকর যেখানে এর উল্লেখ নাও করা যেতে পারে তার উদাহরণ রয়েছে। আমি সি ++ 11 স্ট্যান্ডার্ড এবং বিশেষত libstdc ++ ব্যবহার করি। ঠিক আছে, এটির সম্পূর্ণ std::regexসমর্থন নেই। অবশ্যই, এটি সংকলন করে তবে এটি প্রোগ্রামারের শেষদিকে ত্রুটি হওয়ার প্রান্তে এটি ব্যতিক্রম করে। তবে তা বাস্তবায়নের অভাব।

সুতরাং আমি এখানে এটি কীভাবে সমাধান করেছি। বুস্টের রেজেক্স ইনস্টল করুন এবং এটিতে লিঙ্ক করুন Then তারপরে, আমি নিম্নলিখিতটিগুলি করি যাতে যখন libstdc ++ এটি সম্পূর্ণরূপে বাস্তবায়িত হয় তখন আমার কেবল এই ব্লকটি সরিয়ে নেওয়া দরকার এবং কোডটি একই থাকবে:

namespace std
{
    using boost::regex;
    using boost::regex_error;
    using boost::regex_replace;
    using boost::regex_search;
    using boost::regex_match;
    using boost::smatch;
    namespace regex_constants = boost::regex_constants;
}

এটি একটি খারাপ ধারণা কিনা তা নিয়ে আমি তর্ক করব না। তবে আমি যুক্তি দিয়ে বলব যে এটি আমার প্রকল্পের জন্য এটি পরিষ্কার রাখে এবং একই সাথে এটি নির্দিষ্ট করে তোলে: সত্য, আমাকে বুস্ট ব্যবহার করতে হবে, তবে আমি এটি লাইবস্টডিসি ++ এর মতো ব্যবহার করব eventually হ্যাঁ, আপনার নিজের প্রকল্প শুরু করা এবং একেবারে শুরুতে একটি স্ট্যান্ডার্ড (...) দিয়ে শুরু করা রক্ষণাবেক্ষণ, বিকাশ এবং প্রকল্পের সাথে জড়িত সমস্ত কিছুতে সহায়তা করার সাথে অনেক দীর্ঘ পথ চলে যায়!

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

যেমনটি হ'ল, আমি এখনও সি এর প্রতি খুব পক্ষপাতী এবং সি ++ এর বিরুদ্ধে পক্ষপাতদুষ্ট। বিশদ বিবরণ, আমি যা কাজ করি তার বেশিরভাগই সি-তে ফিট করে (তবে এটি একটি ভাল অনুশীলন এবং নিজেকে একটি করে গড়ে তোলার একটি ভাল উপায় ছিল another অন্য ভাষা শেখা এবং খ। অবজেক্ট / শ্রেণি / ইত্যাদির বিরুদ্ধে কম পক্ষপাতদুষ্ট না হওয়ার চেষ্টা করুন যা সম্ভবত আরও ভাল বর্ণিত হয়েছে) যতটা নিবিড়, কম অহংকারী এবং আরও গ্রহণযোগ্য) তবে দরকারীটি হ'ল কিছু যা ইতিমধ্যে পরামর্শ দিয়েছিল: আমি প্রকৃতপক্ষে তালিকাটি ব্যবহার করি (এটি মোটামুটি জেনারিক, তাই না?), এবং দু'জনের নাম সারণি করুন (একই জিনিস) যা যদি আমি করি তবে নাম সংঘর্ষের কারণ হয়ে দাঁড়ায় using namespace std;, এবং তাই সে লক্ষ্যে আমি নির্দিষ্ট হওয়া পছন্দ করি, নিয়ন্ত্রণে এবং জেনেও যে আমি যদি এটি মানক ব্যবহারের উদ্দেশ্যে করি তবে আমাকে এটি নির্দিষ্ট করতে হবে। সহজভাবে রাখুন: অনুমান করার অনুমতি নেই।

এবং বুস্টের রেজেক্সের অংশ তৈরির জন্য std। আমি ভবিষ্যতের সংহতকরণের জন্য এটি করি এবং - আবারও, আমি পুরোপুরি স্বীকার করি এটি পক্ষপাতিত্ব - আমি মনে করি না এটি এতটা কুৎসিত boost::regex:: ...। আসলে, এটি আমার জন্য অন্য জিনিস। সি ++ তে এমন অনেকগুলি বিষয় রয়েছে যা আমি এখনও চেহারা এবং পদ্ধতিগুলিতে পুরোপুরি গ্রহণ করতে পারি নি (অন্য উদাহরণ: ভেরিয়েডিক টেম্পলেট বনাম ভার আর্গুমেন্টগুলি [যদিও আমি স্বীকার করি যে ভেরিয়েডিক টেম্পলেটগুলি খুব দরকারী!])। এমনকি আমি এগুলি গ্রহণ করি তাও কঠিন ছিল এবং তাদের সাথে আমার এখনও সমস্যা আছে।

— পিটার মর্টেনসেন
সূত্র
1
stdনেমস্পেস প্রসারিত করা অনির্ধারিত আচরণ এবং এভাবে কখনও করা উচিত নয়।
— tamre
7

আমার অভিজ্ঞতা থেকে, যদি আপনার একাধিক লাইব্রেরি থাকে যা ব্যবহার করে বলে cout, তবে অন্য কোনও উদ্দেশ্যে আপনি ভুলটি ব্যবহার করতে পারেন cout।

উদাহরণস্বরূপ, যদি আমি টাইপ করুন, using namespace std;এবং using namespace otherlib;এবং মাত্র টাইপ cout(যা উভয় হতে হবে), বদলে std::cout(অথবা 'otherlib::cout'), আপনি ভুল ব্যবহার পারে, এবং ত্রুটি পেতে। এটি ব্যবহার করতে অনেক বেশি কার্যকর এবং দক্ষ std::cout।

— ইঞ্জিন দেব
সূত্র
6

অযোগ্য আমদানীকৃত শনাক্তকারীদের সাথে সনাক্তকারী কোথায় ঘোষিত হয়েছে তা খুঁজে পেতে আপনার গ্রেপের মতো বাহ্যিক অনুসন্ধান সরঞ্জামগুলি প্রয়োজন need এটি প্রোগ্রামের সঠিকতা সম্পর্কে যুক্তি আরও শক্ত করে তোলে।

— আগস্ট কার্লস্ট্রোম
সূত্র
6

এটি কোথায় অবস্থিত তার উপর নির্ভর করে। যদি এটি একটি সাধারণ শিরোনাম হয় তবে আপনি বিশ্বব্যাপী নেমস্পেসে মার্জ করে নেমস্পেসের মান হ্রাস করছেন। মনে রাখবেন, এটি মডিউল গ্লোবালগুলি তৈরির একটি ঝরঝরে উপায় হতে পারে।

— MathGladiator
সূত্র
6

এটি একটি খারাপ অনুশীলন, প্রায়শই বিশ্বব্যাপী নেমস্পেস দূষণ হিসাবে পরিচিত। সমস্যাগুলি দেখা দিতে পারে যখন একাধিক নেমস্পেসে স্বাক্ষর সহ একই ফাংশনটির নাম থাকে, তখন কোনটি কল করতে হবে তা নির্ধারণ করার জন্য সংকলকটির পক্ষে অস্পষ্ট হবে এবং যখন আপনি আপনার ফাংশন কলের মতো নাম স্থানটি নির্দিষ্ট করে রাখবেন তখন এগুলি এড়ানো যেতে পারে std::cout। আশাকরি এটা সাহায্য করবে. :)

— adn.911
সূত্র
5

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

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

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

— নুনিও গেটিট
সূত্র
কতগুলি লোক কার্যকর স্ট্যান্ডার্ড লাইব্রেরি ফাংশনগুলি ( <algorithm>উদাহরণস্বরূপ, জিনিসগুলি পুনরায় উদ্ভাবন করা ) সম্পর্কে অজানা বলে মনে করা হচ্ছে , এটি একই রকম লোকেরা নির্ভরযোগ্যভাবে সেই শনাক্তকারীদের এড়াতে পারে তা কল্পনা করার মতো কিছুটা মনে হয়। আপনার নিজের কোডটি দেখুন এবং আমাকে বলুন আপনার কখনও ভেরিয়েবল বা ফাংশন বলা হয় না count। অথবা distance, অথবা log, destroy, launch, visit, beta, sample, messages, clamp, erase, copy, modulus, left, ইত্যাদি সব শনাক্তকারী মধ্যে উল্লেখ করতে এখনো stdযে আপনার কোড ভঙ্গ করবে যখন সি ++ 35 আসে আউট ...
— টবি Speight
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.