কে সি +++ এর আইওএসট্রিমগুলি আর্কিটেক্ট / ডিজাইন করেছিলেন এবং এখনও এটি কি আজকের মানদণ্ড দ্বারা সুনির্দিষ্টভাবে বিবেচিত হবে? [বন্ধ]

Question

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

---

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

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

বিশেষত আমাকে কী আশ্চর্য করে :

• আইওএসট্রিমের সামগ্রিক নকশার জন্য কে দায়ী ছিলেন তা অজানা বলে মনে হচ্ছে (আমি এ সম্পর্কে কিছু পটভূমি তথ্য পড়তে পছন্দ করব - কেউ কি ভাল সংস্থান জানে?);

• একবার আপনি আইওএসটিস্ট্রিমের তাত্ক্ষণিক পৃষ্ঠের নীচে ডেলিভেশন করে, যেমন আপনি যদি নিজের ক্লাসের সাথে আইওএসট্রিমগুলি প্রসারিত করতে চান তবে আপনি মোটামুটি ক্রিপ্টিক এবং বিভ্রান্তকারী সদস্য ফাংশন নামগুলির সাথে একটি ইন্টারফেসে যান, যেমন, getloc/ imbue, uflow/ underflow, snextc/ sbumpc/ sgetc/ sgetn, pbase/ pptr/ epptr(এবং সেখানে সম্ভবত আরও খারাপ উদাহরণ)। সামগ্রিক নকশা এবং একক অংশগুলি কীভাবে সহযোগিতা করে তা বুঝতে এটি এত বেশি শক্ত করে তোলে। এমনকি বই আমি পূর্বেই উল্লেখ করা সাহায্য না যে অনেক (এই প্রোগ্রামটিতে)।

---

এইভাবে আমার প্রশ্ন:

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

Comments

ঔষধি Sutter মতামত আকর্ষণীয় stackoverflow.com/questions/2485963/... :) এটা খুব খারাপ, যে লোক অংশগ্রহণ এত পর মাত্র কয়েক দিন বাকি

— জোহানেস Schaub - litb

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

— মিমি মিমি মিমি মম

@ স্টেস্টেভেন, এই উদ্বেগগুলির একটি বিচ্ছেদ রয়েছে। std::streambufবাইট পড়ার এবং লেখার জন্য বেস-ক্লাস এবং istream/ ostreamএবং বিন্যাসটি ইন- এবং আউটপুট জন্য std::streambufহয়, এটির গন্তব্য / উত্স হিসাবে একটি পয়েন্টার গ্রহণ করে ।

— জোহানেস স্কাউব - লিটব

@ লিটলবি: তবে স্ট্রিমবুফ যা স্রোত (ফর্ম্যাটর) দ্বারা ব্যবহৃত হয় তা কী স্যুইচ করা সম্ভব? তাই সম্ভবত আমি এসটিএল ফর্ম্যাটিংটি ব্যবহার করতে চাই তবে নির্দিষ্ট স্ট্র্যামবুফের মাধ্যমে ডেটা লিখতে চাই?

— মিমি মিমি মিমি

@ স্টেটিভেনস,ostream foo(&somebuffer); foo << "huh"; foo.rdbuf(cout.rdbuf()); foo << "see me!";

— জোহানেস স্কাউব -

Answer 1

বেশ কয়েকটি অকল্পনীয় ধারণাগুলি স্ট্যান্ডার্ডের মধ্যে তাদের পথটি খুঁজে পেয়েছে: auto_ptr , vector<bool>, valarrayএবং export, শুধু একটি কয়েক নাম। সুতরাং আমি প্রয়োজনীয় ডিজাইনের চিহ্ন হিসাবে আইওএসট্রিমের উপস্থিতি নেব না।

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

Comments

