প্ল্যাটফর্মগুলিতে 8-বিট চর ছাড়া অন্য কিছু রয়েছে?

Question

প্রতিবার এবং তারপরেও, এসও-তে থাকা যে কেউ উল্লেখ করেছেন যে char(ওরফে 'বাইট') 8 বিট অগত্যা নয় ।

দেখে মনে হচ্ছে 8-বিট charপ্রায় সর্বজনীন। আমি ভাবতাম যে মূলধারার প্ল্যাটফর্মগুলির জন্য, charবাজারে এটির কার্যকারিতা নিশ্চিত করার জন্য একটি 8-বিট থাকা প্রয়োজন।

এখন এবং Bothতিহাসিকভাবে উভয়ই, কোন প্ল্যাটফর্মগুলি charএমন 8 টি বিট নয় এমন ব্যবহার করে এবং কেন তারা "সাধারণ" 8 বিট থেকে পৃথক হবে?

কোড লেখার সময়, এবং ক্রস-প্ল্যাটফর্ম সমর্থন (যেমন সাধারণ-ব্যবহারের লাইব্রেরিগুলির জন্য) সম্পর্কে চিন্তা করার সময়, 8-বিটবিহীন প্ল্যাটফর্মগুলিতে কী ধরণের বিবেচনা করা উচিত char?

অতীতে আমি কিছু অ্যানালগ ডিভাইস ডিএসপি পেয়েছি যার charজন্য 16 বিট। আমি মনে করি ডিএসপিগুলি একটি কুলুঙ্গি স্থাপত্যের কিছুটা। (তারপরে আবার সেই সময় হাতে-কোডেড এসেম্বিলার সহজেই উপলব্ধ সি সংকলকগুলি যা করতে পারে তা সহজেই পরাজিত করে, তাই আমি প্ল্যাটফর্মে সিটির সাথে সত্যিই খুব বেশি অভিজ্ঞতা পাইনি))

Comments

সিডিসি সাইবার সিরিজে একটি 6/12 বিট এনকোডিং ছিল। সর্বাধিক জনপ্রিয় চরিত্রগুলি ছিল 6 বিট। বাকি অক্ষরগুলি 12 বিট ব্যবহার করেছে।

— থমাস ম্যাথিউজ

পিডিপি -11 এটিকে পেরেক দিয়েছিল। একটি চরকে একটি চরকে এনকোড করা যায় এমন ধারণাটি গুরুতরভাবে অপ্রচলিত।

— হান্স প্যাস্যান্ট

"পিডিপি -11 এটিকে পেরেক দিয়েছিল" - আপনার অর্থ হ'ল সি পিডিপি -11 এর জন্য 8 বিট বাইট সহ প্রথম প্রয়োগ করা হয়েছিল? তবে সিটি পরবর্তী সময়ে 9 বিট বাইট সহ হানিওয়েল মেশিনগুলির জন্য প্রয়োগ করা হয়েছিল। কেএন্ডআর সংস্করণ দেখুন See. এছাড়াও চরিত্র সম্পর্কে নয় (যেমন বাইট) সম্পর্কে প্রশ্নটি জিজ্ঞাসা করা হয়েছিল (এক বা একাধিক বাইট এমন কোনও এনকোডিং যা সম্পর্কে জিজ্ঞাসা করা হয়নি)।

— উইন্ডোজ প্রোগ্রামার

ডিইসি -10 এবং ডিইসি -20 এর 36-বিট শব্দ ছিল। প্রতি শব্দ পাঁচ পাঁচ বিট ASCII অক্ষর বেশ সাধারণ ছিল। এছাড়াও ছয়-বিট অক্ষর ব্যবহার করা হয়েছিল।

— ডেভিড আর ট্রিবিলে

@ ক্রেইগম্যাক কিউইন: আমি যদি সঠিকভাবে মনে রাখি তবে আট্মেল মাইক্রোকন্ট্রোলারদের জন্য কোডভিশন একজনকে চর আকার নির্বাচন করতে দেয়

— বনাম

Answer 1

charটেক্সাস ইনস্ট্রুমেন্টস C54x ডিএসপিগুলিতেও 16 বিট, যা ওএমএপি 2-তে উদাহরণস্বরূপ পরিণত হয়েছে। 16 এবং 32 বিট সহ অন্যান্য ডিএসপি রয়েছে char। আমি মনে করি এমনকি আমি একটি 24-বিট ডিএসপি সম্পর্কে শুনেছি, তবে আমি কী মনে করতে পারি না, তাই আমি এটি কল্পনাও করেছি।

