আসল কারণটি হ'ল একদিকে সি এবং সি ++, এবং অন্যদিকে জাভা এবং সি # (কেবলমাত্র কয়েকটি উদাহরণের জন্য) এর মধ্যে অভিপ্রায় একটি মৌলিক পার্থক্য to Historicalতিহাসিক কারণে, এখানে বেশিরভাগ আলোচনা সি ++ এর পরিবর্তে সি সম্পর্কে কথা বলে, তবে (আপনি সম্ভবত ইতিমধ্যে জানেন) সি ++ সি এর মোটামুটি প্রত্যক্ষ বংশধর, সুতরাং এটি সি সম্পর্কে যা বলে তা সি ++ তে সমানভাবে প্রযোজ্য।
যদিও এগুলি অনেকাংশেই ভুলে গেছে (এবং তাদের অস্তিত্ব কখনও কখনও অস্বীকারও করা হয়েছে), ইউএনআইএক্সের প্রথম সংস্করণগুলি সমাবেশ ভাষায় রচিত হয়েছিল। বেশিরভাগ (একমাত্র না হয়ে থাকলে) সি এর মূল উদ্দেশ্যটি ছিল ইউনিক্সের বন্দরটি ইউনিক্স ভাষা থেকে উচ্চতর স্তরের ভাষায়। অভিপ্রায়টির একটি অংশটি ছিল উচ্চতর স্তরের ভাষায় যতটা সম্ভব অপারেটিং সিস্টেমটি লিখতে - বা এটি অন্য দিক থেকে দেখে, সমাবেশের ভাষায় যে পরিমাণ রচনা লিখতে হয়েছিল তা হ্রাস করতে হবে min
এটি সম্পাদন করার জন্য সি এর সমাবেশের ভাষা যেমন হার্ডওয়্যারটিতে প্রায় একই স্তরের অ্যাক্সেস সরবরাহ করা প্রয়োজন। PDP-11 (একটি উদাহরণস্বরূপ) ম্যাপযুক্ত আই / ও নির্দিষ্ট ঠিকানাগুলিতে নিবন্ধভুক্ত। উদাহরণস্বরূপ, সিস্টেম কনসোলে কোনও কী চাপছে কিনা তা পরীক্ষা করতে আপনি একটি মেমরি অবস্থান পড়তেন। তথ্য পড়ার জন্য অপেক্ষা করার সময় সেই স্থানে একটি বিট সেট করা হয়েছিল। তারপরে চাপানো কীটির ASCII কোডটি পুনরুদ্ধার করতে আপনি অন্য নির্দিষ্ট অবস্থান থেকে একটি বাইট পড়তে চাইবেন।
তেমনিভাবে, আপনি যদি কিছু ডেটা মুদ্রণ করতে চান, আপনি অন্য একটি নির্দিষ্ট অবস্থান পরীক্ষা করে দেখতে পারেন এবং যখন আউটপুট ডিভাইস প্রস্তুত ছিল, আপনি নিজের ডেটা অন্য নির্দিষ্ট নির্দিষ্ট জায়গায় লিখবেন।
এই জাতীয় ডিভাইসগুলির জন্য ড্রাইভার লেখার পক্ষে সমর্থন করার জন্য, সি আপনাকে কিছু পূর্ণসংখ্যার প্রকার ব্যবহার করে একটি স্বেচ্ছাসেবীর অবস্থান নির্দিষ্ট করতে, পয়েন্টারে রূপান্তর করতে এবং মেমোরিতে সেই অবস্থানটি পড়তে বা লিখতে অনুমতি দেয়।
অবশ্যই, এটি একটি বেশ গুরুতর সমস্যা: পৃথিবীর প্রতিটি মেশিনের স্মৃতি 1970 সালের দশকের প্রথম থেকেই পিডিপি -11 এর সাথে একইভাবে ছড়িয়ে যায় না। সুতরাং, আপনি যখন পূর্ণসংখ্যাটি গ্রহণ করবেন, এটিকে একটি পয়েন্টারে রূপান্তর করুন এবং তারপরে সেই পয়েন্টারটির মাধ্যমে পড়ুন বা লিখুন, আপনি কী পাচ্ছেন সে সম্পর্কে কেউ কোনও যুক্তিসঙ্গত গ্যারান্টি সরবরাহ করতে পারে না। কেবল একটি সুস্পষ্ট উদাহরণের জন্য, পড়া এবং লেখা হার্ডওয়্যারে আলাদা আলাদা রেজিস্টার করতে মানচিত্র তৈরি করতে পারে, তাই আপনি (সাধারণ স্মৃতির বিপরীতে) যদি আপনি কিছু লিখেন তবে তা আবার পড়ার চেষ্টা করুন, আপনি যা পড়েছেন তা আপনার লেখার সাথে মেলে না।
আমি কয়েকটি সম্ভাবনা দেখতে পাচ্ছি যা ছেড়ে যায়:
- সমস্ত সম্ভাব্য হার্ডওয়ারের জন্য একটি ইন্টারফেস সংজ্ঞায়িত করুন - যে কোনও স্থানে হার্ডওয়্যারের সাথে ইন্টারঅ্যাক্ট করতে আপনি পড়তে বা লিখতে চাইতে পারেন এমন সমস্ত অবস্থানের নিখুঁত ঠিকানা উল্লেখ করুন।
- অ্যাক্সেসের সেই স্তরটি নিষিদ্ধ করুন এবং ডিক্রি করুন যে যে কেউ এই জাতীয় কাজ করতে চান তাদের সমাবেশ ভাষা ব্যবহার করা উচিত।
- লোকেরা এটি করার অনুমতি দিন, তবে তারা যে হার্ডওয়্যারটি টার্গেট করছেন তার ম্যানুয়ালগুলি পড়ার জন্য তাদের কাছে ছেড়ে দিন (উদাহরণস্বরূপ) এবং তারা যে হার্ডওয়্যারটি ব্যবহার করছেন সেটি ফিট করার জন্য কোডটি লিখুন।
এর মধ্যে ১ টি যথেষ্ট উদ্বেগজনক বলে মনে হচ্ছে এটি আরও আলোচনার জন্য খুব কমই। 2 মূলত ভাষার মূল অভিপ্রায় ফেলে দিচ্ছে। এটি তৃতীয় বিকল্পকে মূলত কেবলমাত্র একমাত্র তারা যুক্তিসঙ্গত বিবেচনা করতে পারে হিসাবে ছেড়ে দেয়।
আর একটি বিষয় যা প্রায়শই প্রায়শই আসে তা হ'ল পূর্ণসংখ্যার ধরণের আকার। সি "অবস্থান" নেয় intযা আর্কিটেকচারের প্রস্তাবিত প্রাকৃতিক আকার হওয়া উচিত। সুতরাং, যদি আমি একটি 32-বিট ভ্যাক্স প্রোগ্রামিং করছি, intসম্ভবত 32 বিট হওয়া উচিত, তবে আমি যদি 36-বিট ইউনিভ্যাক প্রোগ্রামিং করছি তবে intসম্ভবত 36 বিট (এবং আরও কিছু) হওয়া উচিত। ৮ বিট কম্পিউটারের জন্য অপারেটিং সিস্টেম লিখতে সম্ভবত যুক্তিসঙ্গত নয় (কেবলমাত্র 8 বিটের আকারের গ্যারান্টিযুক্ত এমন প্রকারগুলি ব্যবহার করে) computer হতে পারে আমি কেবলমাত্র মাত্রাতিরিক্ত হয়ে উঠছি, তবে আমার কাছে মনে হয় যে আমি যদি ৩ 36-বিট মেশিনের জন্য একটি ওএস লিখছিলাম, তবে আমি সম্ভবত একটি ভাষা ব্যবহার করতে চাই যা ৩ that-বিট টাইপের সমর্থন করে।
ভাষার দৃষ্টিকোণ থেকে এটি আরও বেশি সংজ্ঞায়িত আচরণের দিকে পরিচালিত করে। আমি যদি 32 টি বিটের সাথে মানানসই সবচেয়ে বড় মানটি গ্রহণ করি তবে আমি 1 যুক্ত করলে কী হবে? সাধারণ 32-বিট হার্ডওয়ারে, এটি গড়িয়ে যাচ্ছে (বা সম্ভবত কোনও ধরণের হার্ডওয়্যার ত্রুটি নিক্ষেপ করবে)। অন্যদিকে, এটি যদি 36-বিট হার্ডওয়ারে চলতে থাকে তবে এটি কেবল ... যুক্ত করবে। ভাষা যদি অপারেটিং সিস্টেমগুলি লেখার পক্ষে সমর্থন করে, আপনি উভয়ই আচরণের গ্যারান্টি দিতে পারবেন না - আপনাকে প্রায় উভয় আকারের আকার এবং ওভারফ্লো এর আচরণকে একে অপরকে পরিবর্তিত করতে দেওয়া উচিত।
জাভা এবং সি # এগুলি সব উপেক্ষা করতে পারে। তারা অপারেটিং সিস্টেম রাইটিং সমর্থন করার উদ্দেশ্যে নয়। তাদের সাথে, আপনার কয়েকটি পছন্দ আছে। একটি হ'ল হার্ডওয়্যারকে যা দাবি করা হয় সেগুলি সমর্থন করা - যেহেতু তারা 8, 16, 32 এবং 64 বিট জাতীয় প্রকারের দাবি করে, কেবল সেই আকারগুলি সমর্থন করে এমন হার্ডওয়্যার তৈরি করুন। অন্যান্য স্পষ্টত সম্ভাবনাটি হ'ল অন্তর্নিহিত হার্ডওয়্যারটি যা चाहे তা বিবেচনা না করেই কেবল ভাষাটিকে অন্য যে সফ্টওয়্যার দ্বারা তারা যে পরিবেশ চায় সেগুলি সরবরাহ করে top
বেশিরভাগ ক্ষেত্রে, এটি সত্যিই কোনও / বা পছন্দ নয়। বরং অনেক বাস্তবায়ন উভয়ই কিছুটা করে। আপনি সাধারণত কোনও অপারেটিং সিস্টেমে একটি জেভিএম চলমান জাভা চালান। প্রায়শই না করা যায় না, ওএস সি-তে লেখা হয়, এবং সি ++ তে জেভিএম। যদি জেভিএম কোনও এআরএম সিপিইউতে চলমান থাকে, তবে জাভার প্রয়োজনীয়তার সাথে হার্ডওয়ারটি আরও ঘনিষ্ঠভাবে তৈরি করার জন্য সিপিইউতে আর্মের জাজেল এক্সটেনশনগুলি অন্তর্ভুক্ত করার সম্ভাবনা খুব ভাল pretty তাই সফ্টওয়্যারটিতে কম কাজ করা দরকার, এবং জাভা কোডটি দ্রুত চলবে (বা কম) আস্তে আস্তে, যাইহোক)।
সারাংশ
সি এবং সি ++ এর অপরিবর্তিত আচরণ রয়েছে, কারণ কেউ গ্রহণযোগ্য বিকল্পকে সংজ্ঞায়িত করেনি যা তাদের যা করতে ইচ্ছা করছে তা করার অনুমতি দেয়। সি # এবং জাভা পৃথক পদ্ধতি গ্রহণ করে, তবে সেই পদ্ধতিটি সি এবং সি ++ এর লক্ষ্যগুলির সাথে খারাপভাবে (যদি হয় তবে) ফিট করে। বিশেষত, বেশিরভাগ নির্বিচারে বেছে নেওয়া হার্ডওয়্যারগুলিতে সিস্টেম সফ্টওয়্যার (যেমন একটি অপারেটিং সিস্টেম) রচনার জন্য কোনও যুক্তিসঙ্গত উপায় সরবরাহ করে না বলে মনে হয়। উভয়ই তাদের কাজটি করার জন্য বিদ্যমান সিস্টেম সফ্টওয়্যার (সাধারণত সি বা সি ++ তে লিখিত) সরবরাহিত সুবিধার উপর নির্ভর করে।