আপনার সহযোগিতার জন্য ধন্যবাদ। আমি comp.lang.c++.moderatedকোনও মূল্যবান কিছু খুঁজে পেলে আমি সংরক্ষণাগারটি ব্রাউজ করব এবং আমার প্রশ্নের নীচে লিঙ্কগুলি পোস্ট করব । - তদ্ব্যতীত, আমি আপনার সাথে একমত হতে সাহস করি না auto_ptr: হার্ব সটারের ব্যতিক্রমী সি ++ পড়ার পরে RAII প্যাটার্নটি প্রয়োগ করার সময় এটি একটি খুব দরকারী শ্রেণীর মতো বলে মনে হয়।

— স্টাকেক্স -

@ স্ট্যাকএক্স: তবুও এটি unique_ptrপরিষ্কার এবং আরও শক্তিশালী শব্দার্থবিজ্ঞানের দ্বারা অবচিত ও বাতিল হয়ে চলেছে ।

— আঙ্কেলবেন্স

@UncleBens এর unique_ptrমূল মূল্যবোধের প্রয়োজন। সুতরাং এই মুহুর্তে auto_ptrখুব শক্তিশালী পয়েন্টার।

— আর্টিওম

তবে auto_ptrঅনুলিপি / অ্যাসাইনমেন্ট শব্দার্থবিজ্ঞানগুলি স্ক্রু করেছে যা এটি বাগগুলি অবমুক্ত করার এক কুলুঙ্গি করে তোলে ...

— ম্যাথিউ এম।

@ টোকেনম্যাকগুয়ে: এটি কোনও ভেক্টর নয়, এবং এটি বালগুলি সঞ্চয় করে না। যা এটি কিছুটা বিভ্রান্তিকর করে তোলে। ;)

— জলফ

Answer 2

কে তাদের নকশা করেছে সে সম্পর্কে, মূল গ্রন্থাগারটি (আশ্চর্যজনকভাবে নয়) তৈরি করেছিলেন বার্জন স্ট্রোস্ট্রুপ এবং তারপরে ডেভ প্রসোটো পুনরায় প্রয়োগ করেছিলেন। এরপরে এন্ড্রু কোয়েনিগের ম্যানিপুলেটরগুলির ধারণাটি ব্যবহার করে জেরি শোয়ার্জ সিফ্রন্ট ২.০-এর জন্য পুনরায় ডিজাইন করেছিলেন এবং পুনরায় প্রয়োগ করেছিলেন imp লাইব্রেরির মানক সংস্করণটি এই প্রয়োগের উপর ভিত্তি করে।

উত্স "সি ++ এর ডিজাইন এবং বিবর্তন", বিভাগ 8.3.1।

Comments

@ নীল - বাদাম ডিজাইনের বিষয়ে আপনার মতামত কী? আপনার অন্যান্য উত্তরের উপর ভিত্তি করে, অনেক লোক আপনার মতামত শুনতে পছন্দ করবে ...

— ডিভিকে

@ ডিভিকে সবেমাত্র আমার মতামত পৃথক উত্তর হিসাবে পোস্ট করেছেন।

সবেমাত্র বাজনে স্ট্রস্ট্রপের একটি সাক্ষাত্কারের অনুলিপিটি পাওয়া গেছে যেখানে তিনি কিছু বিট এবং আইওএস স্ট্রিমের ইতিহাসের টুকরো উল্লেখ করেছেন: www2.research.att.com/~bs/01chinese.html (এই লিঙ্কটি এখনই অস্থায়ীভাবে ভেঙে গেছে বলে মনে হচ্ছে, তবে আপনি চেষ্টা করতে পারেন গুগলের পৃষ্ঠায় ক্যাশে)

— স্ট্যাকক্স -

আপডেট হওয়া লিঙ্ক: stroustrup.com/01chinese.html ।

— ফ্র্যাঙ্কএইচবি

Answer 3

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

আমি বিভিন্ন কারণে না , বলতে চাই :

দরিদ্র ত্রুটি পরিচালনা

ত্রুটি শর্তগুলি ব্যতিক্রমগুলির সাথে প্রতিবেদন করা উচিত, সাথে নয় operator void*।