আরেকটি বিবেচনা হ'ল পসিক্সের আদেশ CHAR_BIT == 8। সুতরাং আপনি যদি পসিক্স ব্যবহার করছেন তবে আপনি এটি ধরে নিতে পারেন। যদি কারও পরে আপনার কোডটি পসিক্সের কাছাকাছি-বাস্তবায়নের জন্য পোর্ট করার প্রয়োজন হয়, তবে এটি আপনার ব্যবহৃত ফাংশনগুলি ভিন্ন আকারের হতে পারে char, এটি তাদের দুর্ভাগ্য।

সাধারণভাবে, যদিও আমি মনে করি এটি সম্পর্কে চিন্তা করার চেয়ে ইস্যুটি প্রায় কাজ করা প্রায় সবসময় সহজ। শুধু টাইপ করুন CHAR_BIT। আপনি যদি সঠিক 8 বিট প্রকার চান তবে ব্যবহার করুন int8_t। আপনার কোডটি প্রত্যাশিত আকারটি নিঃশব্দে ব্যবহার করার পরিবর্তে কার্যকরভাবে প্রয়োগ করা যা কোনও সরবরাহ করে না তা সংকলন করতে ব্যর্থ হবে। খুব কমপক্ষে, আমি যদি এমন কোনও ক্ষেত্রে আঘাত করি যেখানে আমার এটি ধরে নেওয়ার উপযুক্ত কারণ রয়েছে তবে আমি এটি দৃsert়ভাবে জানাতে পারি।

Comments

টিআই সি 62XX এবং সি 64XX ডিএসপিতেও 16 বিট অক্ষর রয়েছে। (uint8_t platform প্ল্যাটফর্মে সংজ্ঞায়িত করা হয়নি))

— মায়ারন-সেম্যাক

অডিও প্রক্রিয়াকরণের জন্য অনেকগুলি ডিএসপি 24-বিট মেশিন হয়; BelaSigna আধা থেকে DSPs (পরে তারা AMI আধা কেনা); DSP56K / সিম্ফনি অডিও ফ্রীস্কেল থেকে DSPs (পরে তারা মটোরোলা থেকে বন্ধ কর্তিত হয়)।

— ডেভিড ক্যারি

@msemack C64xx এর 8/16/32/40 এর জন্য হার্ডওয়্যার এবং 8 বিট চর

— ব্যবহারকারী 3528438

পরিবর্তে assert()(যদি এটিই আপনি বোঝাতে চেয়েছিলেন), আমি ব্যবহার করতাম #if CHAR_BIT != 8... #error "I require CHAR_BIT == 8"...#endif

— কিথ থম্পসন

@ কিথথম্পসন ব্যবহার না করার কোনও কারণ আছে কি static_assert()?

— কিউস - মনিকা 4

Answer 2

কোড লেখার সময়, এবং ক্রস-প্ল্যাটফর্ম সমর্থন (যেমন সাধারণ-ব্যবহারের লাইব্রেরিগুলির জন্য) সম্পর্কে চিন্তাভাবনা করার সময়, নন-8-বিট চরের সাথে প্ল্যাটফর্মগুলিতে কী ধরণের বিবেচনা করা উচিত?

এটি এতোটুকুও নয় যে এটি কোনও নিয়মের দ্বারা চালিত হওয়ার কারণে "বিবেচনার যোগ্য" playing সি ++ তে উদাহরণস্বরূপ, স্ট্যান্ডার্ডটি বলেছে যে সমস্ত বাইটের "কমপক্ষে" 8 বিট থাকবে। যদি আপনার কোড ধরে নেয় যে বাইটের ঠিক 8 টি বিট রয়েছে, আপনি মানটি লঙ্ঘন করছেন।

এটি এখন নির্বোধ বলে মনে হতে পারে - " অবশ্যই সমস্ত বাইটের 8 টি বিট রয়েছে!", আমি আপনাকে বলতে শুনেছি। তবে খুব স্মার্ট লোক প্রচুর অনুমানের উপর নির্ভর করেছে যা গ্যারান্টি ছিল না এবং তারপরে সবকিছু ভেঙে যায়। ইতিহাস যেমন উদাহরণ সঙ্গে পূর্ণ।

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

