অটো কি সি ++ কোড বোঝা আরও শক্ত করে?

Question

আমি হার্ব সটারের একটি সম্মেলন দেখেছি যেখানে তিনি প্রতিটি সি ++ প্রোগ্রামারকে ব্যবহার করতে উত্সাহিত করেন auto।

কিছু সময় আগে আমাকে সি # কোড পড়তে varহয়েছিল যেখানে ব্যাপকভাবে ব্যবহৃত হয়েছিল এবং কোডটি বোঝা খুব কঠিন ছিল — প্রতিবার varব্যবহার করা হত আমাকে ডান পাশের ফেরতের ধরণটি পরীক্ষা করতে হয়েছিল। কখনও কখনও একাধিকবার, কারণ আমি ভেরিয়েবলের ধরণটি কিছুক্ষণ পরে ভুলে গেছি!

আমি জানি যে সংকলকটি টাইপটি জানে এবং আমার এটি লিখতে হবে না, তবে এটি সর্বজনস্বীকৃত যে আমাদের প্রোগ্রামারদের জন্য কোড লিখতে হবে, সংকলকগুলির জন্য নয়।

আমি আরও জানি যে এটি আরও সহজ:

auto x = GetX();

চেয়ে:

someWeirdTemplate<someOtherVeryLongNameType, ...>::someOtherLongType x = GetX();

তবে এটি কেবল একবার লেখা হয় এবং GetX()টাইপ কী তা বোঝার জন্য রিটার্ন টাইপটি বহুবার পরীক্ষা xকরা হয়।

এটি আমাকে অবাক করে দিয়েছে made autoসি ++ কোড বুঝতে কি আরও কঠিন করে তোলে?

Comments

আপনার কি প্রতিবার রিটার্নের ধরণটি সত্যিই পরীক্ষা করা দরকার ? কোডটি থেকে ধরণটি পরিষ্কার হয় না কেন? autoইতিমধ্যে যখন পড়া খুব শক্ত হয়, অর্থাত্ ফাংশনগুলি খুব দীর্ঘ হয়, ভেরিয়েবলগুলি খুব ভালভাবে নামকরণ করা হয় না তখন প্রায়শই জিনিসগুলি পড়তে আরও শক্ত করে তোলে etc.

— আর মার্টিনহো ফার্নান্দেস

"আর্ট" ব্যবহার autoকরা কখন ব্যবহার করবেন তা নির্ধারণ করার মতো typedef। এটি কখন বাধা সৃষ্টি করে এবং কখন সহায়তা করে তা নির্ধারণ করা আপনার উপর নির্ভর করে।

— অহেনডারসন

আমি ভেবেছিলাম আমারও একই সমস্যা আছে তবে আমি বুঝতে পেরেছিলাম যে প্রকারগুলি না জেনে আমি কেবল কোডটি বুঝতে পারি। উদাহরণস্বরূপ: "অটো আইডিএক্স = get_index ();" সুতরাং আইডিএক্স হ'ল একটি সূচক ধারণ করে index সঠিক ধরণটি কী, বেশিরভাগ ক্ষেত্রে এটি বেশ অপ্রাসঙ্গিক।

— প্লাজমাএইচএইচ

সুতরাং লিখবেন না auto x = GetX();, এর চেয়ে আরও ভাল নাম বাছাই করুন xযা আপনাকে সেই নির্দিষ্ট প্রসঙ্গে কী করে তা বলে দেয় ... এটি প্রায়শই যাইহোক এর ধরণের চেয়ে বেশি কার্যকর।

— জোনাথন Wakely

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

— সিএ ম্যাককান

Answer 1

সংক্ষিপ্ত উত্তর: আরও সম্পূর্ণরূপে, আমার বর্তমান মতামতটি autoহ'ল আপনি autoডিফল্টরূপে ব্যবহার করা উচিত যদি না আপনি স্পষ্টভাবে কোনও রূপান্তর চান। (সামান্য আরও স্পষ্টভাবে, "... যদি না আপনি স্পষ্টভাবে কোনও ধরণের প্রতিশ্রুতিবদ্ধ না করতে চান তবে প্রায়শই এটি কারণ আপনি কোনও রূপান্তর চান" ")