"জম্বি অবজেক্ট" অ্যান্টি-প্যাটার্নটি হ'ল এটি এর মতো বাগ তৈরি করে ।

বিন্যাসকরণ এবং I / O এর মধ্যে দুর্বল পৃথকীকরণ

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

এটি বাগের মতো লেখার প্রতিক্রিয়া বাড়িয়ে তোলে:

using namespace std; // I'm lazy.
cout << hex << setw(8) << setfill('0') << x << endl;
// Oops!  Forgot to set the stream back to decimal mode.

পরিবর্তে, আপনি যেমন কিছু লিখেছেন:

cout << pad(to_hex(x), 8, '0') << endl;

কোনও বিন্যাস-সম্পর্কিত রাষ্ট্র বিট থাকবে না, এবং কোনও সমস্যা হবে না।

নোট করুন যে জাভা, সি #, এবং পাইথনের মতো "আধুনিক" ভাষায়, সমস্ত বস্তুর একটি toString/ ToString/ __str__ফাংশন থাকে যা I / O রুটিন দ্বারা ডাকা হয়। আফাইক, কেবল সি ++ stringstreamস্ট্রিংয়ে রূপান্তর করার মানক উপায় হিসাবে ব্যবহার করে এটি অন্যভাবে করে ।

I18n এর জন্য দরিদ্র সমর্থন

আইস্ট্রিম-ভিত্তিক আউটপুট স্ট্রিং লিটারেলগুলিকে টুকরো টুকরো করে।

cout << "My name is " << name << " and I am " << occupation << " from " << hometown << endl;

ফর্ম্যাট স্ট্রিং পুরো বাক্যগুলিকে স্ট্রিং লিটারেলেস রাখে।

printf("My name is %s and I am %s from %s.\n", name, occupation, hometown);

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

Comments

আসলে, i18n এর জন্য, প্রতিস্থাপনগুলি পজিশনের দ্বারা চিহ্নিত করা উচিত (% 1,% 2, ..), কারণ অনুবাদ হিসাবে প্যারামিটার ক্রম পরিবর্তন করতে হতে পারে। অন্যথায়, আমি সম্পূর্ণরূপে একমত - +1।

— পিটারচেন

@peterchen: এর POSIX কি যে $জন্য নির্দিষ্টকরী printfহয়।

— জেমসডলিন

সমস্যাটি বিন্যাসের স্ট্রিং নয়, এটি সি ++ এর মধ্যে নন-টাইপসেটেফ ভার্জ রয়েছে।

— dan04

সি ++ 11 হিসাবে এটিতে এখন টাইপসেফ ভেরাগস রয়েছে।

— হাঁসটি

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

— কাউট দিয়ে করা জিনিসগুলি সাধারণত প্রিন্টফের

Answer 4

আমি এটি একটি পৃথক উত্তর হিসাবে পোস্ট করছি কারণ এটি খাঁটি মতামত।

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

Answer 5

সি ++ আইস্ট্রিম সম্পর্কে আমার মতামত সময়ের সাথে সাথে যথেষ্ট উন্নতি হয়েছে, বিশেষত আমি আমার নিজের স্ট্রিম ক্লাসগুলি বাস্তবায়নের মাধ্যমে এগুলি প্রকৃতপক্ষে প্রসারিত করা শুরু করার পরে। আমি হাস্যকরভাবে দরিদ্র সদস্য ফাংশন নামগুলির মতো সত্ত্বেও এক্সটেনসিবিলিটি এবং সামগ্রিক নকশার প্রশংসা করতে শুরু করিxsputn বা যাই হোক না কেন । নির্বিশেষে, আমি মনে করি I / O স্ট্রিমগুলি সি স্টিডিয়ো এইচ-এর চেয়ে ব্যাপক উন্নতি, যার কোনও ধরণের সুরক্ষা নেই এবং এটি প্রধান সুরক্ষা ত্রুটিগুলির সাথে ছাঁটাই।

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

std::stringstream ss;
std::string output_string = "Hello world";
ss << output_string;

...