---

একজন কমেন্টার জিজ্ঞাসা করেছিল যে কোথায় স্ট্যান্ডার্ডে বলা হয়েছে যে চরটিতে কমপক্ষে 8 বিট থাকতে হবে। এটি বিভাগ 5.2.4.2.1 । এই বিভাগটি সংজ্ঞায়িত করেছে CHAR_BIT, ক্ষুদ্রতম ঠিকানাযোগ্য সত্তায় বিটের সংখ্যা এবং এটির 8 এর একটি ডিফল্ট মান রয়েছে It এটি আরও বলে:

তাদের বাস্তবায়ন-সংজ্ঞায়িত মানগুলি একই চিহ্ন সহ দেখানোগুলির সাথে সমান বা বৃহত্তর (পরম মান) হবে shall

সুতরাং 8 বা তার চেয়ে বেশি সমান যে কোনও সংখ্যা এটি প্রয়োগের মাধ্যমে প্রতিস্থাপনের জন্য উপযুক্ত CHAR_BIT।

Comments

আমি কমপক্ষে 20 বছরে একটি টার্বো বোতামটি দেখিনি - আপনি কি সত্যিই মনে করেন যে এটি প্রশ্নের জার্মানী?

— মার্ক রান্সম

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

— জন Feminella

আপনি কি সি ++ স্ট্যান্ডার্ডে চিহ্নিত করতে পারেন যা বলে যে বাইতে কমপক্ষে 8 টি বিট রয়েছে? এটি একটি সাধারণ বিশ্বাস তবে আমি ব্যক্তিগতভাবে এটি স্ট্যান্ডার্ডটিতে খুঁজে পেতে ব্যর্থ হয়েছি। আমি স্ট্যান্ডার্ডে একমাত্র জিনিসটি খুঁজে পেয়েছি যে কোন অক্ষরগুলি অবশ্যই charতার মধ্যে 64৪ টির বেশি হওয়া উচিত তবে তার চেয়ে কম 128 সুতরাং b বিটই যথেষ্ট।

— আদম বদুরা

বিভাগ 18.2.2 এটির জন্য সি স্ট্যান্ডার্ডকে আহ্বান করে। সি স্ট্যান্ডার্ডে এটি বিভাগ 7.10 এবং তারপরে 5.4.2.4.1 বিভাগে। সি স্ট্যান্ডার্ড 22 পৃষ্ঠা।

— উইন্ডোজ প্রোগ্রামার

সুতরাং অন্যান্য উত্তর এবং মন্তব্যগুলি 5 বিট, 6 বিট এবং 7 বিট বাইট সহ মেশিনগুলির উল্লেখ করে। তার মানে কি এই যে আপনি সেই মেশিনে কোনও সি প্রোগ্রাম পরিচালনা করতে পারবেন না যা স্ট্যান্ডার্ডের সাথে মেনে চলে?

— জেরি যেরেমিয়া

Answer 3

36-বিট আর্কিটেকচারযুক্ত মেশিনগুলিতে 9-বিট বাইট রয়েছে। উইকিপিডিয়া অনুসারে, ৩ --বিট আর্কিটেকচারযুক্ত মেশিনগুলির মধ্যে রয়েছে:

• ডিজিটাল সরঞ্জাম কর্পোরেশন পিডিপি -6 / 10
• আইবিএম 701/704/709/7090/7094
• UNIVAC 1103 / 1103A / 1105/1100/2200,

Comments

এছাড়াও হানিওয়েল মেশিনগুলি, যেমন সম্ভবত দ্বিতীয় মেশিন যেখানে সি প্রয়োগ করা হয়েছিল।

— উইন্ডোজ প্রোগ্রামার

প্রকৃতপক্ষে, ডিসি -10 এর 6-বিট অক্ষরও রয়েছে - আপনি এর মধ্যে 6 টি 36-বিট শব্দের (প্রাক্তন-ডিসেম্বর -10 প্রোগ্রামার কথা বলার) মধ্যে প্যাক করতে পারেন

ডিইসি -20 টিএসপিএস -20 হে / এস-তে 36-বিট শব্দ প্রতি পাঁচ 5-বিট ASCII অক্ষর ব্যবহার করেছে।

