স্মৃতি সংরক্ষণের জন্য ভেরিয়েবলগুলির জন্য ছোট ডেটা ধরণের ব্যবহার করা কি ভাল অনুশীলন?

32

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

int x;
or 
short int x;

প্রধান পার্থক্যটি হ'ল শর্ট ইন্টি 2 বাইট মেমরি নেয় যখন ইন্টি 4 বাইট নেয় এবং শর্ট ইন্টের কম মান হয় তবে আমরা এটি এটিকে আরও ছোট করে তুলতে ডাকতে পারি:

int x;
short int x;
unsigned short int x;

যা আরও বেশি সীমাবদ্ধ।

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

c++ data-structures

— Bugster
সূত্র

3

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

— জিনাত

5

স্ট্যান্ডার্ড প্যাকিং / প্রান্তিককরণ সংকলক সেটিংস সহ, ভেরিয়েবলগুলি যাইহোক যাইহোক 4 বাইট সীমানায় সংযুক্ত করা হবে, যাতে কোনও পার্থক্যই নাও হতে পারে।

— নিকি

36

অকাল অপ্টিমাইজেশনের ক্লাসিক কেস।

— স্কার্ফ্রিজে

1

@ নিকি - এগুলি x86 প্রসেসরের 4 বাইট সীমানায় সংযুক্ত থাকতে পারে তবে এটি সাধারণভাবে সত্য নয়। এমএসপি 430 কোনও বাইট ঠিকানায় এবং অন্য কিছুর বাইট ঠিকানায় সমস্ত কিছু রাখে। আমি মনে করি AVR-32 এবং এআরএম কর্টেক্স-এম একই।

— uɐɪ

3

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

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

41

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

unsigned int salary;

আপনি অন্য বিকাশকারীকে একটি দরকারী টুকরো তথ্য দিচ্ছেন: বেতন নেতিবাচক হতে পারে না।

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

— Oleksi
সূত্র

5

এটি সত্য যে এটি আজকাল খুব কমই সমস্যা সৃষ্টি করতে চলেছে তবে আপনি যদি কোনও লাইব্রেরি বা কোনও শ্রেণি ডিজাইন করছেন যা অন্য বিকাশকারী ব্যবহার করবেন, তবে এটি অন্য একটি বিষয়। সম্ভবত তাদের এই মিলিয়ন মিলিয়ন অবজেক্টের জন্য স্টোরেজ প্রয়োজন হবে, এক্ষেত্রে পার্থক্য বড় - 4MB কেবল এই এক ক্ষেত্রের জন্য 2MB এর তুলনায়।

— dodgy_coder

30

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

— zvrba

15

@ জভ্রবা: দুটি বেতনের মধ্যে পার্থক্য নিজেই বেতন নয় এবং তাই স্বাক্ষরিত ভিন্ন ধরণের ব্যবহার বৈধ legitimate

— জেরেমিপি

12

@ জেরেমিপ হ্যাঁ তবে আপনি যদি সি ব্যবহার করছেন (এবং এটি সি ++ তেও সত্য বলে মনে হচ্ছে), স্বাক্ষরযুক্ত পূর্ণসংখ্যা বিয়োগের ফলে একটি স্বাক্ষরবিহীন অন্তর্ভুক্ত হয় যা নেতিবাচক হতে পারে না। আপনি যদি এটি কোনও স্বাক্ষরিত int এ কাস্ট করেন তবে এটি সঠিক মানে পরিণত হতে পারে, তবে গণনার ফলাফলটি একটি স্বাক্ষরবিহীন অন্তর্ভুক্ত। আরও দেখুন এই উত্তরটি আরো স্বাক্ষরিত / স্বাক্ষরবিহীন গণনার weirdness জন্য - যা তুমি কেন স্বাক্ষরবিহীন ভেরিয়েবল ব্যবহার না করা উচিত যদি না আপনি কি সত্যিই বিট twiddling করছি।

— টাকরোয়

5

@zvrba: পার্থক্যটি একটি আর্থিক পরিমাণ তবে বেতন নয়। এখন আপনি যুক্তি দিতে পারেন যে বেতনটিও একটি আর্থিক পরিমাণ (ধনাত্মক সংখ্যার জন্য সীমাবদ্ধ এবং 0 ইনপুট যা বেশিরভাগ লোকেরা যা করে তা বৈধ করে) তবে দুটি বেতনের মধ্যে পার্থক্য নিজেই বেতন নয়।