std::string input_string;
ss >> input_string;
std::cout << input_string;

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

আপনি বলতে পারেন যে আইও স্ট্রিমগুলি সিরিয়ালাইজেশন সুবিধা হিসাবে ডিজাইন করা হয়নি, তবে যদি এটি হয় তবে ইনপুট স্ট্রিমগুলি আসলে কীসের জন্য? এছাড়াও, অনুশীলনে I / O স্ট্রিমগুলি প্রায়শই অবজেক্টগুলিকে সিরিয়ালাইজ করতে ব্যবহার করা হয়, কারণ অন্য কোনও স্ট্যান্ডার্ড সিরিয়ালাইজেশন সুবিধা নেই। বিবেচনা করুন boost::date_timeবা boost::numeric::ublas::matrixযেখানে আপনি <<অপারেটরের সাথে যদি কোনও ম্যাট্রিক্স অবজেক্ট আউটপুট করেন , আপনি >>অপারেটরটি ব্যবহার করে ইনপুট দেওয়ার সময় আপনি ঠিক একই ম্যাট্রিক্স পাবেন । তবে এটি সম্পাদন করার জন্য, বুস্ট ডিজাইনারদের কলাম গণনা এবং সারি গণনার তথ্য আউটপুটে পাঠ্যগত ডেটা হিসাবে সংরক্ষণ করতে হয়েছিল, যা প্রকৃত মানব-পঠনযোগ্য প্রদর্শনকে আপোষ করে। আবার, পাঠ্য বিন্যাসের সুবিধা এবং সিরিয়ালাইজেশনের একটি বিশ্রী সমন্বয়।

অন্যান্য অন্যান্য ভাষা কীভাবে এই দুটি সুবিধা পৃথক করে তা নোট করুন। জাভাতে, উদাহরণস্বরূপ, বিন্যাসটি toString()পদ্ধতিটির মাধ্যমে সম্পন্ন হয় , যখন Serializableইন্টারফেসের মাধ্যমে সিরিয়ালাইজেশন সম্পন্ন হয় ।

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

Comments

উত্তর করার জন্য ধন্যবাদ. আমি এ সম্পর্কে ভালই হতে পারি, তবে আপনার শেষ পয়েন্টটি সম্পর্কে (বাইট-ভিত্তিক বনাম চরিত্রভিত্তিক স্ট্রিমগুলি), স্ট্রিম বাফারগুলির (চরিত্র রূপান্তর, পরিবহন এবং বাফারিং) বিভাজনের জন্য আইওএসট্রিমের (আংশিক?) উত্তর কি নয়? এবং স্ট্রিম (ফর্ম্যাটিং / পার্সিং)? এবং আপনি কি নতুন স্ট্রিম ক্লাসগুলি তৈরি করতে পারেন নি, যা কেবল (যন্ত্র-পাঠযোগ্য) সিরিয়ালাইজেশন এবং ডিসরিয়ালাইজিং এবং অন্যদের (মানব-পঠনযোগ্য) ফর্ম্যাটিং এবং পার্সিংয়ের প্রতি অনন্যভাবে তৈরি for

— স্টাকেক্স

@ স্ট্যাকেক্স, হ্যাঁ, এবং আসলে আমি এটি করেছি। এটি std::char_traitsশোওয়ার চেয়ে কিছুটা বিরক্তিকর, যেহেতু এটি গ্রহণের জন্য বহনযোগ্যভাবে বিশেষজ্ঞ করা যায় না unsigned char। যাইহোক, কর্মক্ষেত্র রয়েছে, তাই আমি অনুমান করি এক্সটেনসিবিলিটি আবারও উদ্ধারে আসে। তবে আমি মনে করি যে বাইট-ভিত্তিক স্ট্রিমগুলি স্ট্যান্ডার্ড নয় এটি লাইব্রেরির দুর্বলতা।

— চার্লস সালভিয়া

