সি ++ বিকাশে এসটিএল ত্যাগ করা কি ব্যবহারিক? [বন্ধ]


19

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



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

ডিবাগিংয়ের সময় স্টিপিং এড়িয়ে চলা হিসাবে দেখুন, উদাহরণস্বরূপ: stackoverflow.com/questions/2062881/…
মার্টিন বা

এটি একটি ভাল প্রশ্নের মতো মনে হচ্ছে। হতে পারে কেউ যুক্ত করতে পারে "কোনও প্রকল্প কেন এসটিএল ব্যবহার না করা বেছে নেবে?"
ম্যাথু জেমস ব্রিগেস

উত্তর:


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

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

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

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

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

    এছাড়াও, বেশ দীর্ঘ সময় ধরে এটি "এসটিএল" নয়, তবে এএনএসআই সি ++ স্ট্যান্ডার্ড লাইব্রেরি। এটি একেবারে একই স্ট্যান্ডার্ড ডকুমেন্ট দ্বারা সংজ্ঞায়িত করা হয়েছে যা ভাষাটি নিজেরাই সংজ্ঞায়িত করে। যে কোনও কিছু এটি সমর্থন করে না সেটিকে সত্যই সি ++ বলা যায় না।


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

@ এসএমএলটাররা: অবশ্যই, রিয়েল-টাইম প্রয়োজনীয়তার অধীনে অনেকগুলি জিনিস ব্যবহার করা যায় না। এমনকি কিছু ভাষা বৈশিষ্ট্য যেমন ব্যাতিক্রম করতে পারে না। স্টিল সি ++ এই সিস্টেমগুলির জন্য দুর্দান্ত ভাষা, কারণ এটি শক্তিশালী সুরক্ষার সাথে কার্যকারিতা এবং সুনির্দিষ্ট নিয়ন্ত্রণকে একত্রিত করতে পারে (এটির জন্য RAII সবচেয়ে গুরুত্বপূর্ণ বৈশিষ্ট্য)।
জানু হুডেক

@ জানহুদেক: প্রকৃতপক্ষে, এজন্য এসটিএল অংশগুলি কেবলমাত্র সি ++ এর "হোস্টেড" প্রয়োগের জন্য প্রয়োজন।
এমসাল্টারস

7

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

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

1
এসএসও ইতিমধ্যে সাধারণ।
হস্তান্তরকারী

উত্তরাধিকারের জন্য: এসএসও -> ছোট স্ট্রিং অপ্টিমাইজেশন, অর্থাৎ সর্বাধিক (সমস্ত?) এসটিডি :: স্ট্রিং বাস্তবায়নগুলি স্ট্যাকের উপরে ছোট ছোট স্ট্রিং রাখে এবং প্রয়োজনে গাদাতে স্যুইচ করুন
নীল


4

সি ++ স্ট্যান্ডার্ড টেম্পলেট লাইব্রেরিটি ব্যবহার না করার একটি বড় বৈধ কারণ রয়েছে: আপনার টার্গেট প্ল্যাটফর্মগুলির মধ্যে একটির এটির পুরোপুরি মেনে চলার বাস্তবায়ন নেই (অথবা এটির কোনও প্রয়োগ নেই) এবং আপনি জানেন যে এটির একটি হবে না won't পরবর্তী বছরের মধ্যে।


3
আকা "যখন আপনার কাছে নেই তখন এটি ব্যবহার করবেন না", যা সত্যই উপলব্ধি করে। :)
জিও

4
প্রদত্ত যে সি ++ 03 স্ট্যান্ডার্ড লাইব্রেরিটি কেবল এএনএসআই সি 89 লাইব্রেরির ক্ষেত্রে প্রয়োগের জন্য ডিজাইন করা হয়েছে, এমন কোনও প্ল্যাটফর্ম রয়েছে যেখানে আপনি কমপক্ষে এসটিএলপোর্ট পাবেন না ?
জানু হুডেক

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

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

4

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

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


2
এসটিএল বাস্তবায়নগুলি নেই যা ক) উপলভ্য ছিল, বা খ) কোনও ভাল the এগুলি কেবলমাত্র এখনও ব্যবহৃত হয়, আজকের এসটিএলের বিরুদ্ধে কিছুই নেই।
gbjbaanb

1
@ জর্জিও: সমস্যাটি জটিল অ্যাপ্লিকেশনগুলিতে রয়েছে, যেখানে আপনি একাধিক লাইব্রেরি সংযুক্ত করছেন। এসটিএল পাত্রে, মানক হওয়ার কারণে একটি লিঙ্গুয়া ফ্র্যাঙ্কা তৈরি হয় । আরও স্পষ্টভাবে, এটি তাদের সম্মেলনগুলি যা করে। সর্বাধিক পরিচিত উদাহরণ বুস্ট। এটি এসটিএল পাত্রে কাজ করতে পারে। এটি কিউটি কনটেইনারগুলিতেও কাজ করতে পারে তবে কেবলমাত্র কেন যে কিউটি এসটিএল কনভেনশনগুলি অনুসরণ করেছে - যেমনQList<T>::iterator
এমসাল্টার্স

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

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

1
@ নন: যেমনটি আমি বলেছিলাম, আমি পুরোপুরি পেয়েছি যে আপনি ক্যামেলকেসে আরও আরামদায়ক।
হস্তান্তরকারী

3

প্যাট্রিক পুরো এসটিএল ব্যবহার না করার কারণ উল্লেখ করেছেন , আপনার প্ল্যাটফর্মের (গুলি) নেই।

সব মিলিয়ে আমি মনে করি প্রশ্নটি বিন্দুটি অনুপস্থিত। এটি বেশিরভাগই সর্বস্ব বা কিছুই নয়, বেছে নেওয়া বাছাইয়ের একটি। আপনি পাত্রে এবং অ্যালগরিদমের সাথে ভালভাবে যেতে সিদ্ধান্ত নিতে পারেন, তবে স্ট্রিং এবং i / o এর জন্য স্ট্যান্ড লিবের বাইরে কিছু ব্যবহার করার সিদ্ধান্ত নিতে পারেন।


3

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

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

"প্রতিটি সফল গেমটি আপনার নিজের লিঙ্কযুক্ত তালিকার বাস্তবায়ন ঘটাতে শুরু করে।"


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

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

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

2
@ জানহুদেক বিষয়টি হ'ল বাস্তবায়নের (এবং আচরণগুলিও খুব বাস্তব) কাজের জন্য খুব উপযুক্তভাবে তৈরি হওয়া দরকার। আপনি কেবলমাত্র এখানে কয়েক ডজন বাইট ছাড়তে পারবেন না এবং সেখানে (রেফারেন্সের লোকালটি নষ্ট করে), ইনপুটকে বৈধ করতে কয়েকটি শাখায় ফেলে (শাখার ভুল ও নির্দেশাবলী ক্যাশে মিস করেছেন) এবং ধরে নিন যে সংকলক আপনার ডেটা-কাঠামোকে কীভাবে ভেক্টরাইজ করতে হয় তা জানে সিমডের সুবিধা গ্রহণ করার জন্য (এটি হবে না, বা কমপক্ষে আপনাকে যা যা চেষ্টা করে তা যাচাই করে নিতে হবে)। অবশ্যই একটি পিসিতে রিয়েল-টাইম সফ্টওয়্যার লেখা ততটা কঠোর নয়, আপনি সর্বদা একটি দ্রুত সিপিইউতে ফেলতে পারেন। কনসোলগুলিতে নয়।
zxcdw
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.