— জেরেমিপি

29

ওপিতে তারা যে ধরণের প্রোগ্রামের জন্য প্রোগ্রাম লিখছেন সে সম্পর্কে কিছুই বলেনি, তবে আমি ধরেই নিয়েছি যে সি ++ এর উল্লেখ থাকার পরে ওপি জিবি'র মেমরির একটি সাধারণ পিসির কথা ভাবছিল। যেমন একটি মন্তব্যে বলা হয়েছে, এমনকি সেই ধরণের মেমরির সাথেও যদি আপনার এক ধরণের কয়েক মিলিয়ন আইটেম থাকে - যেমন একটি অ্যারে - তবে ভেরিয়েবলের আকারটি একটি পার্থক্য আনতে পারে।

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

আমি বর্তমানে 32-বিট এমআইপিএস-ভিত্তিক মাইক্রোকন্ট্রোলারের সাথে আরও একটি এমবেডেড প্রকল্প করছি যাতে 512 কে বাইট ফ্ল্যাশ এবং 128 কে বাইট র‌্যাম রয়েছে (এবং পরিমাণটি প্রায় 6 ডলার)। পিসির মতো, "প্রাকৃতিক" ডেটা আকার 32-বিট। চর এবং শর্টসের পরিবর্তে বেশিরভাগ ভেরিয়েবলের জন্য ints ব্যবহার করা এখন কোডের ভিত্তিতে আরও দক্ষ। তবে আবারও, কোনও ধরণের অ্যারে বা কাঠামো বিবেচনা করে অবশ্যই ছোট ডেটা টাইপগুলি ওয়্যারেন্টেড কিনা তা বিবেচনা করতে হবে। বৃহত্তর সিস্টেমের জন্য কম্পাইলার ভিন্ন, এটি একটি কাঠামো সম্ভাবনা বেশি ভেরিয়েবল হল ইচ্ছার একটি এমবেডেড সিস্টেমে বস্তাবন্দী করা হবে। আমি সর্বদা সমস্ত 32-বিট ভেরিয়েবল প্রথমে রাখার চেষ্টা করি, তারপরে 16-বিট, তারপরে 8-বিট কোনও "গর্ত" এড়ানোর জন্য।

— tcrosley
সূত্র

10

এম্বেড থাকা সিস্টেমে বিভিন্ন বিধি প্রয়োগ হয় এই সত্যের জন্য +1। সি ++ উল্লেখ করা হয়েছে তার অর্থ এই নয় যে লক্ষ্যটি পিসি। আমার সাম্প্রতিক প্রজেক্টগুলির একটি সি 32+ র্যামের 32k এবং 256K ফ্ল্যাশ সহ একটি প্রসেসরে লেখা হয়েছিল।

— uɐɪ

13

উত্তরটি আপনার সিস্টেমে নির্ভর করে। সাধারণত, এখানে ছোট ধরণের ব্যবহারের সুবিধাগুলি এবং অসুবিধাগুলি রয়েছে:

সুবিধাদি

ছোট আকারের বেশিরভাগ সিস্টেমে কম মেমরি ব্যবহার করে।
ছোট ধরণের কিছু সিস্টেমে দ্রুত গণনা দেয়। বিশেষত ভাসমান বনাম বহু সিস্টেমে ডাবল জন্য বিশেষত সত্য। এবং ছোট ইনট টাইপগুলি 8- বা 16-বিট সিপিইউগুলিতে উল্লেখযোগ্যভাবে দ্রুত কোড দেয়।

অসুবিধেও

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

আমার পরামর্শ এটি পছন্দ করতে হয়:

system                             int types

small/low level embedded system    stdint.h with smaller types
32-bit embedded system             stdint.h, stick to int32_t and uint32_t.
32-bit desktop system              Only use (unsigned) int and long long.
64-bit system                      Only use (unsigned) int and long long.

অন্যথা, আপনি ব্যবহার করতে পারেন int_leastn_tবা int_fastn_tstdint.h, যেখানে n সংখ্যা 8, 16, 32 বা 64 থেকে int_leastn_tটাইপ মানে হলো "আমি এই অন্তত হতে চান এন বাইট কিন্তু আমি পরোয়া করি না যদি কম্পাইলার বরাদ্দ এটি হিসাবে প্রান্তিককরণ অনুসারে একটি বৃহত প্রকার "।