এছাড়াও, বাইনারি স্ট্রিমগুলি প্রয়োগ করার জন্য আপনাকে নতুন স্ট্রিম ক্লাস এবং নতুন বাফার ক্লাসগুলি প্রয়োগ করতে হবে , কারণ ফর্ম্যাটিং উদ্বেগগুলি সম্পূর্ণরূপে পৃথক নয় std::streambuf। সুতরাং, মূলত আপনি যে জিনিসটি প্রসারিত করছেন তা হচ্ছে std::basic_iosক্লাস। সুতরাং একটি রেখা আছে যেখানে "সম্প্রসারণ" "সম্পূর্ণ পুনরায় বাস্তবায়ন" অঞ্চলগুলিতে অতিক্রম করে এবং C ++ I / O স্ট্রিম সুবিধাগুলি থেকে বাইনারি স্ট্রিম তৈরি করা সেই বিন্দুর কাছে পৌঁছায় বলে মনে হয়।

— চার্লস সালভিয়া

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

— stakx -

" কোনও বস্তুকে পোর্টেবল ফর্ম্যাটে সিরিয়ালাইজ করার জন্য। " না, তাদের কখনই

— সেটিকে

Answer 6

আমি সর্বদা সি ++ আইওএসট্রিমগুলিকে অ-নকশাকৃতভাবে খুঁজে পেয়েছি: তাদের বাস্তবায়নটি একটি নতুন প্রকারের প্রবাহকে সঠিকভাবে সংজ্ঞা দেওয়া খুব কঠিন করে তোলে। তারা আইও বৈশিষ্ট্য এবং ফর্ম্যাট বৈশিষ্ট্যগুলি মিশ্রিত করে (ম্যানিপুলেটারগুলির সম্পর্কে চিন্তা করুন)।

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

আমার ইচ্ছা সি ++ স্ট্রিমগুলির বিষয়ে এত সহজ ছিল ...

Comments

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

— স্টাকাক্স

"আইও বৈশিষ্ট্য এবং বিন্যাস বৈশিষ্ট্যগুলি মিশ্রণ করুন" <- এ সম্পর্কে কী ভুল? লাইব্রেরির পয়েন্ট এটাই। নতুন স্ট্রিমগুলি তৈরির বিষয়ে, আপনার স্ট্রিম্বুফের পরিবর্তে একটি স্ট্র্যামবুফ তৈরি করা উচিত এবং স্ট্র্যামবুফের চারপাশে একটি সমতল স্ট্রিম তৈরি করা উচিত।

— বিলি ওনিল

মনে হয় এই প্রশ্নের উত্তর আমাকে এমন কিছু বোঝে যা আমাকে কখনই ব্যাখ্যা করা হয়নি: আমার স্ট্রিমবুফের পরিবর্তে স্ট্রিমবুফ নেওয়া উচিত ...

— অ্যাড্রিয়েন প্লিসন

@ স্টাকেক্স: স্ট্র্যামবুফ স্তরটি যদি আপনি যা বলেছিলেন তা যদি করে তবে তা ভাল fine তবে অক্ষর ক্রম এবং বাইটের মধ্যে রূপান্তরগুলি সবই আসল I / O (ফাইল, কনসোল ইত্যাদি) এর সাথে মিশে যায়। চরিত্র রূপান্তর না করেও ফাইল I / O সঞ্চালনের কোনও উপায় নেই যা অত্যন্ত দুর্ভাগ্যজনক।

— বেন ভয়েগট

Answer 7

আমি মনে করি আইওএসটিস্ট্রিম ডিজাইন প্রসারযোগ্যতা এবং দরকারীতার দিক দিয়ে উজ্জ্বল।

1. স্ট্রিম বাফারগুলি: বুস্ট.আইস্ট্রিম এক্সটেনশানগুলিতে একবার দেখুন: জিজিপ তৈরি করুন, টি, কয়েকটি লাইনে স্ট্রিম অনুলিপি করুন, বিশেষ ফিল্টার তৈরি করুন ইত্যাদি। এটি ছাড়া সম্ভব হবে না।