— ডেভিড আর ট্রিবিলে

এই কৌতুকটি বাস্তবে এই স্থাপত্যে ইউনিকোডকে সমর্থন করার জন্য প্রয়োগ করা হয়েছিল।

— জোশুয়া

আমি কল্পনা করেছিলাম যে অষ্টালটি আসলে ব্যবহৃত হয়েছিল কারণ 3 টি অক্টাল ডিজিট খুব সুন্দরভাবে 9-বিট বাইট উপস্থাপন করে যেমন আমরা আজ সাধারণত হেক্সাডেসিমাল ব্যবহার করি কারণ দুটি হেক্সাডেসিমাল ডিজিট খুব সুন্দরভাবে একটি 8-বিট বাইট উপস্থাপন করে।

— bames53

Answer 4

যার কয়েকটি আমি সচেতন:

• ডিইসি পিডিপি -10: পরিবর্তনশীল, তবে প্রায়শই 7-বিট চরগুলি 36-বিট শব্দের প্রতি 5 প্যাক করে, নয়তো 9 বিট চর, প্রতি শব্দ প্রতি 4
• কন্ট্রোল ডেটা মেইনফ্রেমস (সিডিসি-64৪০০, 0000০০, 00 66০০, 00 76০০, সাইবার ১ 170০, সাইবার ১ 176 ইত্যাদি)--বিট অক্ষর, 60০-বিট শব্দ প্রতি 10 প্যাক করা হয়েছে।
• ইউনিসিস মেইনফ্রেমে: 9 বিট / বাইট
• উইন্ডোজ সিই: কেবলমাত্র `চর` টাইপটি মোটেও সমর্থন করে না - এর পরিবর্তে 16-বিট ডাব্লুচার_ট প্রয়োজন

Comments

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

— জেরি কফিন

উইন্ডোজ সিই সংকলক আসলেই এ charধরণের সমর্থন করে না ? আমি জানি যে সিস্টেম লাইব্রেরিগুলি কেবল স্ট্রিংগুলি গ্রহণ করে এমন ফাংশনগুলির বিস্তৃত চার্চ সংস্করণকে সমর্থন করে এবং উইনসইয়ের কমপক্ষে কয়েকটি সংস্করণ আপনাকে স্ট্রিং-হ্যান্ডলিং বন্ধ করতে, স্ট্রেনের মতো এএনএসআই স্ট্রিং ফাংশন সরিয়ে দেয়। তবে আসলেই কি এটির চরের ধরণ ছিল না? কি ছিল sizeof(TCHAR)? Malloc কি ধরণের ফিরে এসেছিল? জাভা byteটাইপ কীভাবে প্রয়োগ করা হয়েছিল?

— স্টিভ জেসোপ

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

— উইন্ডোজ প্রোগ্রামার

পিডিপি -10 এর জন্য সি এর কমপক্ষে দুটি বাস্তবায়ন রয়েছে (কে?): কেসিসি এবং জিসিসির একটি বন্দর ( pdp10.nocrew.org/gcc )।

— এপ্রোগ্রামার

সি স্ট্যান্ডার্ডটি 36-বিট শব্দে 5 প্যাকযুক্ত 7-বিট অক্ষরগুলিকে মঞ্জুরি দেয় না (যেমনটি আপনি পিডিপি -10 এর জন্য উল্লেখ করেছেন), বা এটি কন্ট্রোল ডেটা মেইনফ্রেমগুলির জন্য উল্লিখিত হিসাবে 6-বিট চরগুলিও অনুমতি দেবে না। দেখুন parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6

— কেন ব্লুম

Answer 5

সম্পূর্ণ পোর্টেবল কোড বলে কোনও জিনিস নেই। :-)

হ্যাঁ, বিভিন্ন বাইট / চরের আকার থাকতে পারে। হ্যাঁ, অত্যন্ত অস্বাভাবিক মান প্ল্যাটফর্মের জন্য সি / সি ++ বাস্তবায়নের হতে পারে CHAR_BITএবং UCHAR_MAX। হ্যাঁ, কখনও কখনও এমন কোড লেখা সম্ভব হয় যা চর আকারের উপর নির্ভর করে না।

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