int_fastn_t এর অর্থ "আমি এটি এন বাইট দীর্ঘ হতে চাই, তবে এটি যদি আমার কোডটি দ্রুত চালিত হয় তবে সংকলকটি নির্দিষ্টের চেয়ে বড় ধরণের ব্যবহার করবে"।

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

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

— আলেক্সি

11

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

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

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

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

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

— S.Robins
সূত্র

6

যেমন স্কার্ফ্রিজ মন্তব্য করেছে, এটি একটি

অকাল অপ্টিমাইজেশনের ক্লাসিক কেস ।

মেমরির ব্যবহারের জন্য অপ্টিমাইজ করার চেষ্টা করা পারফরম্যান্সের অন্যান্য ক্ষেত্রেও প্রভাব ফেলতে পারে এবং অপ্টিমাইজেশনের সুবর্ণ নিয়মগুলি হ'ল :

প্রোগ্রাম অপ্টিমাইজেশনের প্রথম বিধি: এটি করবেন না ।

প্রোগ্রাম অপ্টিমাইজেশনের দ্বিতীয় বিধি (কেবল বিশেষজ্ঞদের জন্য!): এটি এখনও করবেন না "

- মাইকেল এ। জ্যাকসন

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

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

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

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

এই কারণে, আধুনিক সংকলকরা আপনার পরামর্শগুলি উপেক্ষা করে। নিকি মন্তব্য হিসাবে :

স্ট্যান্ডার্ড প্যাকিং / প্রান্তিককরণ সংকলক সেটিংস সহ, ভেরিয়েবলগুলি যাইহোক যাইহোক 4 বাইট সীমানায় সংযুক্ত করা হবে, যাতে কোনও পার্থক্যই নাও হতে পারে।

দ্বিতীয়টি আপনার সঙ্কটের সময়টি আপনার বিপদে পড়ুন at

টেরাবাইট ডেটাসেট বা এম্বেড থাকা মাইক্রো-কন্ট্রোলারগুলির সাথে কাজ করার সময়, এই ধরনের অপ্টিমাইজেশনের জন্য একটি জায়গা রয়েছে তবে আমাদের বেশিরভাগের পক্ষে এটি উদ্বেগের বিষয় নয়।

— মার্ক বুথ
সূত্র

3

প্রধান পার্থক্যটি হ'ল শর্ট ইন্টি 2 বাইট মেমরি নেয় যখন ইন্টি 4 বাইট নেয় এবং শর্ট ইন্টের কম মান হয় তবে আমরা এটি এটিকে আরও ছোট করে তুলতে ডাকতে পারি:

এটি ভুল। charএক প্রকার বাইট এবং বাইটে কমপক্ষে 8 বিট ব্যতীত প্রতিটি ধরণের আকার আগেরটির চেয়ে বড় বা সমান হওয়ায় আপনি প্রতি ধরণের কতগুলি বাইট ধারণ করেন সে সম্পর্কে ধারণা অনুমান করতে পারবেন না ।

পারফরম্যান্স সুবিধাগুলি স্ট্যাক ভেরিয়েবলের জন্য অবিশ্বাস্যভাবে বিয়োগাত্মক - সেগুলি সম্ভবত বিন্যস্ত / প্যাড করা হবে।

এ কারণে, shortএবং longআজকাল ব্যবহারিকভাবে কোনও ব্যবহার নেই এবং আপনি প্রায় সবসময় ব্যবহার করা ভাল int।

অবশ্যই, এটি stdint.hব্যবহার করার জন্য পুরোপুরি জরিমানা রয়েছে যা এটি intকাটা না। আপনি যদি কখনও পূর্ণসংখ্যার / স্ট্রাক্টগুলির বিশাল অ্যারে বরাদ্দ করেন তবে intX_tআপনি দক্ষ হতে পারেন এবং ধরণের আকারের উপর নির্ভর করতে পারেন বলে একটি ধারণা তৈরি হয়। এটি মোটেই অকাল নয় কারণ আপনি মেগাবাইটের স্মৃতি সংরক্ষণ করতে পারেন।

— Pubby
সূত্র

1