2. স্থানীয়করণ সংহতকরণ এবং ফর্ম্যাটিং ইন্টিগ্রেশন। কী করা যায় তা দেখুন:

   std::cout << as::spellout << 100 << std::endl;

   মুদ্রণ করতে পারেন: "একশ" বা এমনকি:

   std::cout << translate("Good morning")  << std::endl;

   "বনজৌর" বা "בוקר טוב" প্রিন্ট করতে পারে লোকাল অনুযায়ী জড়িত std::cout!

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

এটি আরও ভাল করা যেতে পারে?

অবশ্যই পারে!আসলে অনেকগুলি জিনিস রয়েছে যা উন্নত হতে পারে ...

আজ থেকে সঠিকভাবে প্রাপ্তিটি বেশ বেদনাদায়ক stream_buffer , অতিরিক্ত স্ট্রিমিং স্ট্রিমিংয়ের তথ্য যুক্ত করা তুচ্ছ নয়, তবে সম্ভব।

তবে অনেক বছর আগে ফিরে তাকানো আমি এখনও লাইব্রেরির নকশা অনেক ভাল জিনিস আনতে যথেষ্ট ভাল ছিল।

কারণ আপনি সর্বদা বড় ছবি দেখতে পারবেন না, তবে আপনি যদি এক্সটেনশনের জন্য পয়েন্টগুলি ছেড়ে দেন তবে এটি আপনাকে এমন পয়েন্টগুলিতে এমনকি আরও ভাল ক্ষমতা দেয় যা আপনি ভাবেননি।

Comments

পয়েন্ট 2 এর জন্য আপনার উদাহরণগুলি কেন এমন কিছু ব্যবহার করার চেয়ে ভাল হবে print (spellout(100));এবং print (translate("Good morning"));এটিকে একটি ভাল ধারণা বলে মনে হবে, যেমন এই I / O থেকে ফর্ম্যাটিং এবং i18n ডুপ্লুপস হিসাবে আপনি একটি মন্তব্য প্রদান করতে পারেন ?

— নির্ধারিত সময়

কারণ এটি স্রোতে নিমগ্ন ল্যাঙ্গেজ অনুযায়ী অনুবাদ করা যেতে পারে। অর্থাৎ, french_output << translate("Good morning"); english_output << translate("Good morning") আপনাকে দেবে: "বনজর শুভ সকাল"

— আরটিয়াম

স্থানীয়করণ যখন আপনি একটি ভাষায় '<< "পাঠ্য" << মান "করতে চান তবে" << মান << "পাঠ্য" অন্য "

— মার্টিন বেকেট

@ মার্টিন বেকেট আমি জানি, বুস্ট.লোক্যাল লাইব্রেরিটি একবার দেখুন, এমন কি ঘটে যে আপনি যদি এমনটি করেন তবে এটি অনুবাদও out << format("text {1}") % valueহতে পারে "{1} translated"। সুতরাং এটি কাজ করে ;-)।

— আরটিয়াম

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

— jalf

Answer 8

(এই উত্তরটি কেবল আমার মতের ভিত্তিতে)

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

Comments

আমি মনে করি আপনার "ফাংশনাল" না দিয়ে "ফাংশন" বোঝানো হয়েছে। ফাংশনাল প্রোগ্রামিং সেই জেনেরিক প্রোগ্রামিং দেখে আরও খারাপ কোড তৈরি করে।

— ক্রিস বেক

এই ভুলটি নির্দেশ করার জন্য ধন্যবাদ; আমি সংশোধন প্রতিফলিত করতে উত্তর সম্পাদনা করেছি।

— ডেলান আজাবানী

আইওএসট্রিমগুলি অবশ্যই ক্লাসিক স্টাডিওর চেয়ে ধীর হতে হবে; যদি আমাকে একটি বহনযোগ্য এবং সহজেই ব্যবহারযোগ্য I / O স্ট্রিম ফ্রেমওয়ার্ক ডিজাইন করার কাজটি দেওয়া হয় তবে আমি সম্ভবত গতি গৌণ বিচার করব, এই বাস্তবতার বাধা সম্ভবত ফাইল I / O গতি বা নেটওয়ার্ক ট্র্যাফিক ব্যান্ডউইথ হতে পারে given