ঠিক আছে. আপনি বাইট অর্ডার রূপান্তর সম্পাদন করতে পারেন এবং কাঠামোর সদস্যদের (যেমন uint32_tবা অনুরূপ) memcpyবাফারে ব্যবহার করে সরিয়ে নিতে পারেন। কেন memcpy? কারণ অনেকগুলি প্ল্যাটফর্ম রয়েছে যেখানে লক্ষ্য ঠিকানাটি সঠিকভাবে সাজানো না গেলে 32-বিট (16-বিট, 64-বিট - কোনও পার্থক্য) লেখা সম্ভব নয়।

সুতরাং, আপনি ইতিমধ্যে বহনযোগ্যতা অর্জনের জন্য অনেক কিছু করেছেন।

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

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

তবে যদি আপনার কোডটি উচ্চতর "স্বতন্ত্র" হয় - তবে কেন নয়? আপনি এটি এমনভাবে লিখতে পারেন যা বিভিন্ন বাইট আকারের অনুমতি দেয়।

Comments

যদি unsigned charকোনও মান প্রতি এক অক্টেট সঞ্চয় করে থাকে তবে কোডটি বৃহত্তর পূর্ণসংখ্যার ধরণের / থেকে অক্টেটের ক্রমগুলিকে রূপান্তর করতে শিফটের পরিবর্তে এলিয়াসিং ট্রিকস ব্যবহার না করে পোর্টেবিলিটি সমস্যা থাকতে হবে না। ব্যক্তিগতভাবে, আমি মনে করি সি স্ট্যান্ডার্ডটি সংক্ষিপ্ত ধরণের ক্রমগুলি (সবচেয়ে সাধারণভাবে char) প্রতি আইটেমের বিট সংশোধনযোগ্য-উপলভ্য সংখ্যার (8 প্রতি unsigned char, 16 প্রতি unsigned short, বা 32 প্রতি unsigned long) সংরক্ষণ করে আন্তঃসংখ্যগুলি প্যাক / আনপ্যাক করার জন্য অন্তর্নিহিত সংজ্ঞা দেওয়া উচিত ।

— সুপারক্যাট

Answer 6

দেখা যাচ্ছে যে আপনি এখনও একটি গুদামের বাইরে একটি আইএম 6100 (অর্থাত্ একটি চিপে পিডিপি -8) কিনতে পারবেন । এটি একটি 12-বিট আর্কিটেকচার।

Answer 7

অনেক ডিএসপি চিপগুলিতে 16- বা 32-বিট থাকে char। টিআই নিয়মিত যেমন চিপগুলি উদাহরণস্বরূপ তৈরি করে ।

Answer 8

সি এবং সি ++ প্রোগ্রামিং ল্যাঙ্গুয়েজগুলি উদাহরণস্বরূপ, বাইটকে "কার্যকর করার পরিবেশের মৌলিক চরিত্রের যে কোনও সদস্যকে ধরে রাখতে যথেষ্ট পরিমাণে তথ্যের ঠিকানাযোগ্য ইউনিট" (সি স্ট্যান্ডার্ডের ৩.6 ধারা) হিসাবে সংজ্ঞা দেয়। যেহেতু সি চর অবিচ্ছেদ্য ডেটা টাইপটিতে কমপক্ষে 8 বিট থাকতে হবে (ধারা 5.2.4.2.1), সি-তে একটি বাইট কমপক্ষে 256 টি বিভিন্ন মান রাখতে সক্ষম। সি এবং সি ++ এর বিভিন্ন বাস্তবায়ন বাইটকে 8, 9, 16, 32, বা 36 বিট হিসাবে সংজ্ঞায়িত করে

Http://en.wikedia.org/wiki/Byte#History থেকে উদ্ধৃত

অন্য ভাষা সম্পর্কে নিশ্চিত না।

http://en.wikipedia.org/wiki/IBM_7030_Stretch#Data_Formats

পরিবর্তনশীল দৈর্ঘ্য হতে সেই মেশিনে একটি বাইট নির্ধারণ করে

Comments

"যদিও অন্য ভাষার সম্পর্কে নিশ্চিত নয়" - historতিহাসিকভাবে, বেশিরভাগ ভাষা মেশিনের আর্কিটেকচারকে তার নিজস্ব বাইট আকার নির্ধারণ করতে দেয়। প্রকৃতপক্ষে

— উইন্ডোজ প্রোগ্রামার

Answer 9

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

Answer 10

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