প্রকৃতপক্ষে, 64 বিট পরিবেশের আগমনের সাথে, এর longচেয়ে আলাদা হতে পারে int। যদি আপনার সংকলকটি এলপি 64 intহয়, 32 বিট হয় এবং long64 বিট হয় এবং আপনি intদেখতে পাবেন যে এখনও 4 বাইট সারিবদ্ধ হতে পারে (উদাহরণস্বরূপ আমার সংকলকটি করে)।

— জেরেমিপি

1

@ জেরেমিপ হ্যাঁ, আমি অন্যথায় কিছু বললাম বা কিছু?

— পাব্বি

আপনার শেষ বাক্যটি যা সংক্ষিপ্ত এবং দীর্ঘ দাবি করে তাদের ব্যবহারিকভাবে ব্যবহার হয় না। লং অবশ্যই একটি ব্যবহার আছে, যদি শুধুমাত্র বেস প্রকার হিসাবেint64_t

— জেরেমিপি

@ জেরেমিপি: আপনি ইনট এবং লম্বা লম্বাভাবে ঠিক থাকতে পারেন।

— gnasher729

@ gnasher729: আপনার যদি এমন একটি ভেরিয়েবলের প্রয়োজন হয় যা 65 হাজারেরও বেশি মান ধরে রাখতে পারে তবে বিলিয়ন হিসাবে কখনই নয়? int32_t, int_fast32_tএবং longসমস্ত ভাল বিকল্পগুলি long longহ'ল কেবল অপচয় এবং intঅ-বহনযোগ্য।

— বেন ভয়েগট

3

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

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

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

আমাদের DOMAIN সত্তাগুলি মডেল করতে অন্তর্নির্মিত প্রকারগুলি ব্যবহার করা কিছু অগোছালো কোড এবং কিছু মিস করা চেক এবং ভাঙা আক্রমণকারীগুলিকে সীমাবদ্ধ করতে বাধ্য। এমনকি যদি কোনও ধরণের সত্তার কিছু অংশ ক্যাপচার করে (negativeণাত্মক হতে পারে না) তবে তা অন্যকে মিস করতে বাধ্য (নির্বিচারে পাটিগণিতের এক্সপ্রেশনগুলিতে ব্যবহার করা যায় না, বিটের অ্যারে হিসাবে বিবেচনা করা যায় না ইত্যাদি))

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

— সারা
সূত্র

1

হ্যা অবশ্যই. uint_least8_tঅভিধান, বিশাল ধ্রুবক অ্যারে, বাফার ইত্যাদির জন্য ব্যবহার করা ভাল ধারণা যা uint_fast8_tপ্রক্রিয়াজাতকরণের উদ্দেশ্যে ব্যবহার করা ভাল ।

uint8_least_t(স্টোরেজ) -> uint8_fast_t(প্রক্রিয়াজাতকরণ) -> uint8_least_t(স্টোরেজ)।

উদাহরণস্বরূপ আপনি 8 বিট প্রতীক নিচ্ছেন source, 16 বিট কোড থেকে dictionariesএবং কিছু 32 বিট constants। চেয়ে আপনি তাদের সঙ্গে এবং 8 বিট আউটপুট 10-15 বিট অপারেশন প্রক্রিয়া করছি destination।

আসুন কল্পনা করুন যে আপনাকে 2 গিগাবাইট প্রসেস করতে হবে source। বিট পরিচালনার পরিমাণ বিশাল huge আপনি যদি প্রক্রিয়া চলাকালীন দ্রুত ধরণেরগুলিতে স্যুইচ করেন তবে আপনি দুর্দান্ত পারফরম্যান্স বোনাস পাবেন। প্রতিটি সিপিইউ পরিবারের জন্য দ্রুত প্রকারগুলি পৃথক হতে পারে। আপনি অন্তর্ভুক্ত করতে পারে stdint.hএবং ব্যবহার uint_fast8_t, uint_fast16_t, uint_fast32_t, ইত্যাদি

আপনি বহনযোগ্যতার জন্য uint_least8_tপরিবর্তে ব্যবহার করতে পারেন uint8_t। কিন্তু আধুনিক সিপিইউ এই বৈশিষ্ট্যটি কী ব্যবহার করবে তা আসলে কেউ জানে না। ভ্যাক মেশিন একটি জাদুঘর টুকরা। সুতরাং এটি একটি ওভারকিল।

— puchu
সূত্র

1

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

— পিটার এম