— স্টাকেক্স - আর

আমি সম্মত হই যে I / O বা নেটওয়ার্কের জন্য কম্পিউটেশনাল গতির পক্ষে তেমন কিছু আসে যায় না। তবে মনে রাখবেন যে সংখ্যার / স্ট্রিং রূপান্তরটির জন্য সি ++ ব্যবহার করা হচ্ছে sstringstream। আমি মনে করি গতি গৌণ হয়, যদিও এটি গৌণ।

— ম্যাথিউ এম।

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

— গ্রেগগো

Answer 9

আইওএসট্রিম ব্যবহার করার সময় আমি সর্বদা অবাক হয়ে যাই।

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

অনেক ফাংশনে বিভ্রান্তিকর শব্দার্থবিজ্ঞানও রয়েছে (যেমন পান, গেটলাইন করুন, উপেক্ষা করুন এবং পড়ুন Some কিছু ডিলিমিটারটি বের করেন, কিছু কিছু করেন না; কিছু সেটও তৈরি করেন)। কিছু প্রবাহ প্রয়োগ করার সময় অদ্ভুত ফাংশনটির নাম উল্লেখ করে (উদাহরণস্বরূপ xsputn, uflow, আন্ডারফ্লো)। যখন কেউ wchar_t রূপগুলি ব্যবহার করে তখন পরিস্থিতি আরও খারাপ হয়। ডাব্লু স্ট্রিমটি মাল্টিবাইটে একটি অনুবাদ করে যখন স্ট্রিং স্ট্রিমটি করে না। বাইনারি I / O ডাব্লুচিকার_টি দিয়ে বাক্সটির বাইরে কাজ করে না: আপনার কোডেকটি ওভাররাইট হয়েছে।

সি বাফার করা আই / ও (অর্থাত্ ফাইল) এর সি ++ অংশের মতো শক্তিশালী নয়, তবে এটি আরও স্বচ্ছ এবং এতে স্বল্প ও স্বাক্ষরিত আচরণ রয়েছে counter

তবুও প্রতিবারই যখন আমি আইওএসট্রিমের উপর হোঁচট খেয়ে যাই, তখন আমি আগুনের পতঙ্গের মতো তার প্রতি আকৃষ্ট হই। সম্ভবত কিছু ভাল চালাক লোকের সামগ্রিক আর্কিটেকচারটি ভালভাবে দেখলে সম্ভবত এটি খুব ভাল হবে।

Answer 10

আমি প্রশ্নের প্রথম অংশটির উত্তর দিতে সহায়তা করতে পারি না (এটি কে করেছে?)। তবে এটি অন্য পোস্টে জবাব দেওয়া হয়েছিল।

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

#include <stdint.h>
#include <iostream>
#include <vector>

// A small attempt in generic programming ;)
template <class _T>
void ShowVector( const char *title, const std::vector<_T> &v)
{
    std::vector<_T>::const_iterator iter;
    std::cout << title << " (" << v.size() << " elements): ";
    for( iter = v.begin(); iter != v.end(); ++iter )
    {
        std::cout << (*iter) << " ";
    }
    std::cout << std::endl;
}
int main( int argc, const char * argv[] )
{
    std::vector<uint8_t> byteVector;
    std::vector<uint16_t> wordVector;
    byteVector.push_back( 42 );
    wordVector.push_back( 42 );
    ShowVector( "Garbled bytes as characters output o.O", byteVector );
    ShowVector( "With words, the numbers show as numbers.", wordVector );
    return 0;
}

উপরের কোডটি আইওস্ট্রিম ডিজাইনের কারণে বাজে কথা উত্পাদন করে। আমার উপলব্ধি ছাড়িয়ে যাওয়ার কিছু কারণে তারা uint8_t বাইটকে অক্ষর হিসাবে বিবেচনা করে, বৃহত্তর অবিচ্ছেদ্য ধরণের সংখ্যার মতো বিবেচনা করা হয়। Qed খারাপ নকশা।