এই কারণে, আমি uint16_tযখন নির্দিষ্ট বিট দৈর্ঘ্যের একটি ডেটা ধরণের প্রয়োজন তখন আমি ডেটা ধরণের সাথে আঁকতে চেষ্টা করি ।

সম্পাদনা: দুঃখিত, আমি প্রথমে আপনার প্রশ্নটি ভুলভাবে লিখেছি।

সি স্পেক বলছে যে কোনও charঅবজেক্ট "এক্সিকিউশন ক্যারেক্টার সেটের যে কোনও সদস্যকে সঞ্চয় করতে যথেষ্ট"। limits.hসর্বনিম্ন 8 টি বিটের আকার নির্ধারণ করে তবে সংজ্ঞাটি একটি charখোলার সর্বাধিক আকার ছেড়ে দেয় ।

সুতরাং, এটি charকমপক্ষে আপনার আর্কিটেকচারের এক্সিকিউশন সেট থেকে সবচেয়ে বড় চরিত্র (সাধারণত নিকটতম 8-বিট সীমানা পর্যন্ত গোলাকার) হিসাবে দীর্ঘ হয়। আপনার আর্কিটেকচারে যদি দীর্ঘতর ওপোড থাকে তবে আপনার charআকার আরও দীর্ঘ হতে পারে।

.তিহাসিকভাবে, x86 প্ল্যাটফর্মের অপকডটি এক বাইট দীর্ঘ charছিল , তাই প্রাথমিকভাবে একটি 8-বিট মান ছিল। বর্তমান x86 প্ল্যাটফর্ম সমর্থন করে একটি বাইটের চেয়ে দীর্ঘ অপকোড, তবে charপ্রোগ্রামাররা (এবং বিদ্যমান x86 কোডের বৃহত পরিমাণে) শর্তযুক্ত বলে লম্বায় 8 বিট রাখা হয়।

মাল্টি প্ল্যাটফর্ম সমর্থন সম্পর্কে চিন্তা করার সময়, সংজ্ঞায়িত প্রকারগুলির সুবিধা নিন stdint.h। আপনি (উদাহরণস্বরূপ) একটি uint16_t ব্যবহার করেন, তারপর আপনি কি নিশ্চিত যে এই মান একটি কি না সেই বিষয়ে 16 বিট মান অনুরূপ, যাই হোক না কেন আর্কিটেকচারের উপর একটি স্বাক্ষরবিহীন 16 বিট মান হতে পারে char, short, int, নাকি অন্য কিছু। ইতিমধ্যে বেশিরভাগ কঠোর পরিশ্রম লোকেরা করেছে যারা আপনার সংকলক / স্ট্যান্ডার্ড লাইব্রেরি লিখেছেন।

আপনি যদি charকোনও নিম্ন-স্তরের হার্ডওয়্যার ম্যানিপুলেশন করে যা প্রয়োজন এর সঠিক আকারটি জানতে হবে তবে আমি সাধারণত একটি ডেটা টাইপ ব্যবহার করি যা charসমস্ত সমর্থিত প্ল্যাটফর্মগুলিতে (সাধারণত 16 বিট যথেষ্ট) রাখার জন্য যথেষ্ট বড় এবং চালানো হয় একটি convert_to_machine_charরুটিনের মাধ্যমে মান যখন আমার সঠিক মেশিনের উপস্থাপনা প্রয়োজন through এইভাবে, প্ল্যাটফর্ম-নির্দিষ্ট কোডটি ইন্টারফেস ফাংশনে সীমাবদ্ধ এবং বেশিরভাগ সময় আমি একটি সাধারণ ব্যবহার করতে পারি uint16_t।

Comments

চরিত্রগুলি (ইউনিকোড কিনা তা) সম্পর্কে প্রশ্ন জিজ্ঞাসা করা হয়নি। এটি চর সম্পর্কে জিজ্ঞাসা করেছিল, যা একটি বাইট।

— উইন্ডোজ প্রোগ্রামার

এছাড়াও, এক্সিকিউশন অক্ষর সেটটির অপকডগুলির সাথে কোনও সম্পর্ক নেই, এটি নির্বাহের সময় ব্যবহৃত অক্ষর সেট, ক্রস-সংকলকগুলির কথা ভাবেন of

— নিনজালজ