দীর্ঘ উত্তর এবং যুক্তি:

autoকেবলমাত্র যখন আপনি প্রকৃতপক্ষে কোনও প্রকারের কাছে স্পষ্টভাবে প্রতিশ্রুতিবদ্ধ করতে চান কেবল তখনই একটি স্পষ্টতাল টাইপ লিখুন ( যার অর্থ প্রায় সর্বদা অর্থ আপনি স্পষ্টভাবে সেই ধরণের রূপান্তর পেতে চান। আমার মাথার শীর্ষে, আমি দুটি প্রধান কেস স্মরণ করছি:

• (প্রচলিত) initializer_listযে auto x = { 1 };আশ্চর্যতা হ্রাস করে initializer_list। আপনি যদি না চান initializer_listতবে টাইপটি বলুন - অর্থাত্, স্পষ্টভাবে রূপান্তরের জন্য জিজ্ঞাসা করুন।
• (বিরল) এক্সপ্রেশন টেম্পলেটগুলির ক্ষেত্রে যেমন auto x = matrix1 * matrix 2 + matrix3;কোনও সহায়ক বা প্রক্সি প্রকারটিকে প্রোগ্রামারের কাছে দৃশ্যমান নয় বোঝায় capt অনেক ক্ষেত্রে, এই ধরণটি ক্যাপচার করার জন্য এটি সূক্ষ্ম এবং সৌম্য, তবে কখনও কখনও আপনি যদি সত্যিই এটি ধসে পড়তে এবং গণনাটি করতে চান তবে টাইপটি বলুন - অর্থাত্, আবার স্পষ্টভাবে রূপান্তরের জন্য জিজ্ঞাসা করুন।

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

• সঠিকতা:auto গ্যারান্টি ব্যবহার করে আপনি সঠিক ধরণ পাবেন। প্রবাদটি যেমন চলেছে, আপনি নিজেকে পুনরাবৃত্তি করেন (টাইপটি রিডানড্রেটিভলি বলে), আপনি মিথ্যা বলতে পারবেন এবং মিথ্যা বলবেন (ভুল হয়ে উঠবেন)। এখানে একটি সাধারণ উদাহরণ রয়েছে: void f( const vector<int>& v ) { for( /*…*- এই মুহুর্তে, আপনি যদি পুনরাবৃত্তকারীর ধরণটি স্পষ্টভাবে লিখেন, আপনি লিখতে মনে রাখতে চান const_iterator(আপনি কি?), তবে autoঠিক এটি পেয়ে যায়।
• Maintainability এবং বলিষ্ঠতার: ব্যবহার auto, পরিবর্তন মুখে আপনার কোড আরো জোরালো করে তোলে কারণ যখন অভিব্যক্তি ধরন পরিবর্তন, autoসঠিক ধরনের সমাধান করতে চলতে থাকবে। পরিবর্তে যদি আপনি একটি সুস্পষ্ট ধরণের প্রতিশ্রুতিবদ্ধ হন তবে এক্সপ্রেশনটির ধরণ পরিবর্তন করা যখন নূতন প্রকারটি পুরানো প্রকারে রূপান্তরিত হয় তখন অকারণে বিল্ড ব্রেক হয়ে যায় যখন নতুন প্রকারটি পুরানো প্রকারের মতো কাজ করে তবে পুরানোতে রূপান্তরিত হয় না ধরন (উদাহরণস্বরূপ, যখন আপনি একটি পরিবর্তন mapএকটি থেকে unordered_map, যা সবসময় জরিমানা যদি আপনি উপর নির্ভর করছে না, ব্যবহার autoআপনার iterators জন্য আপনাকে অঙ্গীভূতভাবে থেকে সুইচ করব map<>::iteratorকরার unordered_map<>::iterator, কিন্তু ব্যবহারmap<>::iterator সর্বত্র স্পষ্টতই এর অর্থ হ'ল আপনি কোনও মেকানিকাল কোড ফিক্সের রিপলে আপনার মূল্যবান সময় নষ্ট করবেন, যদি না কোনও ইন্টার্ন চলতে থাকে এবং আপনি সেগুলি সম্পর্কে বিরক্তিকর কাজটি বন্ধ করতে পারেন)।
• পারফরম্যান্স: যেহেতু autoগ্যারান্টি দেয় যে কোনও অন্তর্নিহিত রূপান্তর ঘটবে না, এটি ডিফল্টরূপে আরও ভাল পারফরম্যান্সের গ্যারান্টি দেয়। এর পরিবর্তে আপনি যদি টাইপটি বলে থাকেন এবং এর জন্য কোনও রূপান্তর প্রয়োজন, আপনি প্রায়শই নিঃশব্দে রূপান্তরটি পাবেন যা আপনি প্রত্যাশা করেছিলেন বা না করেছিলেন।
• ব্যবহারযোগ্যতা: ব্যবহার autoযেমন lambdas এবং টেমপ্লেট সাহায্যকারী হিসাবে হার্ড-টু-বানান এবং অকথ্য ধরনের, পুনরাবৃত্তিমূলক অবলম্বন সংক্ষিপ্ত জন্য, আপনার শুধুমাত্র ভাল বিকল্প decltypeএক্সপ্রেশন বা মত কম-সাশ্রয়ী indirections std::function।
• সুবিধা: এবং হ্যাঁ, autoটাইপিং কম is আমি সম্পূর্ণরূপে শেষটি উল্লেখ করেছি কারণ এটি পছন্দ করার একটি সাধারণ কারণ, তবে এটি এটি ব্যবহার করার সবচেয়ে বড় কারণ নয়।

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

হ্যাঁ, এখন এই সম্পর্কে একটি গটডাব্লু রয়েছে।

Comments

আমি রূপান্তর চাইলেও আমি অটোকে দরকারী মনে করি। এটা আমার স্পষ্টভাবে টাইপ পুনরাবৃত্তি ছাড়া একটি রূপান্তরের জন্য জিজ্ঞাসা করতে অনুমতি দেয়: auto x = static_cast<X>(y)। এর static_castফলে এটি পরিষ্কার হয়ে যায় যে রূপান্তরটি উদ্দেশ্যমূলক এবং এটি রূপান্তর সম্পর্কে সংকলক সতর্কতাগুলি এড়িয়ে চলে। সাধারণত সংকলক সতর্কতা এড়ানো ভাল না, তবে আমি যখন লেখার সময় সাবধানতার সাথে বিবেচনা করেছি এমন রূপান্তর সম্পর্কে সতর্কতা না পেয়ে আমি ঠিক আছি static_cast। যদিও এখনই কোনও সতর্কতা না থাকলে আমি এটি করব না তবে প্রকারগুলি বিপজ্জনক উপায়ে পরিবর্তিত হলে ভবিষ্যতে আমি সতর্কতা পেতে চাই।

— বজরেক হামারশোল্ট রাউন

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

— Xoo

"অটো গ্যারান্টি ব্যবহার করে আপনি সঠিক ধরণ পাবেন" " মোটেও সত্য নয়। এটি কেবলমাত্র গ্যারান্টি দেয় যে আপনি আপনার কোডের অন্য কোনও অংশ দ্বারা নির্ধারিত ধরণটি পাবেন। এটি সঠিক কিনা বা না তা পুরোপুরি অস্পষ্ট যখন আপনি এটিকে পিছনে লুকিয়ে রাখেন auto।

— অরবিটে মার্চীনতা রেস

আমি সত্যিই আশ্চর্য হয়েছি যে কেউ আইডিই সম্পর্কে চিন্তা করে না ... এমনকি আধুনিক আইডিইগুলি autoভেরিয়েবলের ক্ষেত্রে ক্লাস / স্ট্রাক্ট সংজ্ঞায় সঠিকভাবে জাম্পিং সমর্থন করে না , তবে প্রায় সবগুলিই স্পষ্টত ধরণের স্পেসিফিকেশন সহ এটি সঠিকভাবে করে। কেউ আইডিই ব্যবহার করে না? প্রত্যেকে কেবল ইন / ফ্লোট / বুল ভেরিয়েবল ব্যবহার করে? প্রত্যেকে স্ব-ডকুমেন্টেড শিরোনামের পরিবর্তে গ্রন্থাগারগুলির জন্য বাহ্যিক ডকুমেন্টেশন পছন্দ করে?

— avtomaton

যে গটডাব্লু: herbsutter.com/2013/08/12/… আমি দেখতে পাচ্ছি না যে " আরম্ভকারী_লিস্ট সারপ্রাইজ" কীভাবে অবাক হয়; প্রায় ধনুর্বন্ধনী =RHS অন্য কোন ব্যাখ্যা দ্বারা অনেক মানে হয় না (বার করে রেখেছিলেন Init-তালিকা, কিন্তু আপনি জানেন যে কি আপনি initialising হয়েছেন, যা দিয়ে একটি বিরোধাভাস প্রয়োজন auto)। এক যে হয় বিস্ময়কর auto i{1}এছাড়াও deducing initializer_listনা implying সত্ত্বেও এই braced Init-তালিকা নেওয়া বরং এই মত প্রকাশের গ্রহণ করা এবং তার টাইপ ব্যবহার ... কিন্তু আমরা পেতে initializer_listখুব। ধন্যবাদ, সি ++ 17 এগুলি সব ঠিক করে দেয়।

— আন্ডারস্কোর_১

Answer 2

এটি কেস বাই কেস পরিস্থিতি।

এটি কখনও কখনও কোড বোঝা শক্ত করে তোলে, কখনও কখনও না। যেমন ধরুন:

void foo(const std::map<int, std::string>& x)
{
   for ( auto it = x.begin() ; it != x.end() ; it++ )
   { 
       //....
   }
}

স্পষ্টভাবে সহজবোধ্য এবং স্পষ্টভাবে সহজ প্রকৃত পুনরুক্তিকারীর ঘোষণা চেয়ে লিখতে।

আমি আপাতত সি ++ ব্যবহার করছি, তবে আমি গ্যারান্টি দিতে পারি যে এটির আমার প্রথম শটে একটি সংকলক ত্রুটি পেয়েছি কারণ আমি ভুলে গিয়েছিলাম const_iteratorএবং প্রাথমিকভাবে iterator...

আমি এটি এর মতো মামলার জন্য ব্যবহার করব, তবে যেখানে এটি প্রকৃতপক্ষে (আপনার পরিস্থিতিটির মতো) প্রচ্ছন্ন হয় না, তবে এটি নিখুঁতভাবে বিষয়গত।

Comments

যথাযথভাবে। হেক প্রকারের বিষয়ে যত্নশীল। এটি একটি পুনরাবৃত্তি। আমি টাইপটির বিষয়ে চিন্তা করি না, কেবল আমার জানা দরকার যে এটি পুনরাবৃত্তি করতে ব্যবহার করতে পারি।

— আর মার্টিনহো ফার্নান্দেস

+1 টি। এমনকি আপনি যদি প্রকারটির নাম দিয়েছিলেন, আপনি এটির নাম রাখবেন std::map<int, std::string>::const_iterator, তবে এটি নামটি যাহাই হউক না কেন টাইপ সম্পর্কে আপনাকে অনেক কিছু বলে দেয় এমন নয়।

— স্টিভ জেসোপ

@SteveJessop: এটা আমাকে অন্তত দুটি জিনিস বলে: চাবিকাঠি int, এবং মান std::string। :)

— নওয়াজ

@ নাওয়াজ: এবং আপনি it->secondএটি বরাদ্দ করতে পারবেন না কারণ এটি কনস্টেট ইটারেটর । এর সমস্ত তথ্য পূর্ববর্তী লাইনে কী রয়েছে তার পুনরাবৃত্তি const std::map<int, std::string>& x। একাধিকবার কথা বলা মাঝেমধ্যে আরও ভালভাবে অবহিত করে তবে কোনওভাবেই এটি একটি সাধারণ নিয়ম নয় :-)

— স্টিভ জেসোপ

টিবিএইচ আমি for (anX : x)এটিকে আরও স্পষ্ট করে তুলতে পছন্দ করব আমরা কেবল পুনরাবৃত্তি করছি x। আপনি যখন কনটেইনারটি সংশোধন করছেন তখন আপনার যখন xconst&

— ইটারেটর

Answer 3

এটি অন্যভাবে দেখুন। তুমি কি লিখ:

std::cout << (foo() + bar()) << "\n";

বা:

// it is important to know the types of these values
int f = foo();
size_t b = bar();
size_t total = f + b;

std::cout << total << "\n";

কখনও কখনও এটি স্পষ্টভাবে টাইপ বানান সাহায্য করে না।

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

কখনও কখনও ধরণের স্পষ্ট করে দেওয়া দরকারী হতে পারে:

// seems legit    
if (foo() < bar()) { ... }

বনাম

// ah, there's something tricky going on here, a mixed comparison
if ((unsigned int)foo() < bar()) { ... }

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

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

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

Comments

+1 autoআপনাকে নামবিহীন বা অবিবেচনাপ্রযুক্ত প্রকারের সাথে নামযুক্ত ভেরিয়েবলগুলি তৈরি করতে দেয়। অর্থপূর্ণ নামগুলি কার্যকর হতে পারে।

— মনকারসে

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

— কৌতূহলী

Answer 4

আইএমও, আপনি এটিকে বিপরীতে বেশ কিছুটা দেখছেন।

এটি এমন autoকোডের দিকে নিয়ে যাওয়ার বিষয় নয় যা অপঠনযোগ্য বা আরও কম পাঠযোগ্য। এটি প্রত্যাশার বিষয় যে প্রত্যাবর্তনের মূল্যের জন্য একটি সুস্পষ্ট প্রকারের বিষয়টি নিশ্চিত হওয়া উচিত যে এটি (স্পষ্টতই) নির্দিষ্ট কোন ফাংশন দ্বারা কোন প্রকারটি ফিরে আসবে তা পরিষ্কার নয়।

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

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

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

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

Answer 5

আমি সাধারণ ব্যবহারের জন্য অটো অপছন্দ করার বিভিন্ন কারণ রয়েছে:

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

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

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

auto bThreadOK = চেকথ্রেডহেলথ ();

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

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

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

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

3. প্রাথমিকভাবে লেখার সময় কোডটি টাইপ করা প্রোগ্রামিংয়ের সর্বাধিক সময় ব্যয়কারী অংশ নয়। হ্যাঁ, অটো প্রাথমিকভাবে কিছু কোড লেখা দ্রুত করে তোলে। অস্বীকৃতি হিসাবে, আমি> 100 ডাব্লুপিএম টাইপ করি, তাই এটি অন্যের মতো আমাকে বিরক্ত করে না। তবে আমাকে যদি কেবল সমস্ত দিনই নতুন কোড লিখতে হত তবে আমি একজন খুশি ক্যাম্পার হব be প্রোগ্রামিংয়ের বেশিরভাগ সময় ব্যয়কারী অংশটি হ'ল হার্ড-টু-প্রজনন, কোডে এজ-কেস বাগগুলি নির্ণয় করা হয় যা প্রায়শই সূক্ষ্ম অ-সুস্পষ্ট সমস্যার ফলস্বরূপ - যেমন অটো ব্যবহারের ধরণের অতিরিক্ত ব্যবহার প্রবর্তন হতে পারে (রেফারেন্স বনাম অনুলিপি, স্বাক্ষরিত বনাম স্বাক্ষরযুক্ত, ভাসমান বনাম ইন্ট, বুল বনাম পয়েন্টার ইত্যাদি)।

এটি আমার কাছে স্পষ্ট বলে মনে হয় যে অটো প্রাথমিকভাবে স্ট্যান্ডার্ড লাইব্রেরি টেম্পলেট ধরণের সহিত ভয়ানক বাক্য গঠনের জন্য একটি কার্যকারণ হিসাবে প্রবর্তিত হয়েছিল। লোকেদের সাথে ইতিমধ্যে পরিচিত টেম্পলেট সিনট্যাক্সটি ঠিক করার চেষ্টা করার পরিবর্তে - যা বিদ্যমান কোডটি ভেঙে দিতে পারে তার কারণে এটি করা প্রায় অসম্ভব হতে পারে - মূলত সমস্যাটি লুকিয়ে রাখে এমন একটি কীওয়ার্ড যুক্ত করুন। মূলত যাকে আপনি "হ্যাক" বলতে পারেন।

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

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

Comments

আপনি এটি পেরেক দিয়েছিলেন। আমি যদি এটি +2 দিতে পারি

— 7:53

একটি ভাল "সতর্কতা অবলম্বন করা উচিত" -স্বত্বক। @ মাস্টার: এটি আছে।

— প্রতিলিপি 9

আমি এক আরো উপযোগী ক্ষেত্রে পাওয়া যায়: auto something = std::make_shared<TypeWithLongName<SomeParam>>(a,b,c);। :-)

— নোটলিস্ট

Answer 6

হ্যাঁ, আপনি যদি ব্যবহার না করেন তবে আপনার ভেরিয়েবলের ধরণটি আরও সহজ করে তোলে auto। প্রশ্ন হলো, আপনি কি প্রয়োজন কোড পড়তে আপনার পরিবর্তনশীল ধরণ জানেন কিভাবে? কখনও কখনও উত্তর হ্যাঁ, কখনও না হবে। উদাহরণস্বরূপ, ক এর কাছ থেকে পুনরুক্তি করার সময় std::vector<int>, আপনার কি এটি জানা উচিত যে এটি একটি std::vector<int>::iteratorবা auto iterator = ...;যথেষ্ট হবে? যে কেউ প্রত্যাহকের সাথে যা করতে চায় তার সবকিছুই এটি পুনরুক্তিকারী দ্বারা দেওয়া হয় - প্রকারটি বিশেষত কী তা বিবেচ্য নয়।

autoযখন আপনার কোডটি পড়া আরও কঠিন করে না তখন এই পরিস্থিতিতে ব্যবহার করুন ।

Answer 7

ব্যক্তিগতভাবে আমি autoকেবল তখনই ব্যবহার করি যখন এটি প্রোগ্রামারটির পক্ষে একেবারে স্পষ্ট।

উদাহরণ 1

std::map <KeyClass, ValueClass> m;
// ...
auto I = m.find (something); // OK, find returns an iterator, everyone knows that

উদাহরণ 2

MyClass myObj;
auto ret = myObj.FindRecord (something)// NOT OK, everyone needs to go and check what FindRecord returns

Comments

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

— আর মার্টিনহো ফার্নান্দেস

ঠিক আছে, এখন এটি কিছুটা ভাল। আমি এখনও দেখতে পাই যে ভেরিয়েবলটির নাম খারাপভাবে দেওয়া হয়েছে, যদিও এটি এখনও ব্যথা করে। আপনি লেখার জন্য auto record = myObj.FindRecord(something)এটি স্পষ্ট হবে যে চলক প্রকারটি রেকর্ড ছিল। বা এর নামকরণ করা itবা এর অনুরূপ করা এটি পরিষ্কার করে দেবে এটি একটি পুনরাবৃত্তিকে ফেরত দেয়। মনে রাখবেন, আপনি ব্যবহার না করলেও auto, সঠিকভাবে ভেরিয়েবলটির নামকরণের অর্থ হ'ল ফাংশনের যে কোনও জায়গা থেকে প্রকারটি দেখার জন্য আপনাকে ঘোষণাপত্রটিতে ফিরে ঝাঁপিয়ে পড়ার দরকার নেই । আমি আমার ডাউনটোটটি সরিয়েছি কারণ উদাহরণটি এখন সম্পূর্ণ স্ট্রোম্যান নয়, তবে আমি এখানে তর্কটি কেনি না।

— আর মার্টিনহো ফার্নান্দেস

@ আর.মার্টিনহো ফার্নান্দেসে যুক্ত করার জন্য: প্রশ্নটি হল, এখন "রেকর্ড" হ'ল আসলে কী এখন গুরুত্বপূর্ণ? আমার মনে হয় এটি আরও গুরুত্বপূর্ণ যে এটি একটি রেকর্ড, প্রকৃত অন্তর্নিহিত আদিম ধরণের আরেকটি বিমূর্ত স্তর .. সুতরাং অটো ছাড়া সম্ভবত MyClass::RecordTy record = myObj.FindRecord (something)

— কোনওটি

@ পাওল ২৩: অটো বনাম ধরণের বিপরীতে কী ব্যবহার করা আপনার পক্ষে লাভ করে তা যদি আপনার একমাত্র আপত্তি হয় তবে "এটি কীভাবে ব্যবহার করতে হয় তা আমি জানি না"। হয় আপনাকে যেকোন উপায়ে এটি সন্ধান করে।

— GManNickG

@GManNickG এটি আমাকে গুরুত্বহীনতার সঠিক ধরণের কথা বলে।

— পল23

Answer 8

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

জটিল টেম্পলেট ধরণের ক্ষেত্রে এটি বিশেষত সত্য। এখানে একটি সরলীকৃত এবং স্বীকৃত উদাহরণ। কোনটি বোঝা সহজ?

for( std::map<std::pair<Foo,Bar>, std::pair<Baz, Bot>, std::less<BazBot>>::const_iterator it = things_.begin(); it != things_.end(); ++it )

.. বা ...

for( auto it = things_.begin(); it != things_.end(); ++it )

কেউ কেউ বলবে দ্বিতীয়টি বোঝা সহজ, অন্যেরা প্রথমটি বলতে পারে। তবুও অন্যরা বলতে পারেন যে একটি কৃত্রিম ব্যবহার autoএটি প্রোগ্রামারদের ডাম্পিং ডাউনগুলিতে অবদান রাখতে পারে, তবে এটি অন্য গল্প।

Comments

+1 হাহা, প্রত্যেকে std::mapজটিল টেম্পলেট যুক্তিগুলির সাথে উদাহরণ উপস্থাপন করছে ।

— নওয়াজ

@ নাওয়াজ: পাগল-দীর্ঘ টেম্পলেট নাম ব্যবহার করে mapএস ব্যবহার করা সহজ । :)

— জন ডিবলিং

@ নাওয়াজ: তবে আমি অবাক হয়েছি কেন তখন কেন কেউ আরও ভাল এবং আরও বেশি পঠনযোগ্য বিকল্প হিসাবে লুপের ভিত্তিতে পরিসর নিয়ে আসছেন না ...

— প্লাজমাএইচএইচ

@ প্লাজমাএইচএইচ, পুনরুক্ত-ভিত্তিক forযেমন পুনরাবৃত্তকারীগুলির সাথে সমস্ত লুপগুলি প্রতিস্থাপন করা যাবে না যদি পুনরুক্তিগুলি লুপের শরীরে অবৈধ হয় এবং তাই প্রাক-বর্ধিত হওয়া বা মোটামুটি বৃদ্ধি করা দরকার না।

— জোনাথন Wakely

@ প্লাজমাএইচ: আমার ক্ষেত্রে, এমএসভিসি 10 লুপের জন্য পরিসর-ভিত্তিক কাজ করে না। যেহেতু এমএসভিসি 10 আমার গ-টু সি ++ 11 টেস্টবেড, তাই তাদের সাথে আমার আসলে খুব বেশি অভিজ্ঞতা নেই।

— জন ডিবলিং

Answer 9

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

নীচের লাইন: autoএটি যখন সহায়তা করে তখন ব্যবহার করুন : লুপগুলির জন্য পুনরাবৃত্তকারী। পাঠক প্রকারটি খুঁজে বের করার জন্য যখন এটির চেষ্টা করে তখন এটি ব্যবহার করবেন না।

Answer 10

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

মনে করুন আপনি কোনও ফাংশন পেয়েছেন, যা প্ল্যাটফর্ম-নির্দিষ্ট ধরণের সাথে কিছু দেয়:

#ifdef PLATFROM1
__int256 getStuff();
#else //PLATFORM2
__int128 getStuff();
#endif

জাদুকরী ব্যবহার আপনি পছন্দ করবেন?

#ifdef PLATFORM1
__int256 stuff = getStuff();
#else
__int128 stuff = getStuff();
#endif

বা কেবল সহজভাবে

auto stuff = getStuff();

অবশ্যই, আপনি লিখতে পারেন

#define StuffType (...)

পাশাপাশি কোথাও, কিন্তু না

StuffType stuff = getStuff();

আসলে এক্স এর ধরণ সম্পর্কে আরও কিছু বলুন? এটি সেখান থেকে ফিরে কী আসে তা তা বলে দেয়, তবে এটি স্বয়ংক্রিয় যা হয়। এটি কেবল অপ্রয়োজনীয় - 'স্টাফ' এখানে 3 বার লেখা হয়েছে - এটি আমার মতে এটি 'অটো' সংস্করণের চেয়ে কম পঠনযোগ্য করে তোলে।

Comments

প্ল্যাটফর্ম নির্দিষ্ট ধরণের হ্যান্ডেল করার সঠিক উপায় typedefতাদের কাছে।

— cmaster

Answer 11

পঠনযোগ্যতা বিষয়গত; আপনাকে পরিস্থিতিটি দেখার প্রয়োজন এবং সেরা কি তা সিদ্ধান্ত নিতে হবে।

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

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

তারপরে ধারাবাহিকতা আছে; এটা আপনার কাছে কতটা গুরুত্বপূর্ণ? আপনি কি কিছু অংশে অটো এবং অন্যদের মধ্যে স্পষ্ট ঘোষণা, বা একটি ধারাবাহিক পদ্ধতি চান?

Answer 12

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

Comments

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

— প্রচারক

Answer 13

আমার দুটি নির্দেশিকা রয়েছে:

• যদি ভেরিয়েবলের ধরণটি স্পষ্ট হয় তবে লেখার জন্য ক্লান্তিকর বা ব্যবহারের অটো নির্ধারণ করা শক্ত।

  auto range = 10.0f; // Obvious
  
  for (auto i = collection.cbegin(); i != cbegin(); ++i) // Tedious if collection type
  // is really long
  
  template <typename T> ... T t; auto result = t.get(); // Hard to determine as get()
  // might return various stuff

• আপনার যদি নির্দিষ্ট রূপান্তর প্রয়োজন হয় বা ফলাফলের ধরণটি সুস্পষ্ট না এবং বিভ্রান্তির কারণ হতে পারে।

  class B : A {}; A* foo = new B(); // 'Convert'
  
  class Factory { public: int foo(); float bar(); }; int f = foo(); // Not obvious

Answer 14

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

দিন শেষে 'অটো' কোডটি এবং স্বচ্ছতার জন্য পাঠ্যযোগ্যতার জন্য কৃত্রিম এবং নান্দনিক 'পরিষ্কার' জন্য আত্মত্যাগ করে (যা কেবলমাত্র আবশ্যক কারণ আবশ্যকভাবে অবিচ্ছিন্নভাবে বাক্য গঠন বাক্য গঠন করেছে) এবং প্রদত্ত কোনও লাইনে 10 টি কম অক্ষর টাইপ করার দক্ষতা রয়েছে। এটি ঝুঁকি, বা প্রচেষ্টা দীর্ঘমেয়াদী জড়িত মূল্যহীন।