এটি ঠিক করার কোনও উপায় নেই is প্রকারটি পাশাপাশি ফ্লোট বা ডাবলও হতে পারে ... সুতরাং নির্মেয় আইস্ট্রিমকে বোঝার জন্য 'ইনট' এ অভিনেতাকে বুঝতে হবে যে সংখ্যাগুলি চরিত্র নয় তা বিষয়বস্তু সাহায্য করবে না।

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

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

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

template <class _T>
void ShowVector( const char *formatString, const char *title, const std::vector<_T> &v );

Comments

দোষটি (নিখুঁতভাবে) iostream নিয়ে আসে না। পরীক্ষা করে দেখুন আপনার কি uint8_tএকটি হল মধ্যে typedef জন্য। এটি কি আসলে চর? তারপরে আইস্ট্রিমেজকে চরের মতো আচরণের জন্য দোষ দিবেন না।

— মার্টিন বা

এবং আপনি যদি জেনেরিক কোডে একটি নম্বর পেয়েছেন তা নিশ্চিত করতে চান তবে আপনি স্ট্রিম সন্নিবেশ অপারেটরের পরিবর্তে num_putদিকটি ব্যবহার করতে পারেন ।

— মার্টিন বা

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

— বিটিক্লার

@ মার্টিন ব্লে: সিপ্রেফারেন্স উল্লেখ করেছেন যে ইন্ট 8_টি হ'ল 8 বিটের প্রস্থ সহ একটি স্বাক্ষরিত পূর্ণসংখ্যা টাইপ author আমি লেখকের সাথে একমত যে আপনি তখন আবর্জনার আউটপুট পান তা আশ্চর্যের বিষয়, যদিও এটি টাইপডেফ এবং আইওস্ট্রিমের চর টাইপের ওভারলোডের দ্বারা প্রযুক্তিগতভাবে ব্যাখ্যাযোগ্য । এটি টাইপডেফের পরিবর্তে একটি সত্য __int8 রেখে সমাধান করা যেতে পারে।

— gast128

ওহ, এটি ঠিক করা খুব সহজ: // স্ট্যান্ড :: অস্ট্রিমে ফিক্স যা স্বাক্ষরযুক্ত / স্বাক্ষরিত / চর প্রকারের জন্য সমর্থন ভঙ্গ করেছে // এবং 8-বিট ইন্টিজারগুলি অক্ষরের মতো ছাপিয়েছে। নেমস্পেস ostream_fixes {ইনলাইন স্টাড :: ostream এবং অপারেটর << (std :: ostream & os, স্বাক্ষরযুক্ত স্বাক্ষরিত i) {ফিরে আসুন << স্ট্যাটিক_কাস্ট <স্বাক্ষরবিহীন>> (i); } ইনলাইন std :: ostream & অপারেটর << (std :: ostream & OS, স্বাক্ষরিত চর) {রিটার্ন ওএস << স্ট্যাটিক_কাস্ট <স্বাক্ষরিত>> (i); }} // নেমস্পেস ostream_fixes

— এমসিভি

Answer 11

অন্যান্য প্রতিক্রিয়াগুলিতে উল্লিখিত হিসাবে সি ++ আইওস্ট্রিমে প্রচুর ত্রুটি রয়েছে, তবে আমি এর প্রতিরক্ষায় কিছু নোট করতে চাই।

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

নতুনদের জন্য এই সরলতা একটি মূল্যে আসে, এটি আরও জটিল পরিস্থিতিতে I / O এর সাথে আচরণের জন্য মাথা ব্যাথা তৈরি করতে পারে তবে আশা করি সেই মুহূর্তে প্রোগ্রামার তাদের সাথে মোকাবেলা করতে যথেষ্ট শিখেছে, বা কমপক্ষে যথেষ্ট পুরানো হয়ে গেছে পান করতে.