"Icallyতিহাসিকভাবে, x86 প্ল্যাটফর্মের অপকোডটি একটি বাইট দীর্ঘ ছিল": কত মিষ্টি। Orতিহাসিকভাবে , সি একটি পিডিপি -11 (1972) এ বিকাশ করা হয়েছিল, x86 উদ্ভাবিত হওয়ার আগে (1978) এর অনেক আগে।

— মার্টিন বোনার

Answer 11

নন-8-বিট চরের সাথে প্ল্যাটফর্মগুলিতে কী ধরণের বিবেচনা করা উচিত?

স্থানান্তরিত করার সময় যাদু সংখ্যাগুলি ঘটে;

এর মধ্যে বেশিরভাগগুলি CHAR_BIT এবং উদাহরণস্বরূপ 8 এবং 255 (বা অনুরূপ) এর পরিবর্তে UCHAR_MAX ব্যবহার করে বেশ সহজেই পরিচালনা করা যায়।

আশা করি আপনার বাস্তবায়ন সেগুলি সংজ্ঞায়িত করেছে :)

এগুলি হ'ল "সাধারণ" বিষয়গুলি .....

অন্য অপ্রত্যক্ষ সমস্যাটি হ'ল আপনার কাছে রয়েছে:

struct xyz {
   uchar baz;
   uchar blah;
   uchar buzz; 
}

এটি একটি প্ল্যাটফর্মে 24 বিট "কেবল" নিতে পারে (সেরা ক্ষেত্রে) নিতে পারে তবে 72২ বিট অন্যত্র নিতে পারে .....

যদি প্রতিটি উচার "বিট পতাকা" ধারণ করে থাকে এবং প্রতিটি উচরের কাছে কেবল "2" উল্লেখযোগ্য "বিট বা পতাকা ছিল যা আপনি বর্তমানে ব্যবহার করছেন এবং আপনি কেবল" স্পষ্টতা "এর জন্য এগুলিকে 3 টি uchars এর মধ্যে সংগঠিত করেছেন, তবে এটি তুলনামূলকভাবে" আরও অপচয় "হতে পারে যেমন 24-বিট উচর সহ একটি প্ল্যাটফর্ম .....

কিছুতেই বিটফিল্ড সমাধান করতে পারে না, তবে তাদের দেখার জন্য অন্যান্য জিনিস রয়েছে ....

এই ক্ষেত্রে, কেবলমাত্র একটি একক এনাম আপনার "আসলতম" আকারের পূর্ণসংখ্যার আসল উপায় হতে পারে যা আপনার আসলে প্রয়োজন ...

সম্ভবত একটি বাস্তব উদাহরণ নয়, তবে কিছু কোড দিয়ে পোর্টিং / খেলার সময় আমার এই "বিট" এর মতো জিনিস .....

কেবল সত্য যে কোনও উচর যদি "সাধারণত" প্রত্যাশার চেয়ে ততবার বড় হয় তবে এই জাতীয় 100 টি কাঠামো কিছু প্ল্যাটফর্মে প্রচুর স্মৃতি নষ্ট করতে পারে ..... যেখানে "সাধারণভাবে" এটি কোনও বড় বিষয় নয় ... ।

সুতরাং জিনিসগুলি এখনও "ভাঙ্গা" হতে পারে বা এই ক্ষেত্রে "খুব দ্রুত স্মৃতি খুব দ্রুত নষ্ট করে" এমন একটি অনুমানের কারণে যে কোনও প্ল্যাটফর্মের তুলনায় র‌্যামের তুলনায় একটি প্ল্যাটফর্মের উচর "খুব অপব্যয় নয়" ... ..

সমস্যাটি আরও সুস্পষ্ট হতে পারে যেমন ইন্টস বা অন্যান্য ধরণের ক্ষেত্রে যেমন আপনার কিছু কাঠামো রয়েছে যার জন্য 15 টি বিট প্রয়োজন, তাই আপনি এটি একটি আটকে আটকে রাখুন, তবে অন্য কোনও প্ল্যাটফর্মে একটি ইনট 48 বিট বা যাই হোক না কেন .... ।

"সাধারণত" আপনি এটিকে 2 টি uchars মধ্যে বিভক্ত করতে পারেন, তবে উদাহরণস্বরূপ 24-বিট উচরের সাথে আপনার কেবল একটি প্রয়োজন হবে .....

