ওহ হ্যাঁ, এটি ব্যবহৃত হয়। আমি নেটওয়ার্ক প্যাকেট প্রসেসিংয়ের ক্ষেত্রে কাজ করি। আমি দুটি পৃথক সংস্থায় ছিলাম যেখানে আমরা নেটওয়ার্ক প্যাকেটগুলি প্রক্রিয়া করি। সুতরাং, আমরা ইথারনেট বা আইপি স্তরে অপারেশন করছি, টিসিপির উপরের স্তরে নয়।
মজার বিষয় হল, উভয় সংস্থায় সি ++ এর চেয়ে বেশি নির্বাচিত হয়েছিল। একটি কোম্পানির মধ্যে, দুটি পণ্যগুলির মধ্যে একটি লিনাক্স কার্নেলের শীর্ষে নির্মিত হয়েছিল, অন্য পণ্যটি লিনাক্স ব্যবহারকারী স্পেসে নির্মিত হয়েছিল। লিনাক্স কার্নেল হিসাবে সিটিতে কার্নেল পণ্যটি অবশ্যই স্পষ্টভাবে ব্যবহৃত হয়েছিল, তবে তারা ব্যবহারকারী স্থানের পণ্যটির জন্যও সি ব্যবহার করতে পছন্দ করেছিল। উভয় পণ্যই প্রায় 2000 সাল থেকে শুরু হয়েছিল (2000 এর কিছু আগে কার্নেল পণ্য এবং 2000 এর পরে ইউজারস্পেস পণ্য)।
আমি তার পরে যে সংস্থায় গিয়েছিলাম, সেখানে পণ্যটি সি -+ তে নয়, সি-তে নির্মিত হয়েছিল। এটি আসলে ১৯৯০ এর দশকের মাঝামাঝি থেকে একটি প্রকল্পের ধারাবাহিকতা, যদিও সাম্প্রতিক পারফরম্যান্স উন্নতির দাবিগুলির কারণে, সিদ্ধান্ত নেওয়া হয়েছিল যে মূলত সবকিছুই আবার লেখা হবে। এই পুনর্লিখনের কারণে আমাদের কাছে সি ++ নির্বাচন করার বিকল্প ছিল, কিন্তু তা হয়নি।
নেটওয়ার্ক প্যাকেট প্রক্রিয়াজাতকরণের ক্ষেত্রে কর্মক্ষমতা অনেক বেশি গণনা করে। সুতরাং, আমি আমার নিজের হ্যাশ টেবিলটি বিদ্যমান হ্যাশ টেবিলের চেয়ে উচ্চতর পারফরম্যান্সের সাথে প্রয়োগ করতে চাই। আমি, হ্যাশ টেবিল লেখক নই, আমি হ্যাশ ফাংশনটি কী ব্যবহার করতে হবে তা নির্বাচন করে। সম্ভবত আমি পারফরম্যান্স চাই এবং মারমুরহ্যাশ 3 এর জন্য যাই । সম্ভবত আমি সুরক্ষা চাই এবং সিপহ্যাশের উদ্দেশ্যে যাই । মেমরি বরাদ্দকারীরা অবশ্যই কাস্টম। প্রকৃতপক্ষে, আমরা ব্যবহার করি এমন সমস্ত গুরুত্বপূর্ণ ডেটা স্ট্রাকচারগুলি সর্বোচ্চ সম্ভাব্য পারফরম্যান্সের জন্য কাস্টম-প্রয়োগ করা হয়েছে।
যদিও সি ++ এর ব্যবহার প্রতিরোধ করতে পারে এমন কিছুই নেই তবে এটি সাধারণত একটি খারাপ ধারণা। প্যাকেট প্রতি একক নিক্ষিপ্ত ব্যতিক্রম প্যাকেট প্রক্রিয়াকরণের হার অগ্রহণযোগ্য পর্যায়ে ফেলে দেবে! সুতরাং, আমরা সি ++ এর ব্যতিক্রমগুলি ব্যবহার করতে পারি না। উপায় খুব ধীর। আমরা ইতিমধ্যে ধরনের স্ট্রাক্ট হিসাবে ডেটা স্ট্রাকচার প্রয়োগ করে এবং তারপরে সেই স্ট্রাক্টগুলিতে অপারেটিং ফাংশনগুলি বাস্তবায়ন করে ধরণের অবজেক্ট-ওরিয়েন্টেড সি কোড ব্যবহার করছি। সি ++ ভার্চুয়াল ফাংশনগুলি রাখার অনুমতি দেয়, তবে তারপরে আবার ভার্চুয়াল ফাংশন কলগুলি সর্বত্র ব্যবহৃত হলে পারফরম্যান্স হ্রাস করে। সুতরাং, ভার্চুয়াল ফাংশন কলগুলির প্রয়োজন হলে সুস্পষ্ট হওয়া এবং একটি ফাংশন পয়েন্টার থাকা ভাল।
সি ++ আপনার পিছনের পিছনে অনেক কিছুই করবে: মেমরির বরাদ্দ ইত্যাদি, অন্যদিকে, সিতে যা সাধারণত ঘটে না। আপনি একটি ফাংশন লিখতে পারেন যা মেমরি বরাদ্দ করে, তবে সাধারণত এটি ফাংশনের ইন্টারফেস থেকে স্পষ্ট হয় যে বরাদ্দ হচ্ছে।
সি তে প্রোগ্রামিং করার সময় আপনি যে ধরণের মাইক্রো অপটিমাইজেশন করতে পারেন তা উদাহরণ হিসাবে, লিনাক্স কার্নেলের কনটেইনার_ম্যাক্রোটি দেখুন। অবশ্যই, আপনি সি ++ কোডে ধারক_ও ব্যবহার করতে পারেন, তবে কে তা করে? আমি বলতে চাইছি, বেশিরভাগ সি প্রোগ্রামগুলিতে এটি সম্পূর্ণরূপে গ্রহণযোগ্য তবে সাধারণত সি ++ প্রোগ্রামাররা তাত্ক্ষণিকভাবে অন্য কিছু প্রস্তাব করতে পারে যেমন লিঙ্ক নোডকে আলাদা ব্লক হিসাবে বরাদ্দ করে। আমরা তা চাই না কারণ প্রতিটি বরাদ্দকৃত মেমরি ব্লক কার্য সম্পাদনের জন্য খারাপ।
আমাদের কেবলমাত্র C ++ এ উপকার হবে তা হ'ল সি ++ টেমপ্লেট মেটাগ্রোগ্রামিংয়ের অনুমতি দেয়, এর অর্থ আপনি কোনও ফাংশন প্যারামিটার থাকা অবস্থায় কখনও কখনও ভার্চুয়াল ফাংশন কলগুলি এড়াতে পারবেন এবং সংকলকটিকে ফাংশনগুলি ইনলাইন করার অনুমতি দিন। তবে টেমপ্লেট রূপান্তর জটিল, এবং আমরা সিতে সমস্ত প্রয়োজনীয়তা পূরণ করতে পরিচালিত করেছি, সুতরাং সি ++ এ এই বৈশিষ্ট্যটির সুবিধাটি এতটা সমালোচনামূলক নয়।
কোনও একটি সংস্থায়, আমাদের আসলে একটি কাস্টম সংকলিত ভাষা ছিল যেখানে বৈশিষ্ট্যগুলির অংশটি বাস্তবায়িত হয়েছিল ess অনুমান করুন যে সংকলকটির লক্ষ্য ভাষাটি ছিল? পরিষদের? না, আমাদের 32-বিট এবং 64-বিট উভয়ই আর্কিটেকচার সমর্থন করতে হয়েছিল। সি ++? নিশ্চয়ই তামাশা স্পষ্টতই, এটি ছিল জিসিসির গণিত গোটোতে সি । সুতরাং, কাস্টম ভাষা সিতে সংকলিত হয়েছিল (বা আসলে গ এর গিসি ভেরিয়েন্ট যা গণিত গোটো সমর্থন করে), এবং সি সংকলক উত্পাদন করে সমাবেশ।