সুতরাং একটি এনাম একটি ভাল "জেনেরিক" সমাধান হতে পারে ....

আপনি কীভাবে সেই বিটগুলিতে অ্যাক্সেস করছেন তার উপর নির্ভর করে :)

সুতরাং, "ডিজাইনের ত্রুটিগুলি" থাকতে পারে যা তাদের মাথা পিছনে ফেলে .... এমনকি যদি কোডটি এখনও কাজ করে / উচার বা ইউন্টের আকার নির্বিশেষে সূক্ষ্মভাবে চালায় ...

আপনার কোডে কোনও "ম্যাজিক নম্বর" না থাকলেও এ জাতীয় জিনিসগুলি নজর রাখতে হবে ...

আশা করি এটি সার্থক হয় :)

Comments

...কি? আপনি কেন enumঅন্যান্য দেশীয় প্রকারের চেয়ে ছোট বলে মনে করেন ? আপনি কি জানেন যে এটি একই স্টোরেজটিতে ডিফল্ট হয় int? "আপনার কিছু কাঠামো রয়েছে যার জন্য 15 টি বিট প্রয়োজন, তাই আপনি এটি কোনও ইনটিকে আটকে রাখুন, তবে অন্য কোনও প্ল্যাটফর্মে একটি ইনট 48 বিট বা যাই হোক না কেন ....." - #include <cstdint>এবং এটি int16_tবিট ব্যবহার হ্রাস করার সর্বোত্তম সুযোগের জন্য একটি করুন । আপনি সত্যিই নিশ্চিত নন যে আপনি thought সমস্ত উপবৃত্তের মধ্যে আপনি কী বলেছিলেন।

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

Answer 12

ints 16 বিট (pdp11, ইত্যাদি) ব্যবহৃত হত। 32 বিট আর্কিটেকচারে যাওয়া শক্ত ছিল। লোকেরা আরও উন্নত হচ্ছে: খুব সহজেই কেউ অনুমান করেছে যে কোনও পয়েন্টার আরও দীর্ঘায়িত হবে (আপনি ঠিক বলেছেন না?) অথবা ফাইল অফসেট, বা টাইমস্ট্যাম্প, বা ...

8 বিট অক্ষর ইতিমধ্যে কিছুটা অ্যানাক্রোনিজম। বিশ্বের সমস্ত চরিত্রের সেটগুলি ধরে রাখতে আমাদের ইতিমধ্যে 32 বিট দরকার।

Comments

সত্য। নামটি charএখন ইউনিকোডের দিনে কিছুটা বিশ্রী ain বাইনারি ডেটা, যেমন ফাইল স্টোরেজ, নেটওয়ার্ক যোগাযোগের সাথে লেনদেন করার সময় আমি 8-বিট ইউনিট (অক্টেটস) সম্পর্কে আরও যত্নশীল। uint8_tআরও দরকারী।

— ক্রেগ ম্যাককুইন

ইউনিকোডের কখনই পূর্ণ 32 বিটের প্রয়োজন হয় না। তারা মূলত 31 টির জন্য পরিকল্পনা করেছেন (মূল ইউটিএফ -8 কাজটি দেখুন) তবে এখন তারা কেবল 21 বিট নিয়ে সন্তুষ্ট । তারা সম্ভবত বুঝতে পেরেছিল যে তাদের যদি আসলে 31 টি বিটের প্রয়োজন হয় তবে তারা আর বইটি মুদ্রণ করতে পারবেন না: পি

— 22

@ me22, ইউনিকোড মূলত 16 বিটের জন্য পরিকল্পনা করেছে। "ইউনিকোডের অক্ষরগুলি ভাষা নির্বিশেষে ধারাবাহিকভাবে 16 বিট বিস্তৃত ..." ইউনিকোড ১.০.০। unicode.org/versions/Unicode1.0.0/ch01.pdf ।

— শ্যানন সিভেরেন্স

আইএসও 10646 মূলত 31 টি বিট ছিল এবং ইউনিকোড আইএসও 10646 এর সাথে একীভূত হয়েছিল, তাই ইউনিকোডটি 31 বিট ছিল তা বলতে গেলে ম্লান হতে পারে, তবে এটি সত্যই অসত্য নয়। নোট করুন তারা আসলে সম্পূর্ণ কোড টেবিল আর প্রিন্ট করে না।

— prosfilaes