সি ++ ডি এর চেয়ে আরও ভাল কি করে?


135

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

আমি ডি পছন্দ করি এটি একটি দুর্দান্ত ভাষা, কিছু উপায়ে, সি-তে একটি বিশাল আপডেট এবং সুন্দরভাবে সম্পন্ন হয়েছে। কোনও বৈশিষ্ট্যই "বোল্ট অন" বলে মনে হয় না তবে বাস্তবে বেশ সুচিন্তিত এবং সুনির্দিষ্টভাবে নকশাকৃত।

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

নিজে, আমি সি জানার সময়, আমি বলতে পারি না যে আমি সি ++ জানি। আমি C ++ এবং D উভয়ই জানা কারও কাছ থেকে শুনতে চাই যে তারা যদি মনে করে যে ভাষা হিসাবে সি এর চেয়ে আরও ভাল কিছু রয়েছে যা (সাধারণত "এর তৃতীয় পক্ষের লাইব্রেরিগুলি বেশি না" বা "আরও সংস্থান আছে" বা " D এর চেয়ে বেশি C ++ প্রয়োজন বেশি চাকরির জন্য ") উপস্থিত রয়েছে।

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

এছাড়াও, নোট করুন যে আমি ডি 2.0 সম্পর্কে কথা বলছি , ডি 1.0 এর কথা নয় ।


15
আমি নিশ্চিত করেছি যে ডি সম্প্রদায় এটি দেখতে পাবে কারণ আমি নিশ্চিত যে এখানে প্রায় ডি ডিভাসের চেয়ে অনেক বেশি সি ++ ডিভ রয়েছে। এইভাবে আপনার কাছে আরও আকর্ষণীয় বা কমপক্ষে বিচিত্র উত্তর থাকবে।
ক্লাইম

7
এছাড়াও, ডি 2 ওয়াল্টার ব্রাইট ডিজাইন করেছিলেন তবে আলেকজান্দ্রেস্কুর সাথেও। আপনি আপনার প্রশ্নে এটি ঠিক করতে চাইতে পারেন।
ক্লাইম

2
@ ক্লেইম: ডি এবং স্ট্যান্ডার্ড লাইব্রেরিতে অনেক সম্প্রদায় জড়িত ছিল (এবং এখনও রয়েছে)।
মিশাল মিনিচ

28
@ ভাষা হিসাবে, আপনাকে প্রোগ্রামার বানানোর ক্ষেত্রে সি ++ ডি থেকে অনেক ভাল, আপনার জীবনকে ঘৃণা করে।
অ্যারলেন

6
@jokoon: বাস্তবিক, হ্যাঁ, খুব সামান্য কাজে: digitalmars.com/d/2.0/interfaceToC.html
Anto

উত্তর:


124

ডি + এর চেয়ে সি ++ "বেশিরভাগ জিনিসগুলি মেটা জিনিসগুলি: সি ++ এর রয়েছে আরও ভাল সংকলক, আরও ভাল সরঞ্জাম, আরও পরিপক্ক গ্রন্থাগার, আরও বেশি বাইন্ডিং, আরও বিশেষজ্ঞ, আরও টিউটোরিয়াল ইত্যাদি Bas আরও পরিপক্ক ভাষা থেকে আশা করবে। এটি অনাবাদী।

ভাষা নিজেই হিসাবে, আমার মতে ডি এর চেয়ে সি ++ আরও ভাল কিছু করতে পারে। সম্ভবত আরও কিছু আছে, তবে আমি এখানে আমার মাথার উপরের অংশটি তালিকায় রাখতে পারি যে কয়েকটি:

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

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

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

নোট করুন যে সি ++ এর কিছু টাইপ সিস্টেম ওয়ার্ট রয়েছে (যেমন নন-ট্রানজিটিভ কনস্ট, iteratorপাশাপাশি প্রয়োজনীয় const_iterator) যা এটি একেবারেই কুৎসিত করে তোলে, তবে সি ++ এর টাইপ সিস্টেমটি কিছুটা ভুল হলেও এটি আপনাকে ডি এর মতো কাজ করতে বাধা দেয় না it কখনও কখনও না।

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

ডি কখনও কখনও সামান্য সুবিধাজনক হয় এমন
একটি সমালোচনা যা আপনি প্রায়শই সি ++ এর সম্পর্কে শুনে থাকেন তা হ'ল এটি আপনার কাছ থেকে কিছু নিম্ন-স্তরের সমস্যাগুলি গোপন করে simple যেমন সরল অ্যাসাইনমেন্ট যেমন a = b;রূপান্তর অপারেটরদের কল করা, ওভারলোড অ্যাসাইনমেন্ট অপারেটরদের কল করা ইত্যাদি অনেক কিছুই করতে পারে যা হতে পারে which কোড থেকে দেখতে কঠিন। কিছু লোক এটি পছন্দ করে, কিছু লোক তা করে না। উভয় ক্ষেত্রেই, D এর এটা খারাপ (ভাল?) ভালো জিনিস কারণে opDispatch, @property, opApply, lazyযা সম্ভাব্য বিষয় আছে যা আপনি আশা করবেন না বা নির্দোষ খুঁজছেন কোড পরিবর্তন করতে হবে।

আমি ব্যক্তিগতভাবে এটি একটি বড় সমস্যা বলে মনে করি না, তবে কারও কারও কাছে এটি অফ-পটিং হতে পারে।

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

ডি বরাদ্দ মেমরির মধ্যে নিষ্পাপ অ্যারের সংজ্ঞাগুলি
এটি আমার একটি পোষা প্রাণবন্ত:

int[3] a = [1, 2, 3]; // in D, this allocates then copies
int a[3] = {1, 2, 3}; // in C++, this doesn't allocate

স্পষ্টতই, ডি-তে বরাদ্দ এড়াতে, আপনাকে অবশ্যই:

static const int[3] staticA = [1, 2, 3]; // in data segment
int[3] a = staticA; // non-allocating copy

এই সামান্য 'আপনার পিছনে পিছনে' বরাদ্দগুলি আমার আগের দুটি পয়েন্টের ভাল উদাহরণ।

সম্পাদনা: দ্রষ্টব্য যে এটি একটি জ্ঞাত সমস্যা যা নিয়ে কাজ করা হচ্ছে।
সম্পাদনা: এটি এখন ঠিক করা হয়েছে। কোন বরাদ্দ স্থান নেয়।

উপসংহার
আমি ডি বনাম সি ++ এর নেতিবাচক দিকে মনোনিবেশ করেছি কারণ প্রশ্নটিই তাই বলেছিল, তবে দয়া করে এই পোস্টটি ডি-র চেয়ে সি +++++++++++++++++++++++++++++++++++++++ ডি ডি থেকে সি +++++++++++++++++++++++++++++++++++++> D + C +++ সি ++ এর চেয়ে বেশি। কোনটি ব্যবহার করবেন তার সিদ্ধান্ত নেওয়া আপনার পক্ষে।


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

3
আপনি এখনও নিম্ন-স্তরের কোডের জন্য জিসি অক্ষম করতে পারেন - পিটার বলছেন যে ভাষা বর্তমানে এটির উপর অনেক বেশি নির্ভর করে। এছাড়াও, আপনি জিসিকে তার এপিআই: কোর.মেমোরি থেকে GC.addRange ব্যবহার করে তার পরিচালিত হিপের বাইরে রেঞ্জগুলি স্ক্যান করতে বলতে পারেন ।
ভ্লাদিমির পানতেলিভ

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

132

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

মোটামুটি, সি ++ (এবং এর অর্থ আমি সি ++ ২০১১) ডি থেকে কী আরও ভাল করে তা জিজ্ঞাসা করা এই প্রশ্নের মতোই স্ববিরোধী, "আপনি যদি নিজের ঘর পরিষ্কার করার জন্য কোনও পেশাদারকে অর্থ প্রদান করেন তবে তারা কোথায় চলে যাবে? আগের চেয়ে নিবিড়? " সি ++ ডি যে পারেনি তা যে মূল্যবান ছিল তা হ'ল, এটি সর্বদা আমার এবং ওয়ালটারের কাছে এক কালশিটে থাম্বের মতো দাঁড়িয়েছিল, তাই প্রায় সংজ্ঞা অনুসারে সি ++ এর কিছুই নেই যা ডি এর নাগালের মধ্যে নয়।

ভাষা নকশায় খুব কমই বোঝা যায় এমন একটি জিনিস (কারণ খুব কম লোকের ভাগ্য আসলে কিছু করার থাকে) তা হ'ল এটির তুলনায় কম অরফোরড ত্রুটি রয়েছে। আমাদের মধ্যে অনেক ভাষা ব্যবহারকারীরাই কোনও না কোনও নির্মাণ বা অন্যটির দিকে তাকিয়ে বলে, "ইও! এটি এত ভুল! তারা কী ভাবছিল?" বিষয়টির সত্যতা হ'ল যে কোনও ভাষার বেশিরভাগ বিশ্রীকর দৃষ্টান্তগুলি কয়েকটি মৌলিক সিদ্ধান্তের পরে ঘটে যা সবগুলি সুস্পষ্ট এবং কাঙ্ক্ষিত তবে মৌলিকভাবে প্রতিদ্বন্দ্বিতা করে বা একে অপরের সাথে বিরোধিতা করে (যেমন: মডুলারালিটি এবং দক্ষতা, স্বল্পতা এবং নিয়ন্ত্রণ ইত্যাদি)।

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

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

  2. ডি অস্পষ্ট-লিঙ্গ প্রকারগুলি অস্বীকার করে (এটি সিদ্ধান্ত নিতে পারে না যে তারা মান বা রেফারেন্স ধরণের কিনা)। এই জাতীয় ডিজাইনগুলি সর্বসম্মতভাবে সি ++ এ সরিয়ে দেওয়া হয় এবং প্রায় সর্বদা ভুল, তবে এর মধ্যে কিছু প্রযুক্তিগতভাবে সঠিক। আমরা এই পছন্দটি তৈরি করেছি কারণ এটি বেশিরভাগ ভুল কোড এবং কেবলমাত্র একটি ছোট ভগ্নাংশের সঠিক কোডকেই আবার অস্বীকার করে। আমরা বিশ্বাস করি এটি একটি ভাল বাণিজ্য।

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

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

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

এক বা দুটি ছোট জিনিস হতে পারে, তবে সামগ্রিকভাবে এটি হওয়া উচিত।


6
@ ডিডএমজি: এর জন্য সি ++ এ কাজ করার জন্য, যে বস্তুটি সরানো হচ্ছে তার জন্য বস্তুটির দিকে নির্দেশ করার জন্য একটি ব্যাক পয়েন্টার প্রয়োজন হবে (যাতে এটি অনুলিপি তৈরির সময় আপডেট হতে পারে)। যদি এটি হয় তবে ডি তে আপনি পোস্টব্লিট কনস্ট্রাক্টর ব্যবহার করে পয়েন্টারটিকে আপডেট করতে পারেন way আপনার যদি কেবল এটির একটি পাসিং জ্ঞান থাকে তবে দয়া করে ডি এর বিরুদ্ধে তর্ক করবেন না।
পিটার আলেকজান্ডার

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

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

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

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

65

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

প্রকৃতপক্ষে, ভাষা হিসাবে সি ++ কেন ডি-এর চেয়ে ভাল, তার কারণগুলি নিয়ে আসার জন্য আমাকে সত্যই আমার মস্তিষ্ককে আবৃত করতে হবে যা সাধারণত মনে আসে যা হ'ল ট্রেড অফের বিষয়।

  1. কারণ ডি এর const সকর্মক, এবং কারণ ভাষা রয়েছে অপরিবর্তনীয় , এটা চেয়ে অনেক শক্তিশালী গ্যারান্টী আছে সি ++ এর const, যার মানে ডি না এবং করতে পারে না আছে mutableএটিতে লজিক্যাল কনস্ট থাকতে পারে না । সুতরাং, আপনি ডি এর কনস্ট সিস্টেমের মাধ্যমে একটি বিশাল লাভ পাবেন তবে কিছু পরিস্থিতিতে আপনি কেবল constসি ++ তে ব্যবহার করতে পারবেন না ।

  2. ডিতে একটি মাত্র কাস্ট অপারেটর রয়েছে, যেখানে সি ++ এর মধ্যে 4 (5 টি আপনি যদি সি কাস্ট অপারেটর গণনা করেন)। এটি সাধারণ ক্ষেত্রে ডি-তে ক্যাসেটগুলি মোকাবেলা করা সহজ করে তোলে, তবে আপনি যখন অতিরিক্ত জটিলতা / সুবিধাগুলি এবং তার ভাইয়েরা প্রদত্ত চান তখন সমস্যা হয় proble const_castতবে ডি আসলেই যথেষ্ট শক্তিশালী যে আপনি সি ++ এর ক্যাসেটগুলি প্রয়োগ করতে টেমপ্লেটগুলি ব্যবহার করতে পারেন, তাই আপনি যদি সত্যিই সেগুলি চান তবে আপনার সেগুলি থাকতে পারে (এবং তারা ডি-এর স্ট্যান্ডার্ড লাইব্রেরিতে কিছুটা হলেও শেষ হতে পারে)।

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

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

  5. জাভা এবং সি # এর মতো ডি'র একাধিক উত্তরাধিকারের পরিবর্তে একক উত্তরাধিকার রয়েছে তবে জাভা এবং সি # এর বিপরীতে এটি আপনাকে সি ++ এর একাধিক উত্তরাধিকার যাবতীয় সমস্যা (এবং সি +++ এর একাধিক উত্তরাধিকার খুব অগোছালো পেতে পারে) সমস্ত সমস্যা ছাড়াই একই প্রভাব পেতে কিছু চমত্কার উপায় দেয় সময়ে)। শুধু ডি আছে ইন্টারফেসগুলি , কিন্তু এটা হয়েছে স্ট্রিং mixins , টেমপ্লেট mixins এবং ওরফে এই । সুতরাং, চূড়ান্ত ফলাফলটি তর্কযোগ্যভাবে আরও শক্তিশালী এবং সি ++ এর একাধিক উত্তরাধিকারের মতো সমস্ত সমস্যা নেই।

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

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

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

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

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

  1. ডি শর্তসাপেক্ষ সংকলন আছে । আমি সি ++ তে প্রোগ্রামিং করার সময় এটি এমন একটি বৈশিষ্ট্য যা আমি ঘন ঘন মিস করি। যদি সি ++ এটি যুক্ত করে, তবে টেমপ্লেটগুলির মতো স্টাফের বিষয়টি যখন আসে তখন সি ++ লাফিয়ে ও সীমার দ্বারা উন্নত হয়।

  2. ডি সংকলন-সময় প্রতিবিম্ব আছে

  3. চলকগুলি ডিফল্টরূপে থ্রেড-স্থানীয় হয় sharedতবে আপনি যদি সেগুলি চান তা হতে পারে। এই থ্রেড সঙ্গে তার আচরণ তোলে পর্যন্ত সি ++ তুলনায় ক্লিনার। আপনি সম্পূর্ণ নিয়ন্ত্রণে আছেন। থ্রেডগুলির মধ্যে যোগাযোগের জন্য আপনি ব্যবহার করতে পারেন immutableএবং বার্তা প্রেরণ করতে পারেন , বা আপনি ভেরিয়েবলগুলি তৈরি করতে পারেন sharedএবং এটি মুটিক্স এবং শর্ত ভেরিয়েবলের মাধ্যমে C ++ উপায়ে করতে পারেন । এমনকি এটি সিঙ্ক্রোনাইজড (সি # এবং জাভার অনুরূপ) প্রবর্তনের সাথে সি ++ এর উপরে উন্নত । সুতরাং, ডি এর থ্রেডিংয়ের পরিস্থিতি সি ++ এর চেয়ে অনেক ভাল।

  4. ডি এর টেম্পলেটগুলি সি ++ এর টেম্পলেটগুলির চেয়ে অনেক বেশি শক্তিশালী, আপনাকে আরও অনেক সহজেই আরও অনেক সহজে করার অনুমতি দেয়। আর টেমপ্লেট সীমাবদ্ধতার যোগে, ত্রুটি বার্তা পাঠায় নি উপায় চেয়ে তারা সি হয় ++, ভাল। ডি টেমপ্লেটগুলি খুব শক্তিশালী এবং ব্যবহারযোগ্য করে তোলে। এটি কোনও কাকতালীয় ঘটনা নয় যে আধুনিক সি ++ ডিজাইনের লেখক ডি এর অন্যতম প্রধান সহযোগী। আমি ডি টেম্পলেটগুলির তুলনায় সি ++ টেমপ্লেটগুলির গুরুত্ব সহকারে অভাব বোধ করছি এবং সি ++ এ প্রোগ্রামিং করার সময় এটি খুব হতাশার হতে পারে।

  5. ডি অন্তর্নির্মিত চুক্তি প্রোগ্রামিং আছে

  6. ডি এর অন্তর্নির্মিত ইউনিট পরীক্ষার কাঠামো রয়েছে।

  7. string(ইউটিএফ -8), wstring(ইউটিএফ -16), এবং dstring(ইউটিএফ -32) দিয়ে ইউনিকোডের জন্য ডি অন্তর্নির্মিত সমর্থন করেছে । এটি ইউনিকোড মোকাবেলা করা সহজ করে তোলে। এবং আপনি যদি stringইউনিকোড সম্পর্কে সবেমাত্র ব্যবহার করতে এবং উদ্বেগ প্রকাশ করতে না চান তবে আপনি করতে পারেন - যদিও ইউনিকোডের মূল বিষয়গুলি সম্পর্কে কিছুটা বোঝা স্ট্যান্ডার্ড লাইব্রেরির কয়েকটি কার্যক্রমে সহায়তা করে।

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

  9. ডি এর অ্যারেগুলি সি ++ এর অ্যারেগুলির চেয়ে অনেক বেশি ভাল। এগুলি কেবল দৈর্ঘ্যের সাথে উপযুক্ত টাইপই নয় তবে এগুলিতে সংযোজিত ও পুনরায় আকার দেওয়া যেতে পারে। তাদের প্রতিযোগিতা করা সহজ। এবং সর্বোপরি, তাদের কাটা রয়েছে । এবং এটি দক্ষ অ্যারে প্রসেসিংয়ের জন্য একটি বিশাল वरदान on স্ট্রিংগুলি ডি এর অক্ষরের অ্যারে হয় এবং এটি কোনও সমস্যা নয় (আসলে এটি দুর্দান্ত!), কারণ ডি এর অ্যারেগুলি এত শক্তিশালী।

আমি এবং যেতে পারে। ডি প্রদত্ত অনেকগুলি উন্নতি thisহ'ল সামান্য জিনিস (যেমন নির্মাতার নাম ব্যবহারের জন্য বা বিবৃতি বা লুপ বডি যেখানে সেমিকোলনটি তাদের পুরো শরীর হয় তবে তা অস্বীকার করা) তবে সেগুলির কয়েকটি বেশ বড় হয় এবং আপনি যখন এটি একসাথে যোগ করেন তখন এটি হয় একটি অনেক ভাল প্রোগ্রামিং অভিজ্ঞতা জন্য তোলে । সি ++ 0x কিছু বৈশিষ্ট্য যুক্ত করে যা ডি রয়েছে যা সি ++ অনুপস্থিত ছিল (যেমন autoএবং ল্যাম্বডাস), তবে এর সমস্ত উন্নতির পরেও এখনও তেমন কিছু ঘটেনি যা ডি + এর চেয়ে ভাষা হিসাবে সি ++ সম্পর্কে নিখুঁতভাবে আরও ভাল is

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

সুতরাং, আমি অনুমান করি যে এই প্রশ্নের সংক্ষিপ্ত উত্তরটি "খুব অল্প"। ডি, একটি ভাষা হিসাবে, সাধারণত সি ++ এর চেয়ে উচ্চতর।


2
আবর্জনা সংগ্রহের ভাষাগুলি নন জিসি ল্যাংসের চেয়ে 2-5x বেশি মেমরি ব্যবহার করে (ওয়াইটি-তে আলেকজান্দ্রেস্কুর বক্তব্য অনুসারে) যাতে এটি (মেমের ব্যবহার) বাধা হয়ে দাঁড়ায় অবশ্যই সমস্যা।
NoSenseEtAl

9

RAII এবং স্ট্যাক মেমরি ব্যবহার

ডি 2.0 এটি স্ট্যাকের উপর আরআইআইআইকে হতে দেয় না কারণ এটি স্ট্যাকের scopeশ্রেণীর উদাহরণগুলি বরাদ্দকরণে কীওয়ার্ডের মান সরিয়ে নিয়েছে ।

আপনি ডি-তে মান-ধরণের উত্তরাধিকার করতে পারবেন না, এত কার্যকরভাবে আপনাকে আরআইআইয়ের যে কোনও ফর্মের জন্য গাদা বরাদ্দ করতে বাধ্য করে।
এটি হ'ল যদি না আপনি ব্যবহার করেন emplaceতবে এটি ব্যবহার করা খুব বেদনাদায়ক, যেহেতু আপনাকে হাতে হাত দিয়ে স্মৃতি বরাদ্দ করতে হবে। (আমি এটি emplaceডি তে ব্যবহার করার জন্য ব্যবহারিক এখনও খুঁজে পাইনি )


6

সি ++ আপনাকে ভার্জোজ হতে বাধ্য করার ক্ষেত্রে অনেক বেশি ভাল। আপনি পছন্দ বা ভার্বোসটি পছন্দ করেন কিনা তার উপর নির্ভর করে এটি আপনার চোখে আরও ভাল বা খারাপ হতে পারে।

সি ++ তে রান-টাইম মেমোয়াইজেশনের তুলনা করুন :

template <typename ReturnType, typename... Args>
function<ReturnType (Args...)> memoize(function<ReturnType (Args...)> func)
{
    map<tuple<Args...>, ReturnType> cache;
    return ([=](Args... args) mutable {
            tuple<Args...> t(args...);
            return cache.find(t) == cache.end()
                ? cache[t] : cache[t] = func(args...);
    });
}

ডি একই জিনিস সঙ্গে:

auto memoize(F)(F func)
{
    alias ParameterTypeTuple!F Args;
    ReturnType!F[Tuple!Args] cache;
    return (Args args)
    {
        auto key = tuple(args);
        return key in cache ? cache[key] : (cache[key] = func(args));
    };
}

লক্ষ্য করুন, উদাহরণস্বরূপ, template <typename ReturnType, typename... Args>বনাম (F), Args...বনাম Args, args...বনাম argsইত্যাদির সাথে অতিরিক্ত ভার্বোসিটি আরও
ভাল বা খারাপের জন্য, সি ++ আরও ভার্বোজ।

অবশ্যই আপনি ডি তে এটি করতে পারেন:

template memoize(Return, Args...)
{
    Return delegate(Args) memoize(Return delegate(Args) func)
    {
        Return[Tuple!Args] cache;
        return delegate(Args args)
        {
            auto key = tuple(args);
            return key in cache ? cache[key] : (cache[key] = func(args));
        };
    }
}

এবং তারা প্রায় অভিন্ন দেখতে হবে, কিন্তু তারপরে এটির জন্য একটি প্রয়োজন হবে delegate, যেখানে মূল কোনও কলযোগ্য বস্তু গ্রহণ করেছে । (সি ++ 0 এক্স সংস্করণটির জন্য একটিstd::function অবজেক্টের প্রয়োজন , সুতরাং যেভাবেই হোক না কেন, এটি আরও ইনব্যপস এবং ইনপুটগুলিতে বিধিনিষেধক ... যা আপনি ভার্বোসিটি পছন্দ করলে ভাল হতে পারে, আপনি যদি না করেন তবে খারাপ।)


2

আমি ডি সম্পর্কে তেমন কিছুই জানি না, তবে অনেকগুলি, অনেক সি ++ প্রোগ্রামার আমি এটির পক্ষে অপছন্দ করি এবং ব্যক্তিগতভাবে আমাকে সম্মত হতে হয়- আমি ডি এর চেহারা পছন্দ করি না এবং আরও কাছাকাছি নিয়ে যাব না।

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

কিছু গবেষণা যা আমি দেখেছি যখন একটু গবেষণা করার সময় এবং কয়েকজনের সাথে এটির চেষ্টা করে দেখা হয়েছিল:

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

আমি ফাংশন এবং প্রতিনিধিদের সাথে সমস্যা সম্পর্কে শুনেছি। স্পষ্টতই, ডি -র রান-টাইম কলযোগ্য ফাংশনের ধরণ হিসাবে উভয় ফাংশন এবং প্রতিনিধি রয়েছে এবং সেগুলি একই নয় তবে তারা বিনিময়যোগ্য বা ... কিছু? আমার বন্ধুর সাথে তাদের বেশ কয়েকটি সমস্যা ছিল। এটি অবশ্যই সি ++ এর একটি ডাউনগ্রেড, যা সবে আছে std::functionএবং আপনি শেষ করেছেন।

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

তারপরে, আরও কিছু জিনিস রয়েছে। উদাহরণস্বরূপ, কেবল উইকিপিডিয়া এন্ট্রি পড়ুন।

import std.metastrings;
pragma(msg, Format!("7! = %s", fact_7));
pragma(msg, Format!("9! = %s", fact_9));

printfgetsপুরানো সি স্ট্যান্ডার্ড লাইব্রেরির মতো বড় সমস্যাগুলির মতো একই পরিবারে এখন পর্যন্ত তৈরি করা সবচেয়ে নিরাপদ ফাংশন । আপনি যদি স্ট্যাক ওভারফ্লোতে এটি অনুসন্ধান করেন তবে আপনি এর অপব্যবহার সম্পর্কিত অনেকগুলি, অনেক প্রশ্ন দেখতে পাবেন। মূলত, ডিআরওয়াইprintf লঙ্ঘন- আপনি ফর্ম্যাট স্ট্রিংয়ে টাইপ দিচ্ছেন, এবং তারপরে আপনি যখন কোনও যুক্তি দিবেন তখন এটি আবার দিচ্ছেন। ডিআরওয়াই লঙ্ঘন যেখানে আপনি যদি এটি ভুল হয়ে থাকেন তবে খুব খারাপ জিনিস ঘটে যায় - বলুন, যদি আপনি কোনও টাইপডেফকে 16-বিট সংখ্যার থেকে 32-বিটের মধ্যে পরিবর্তন করেন। এটি মোটেও প্রসারণযোগ্য নয় - প্রত্যেকে যদি নিজস্ব ফর্ম্যাট স্পেসিফায়ার আবিষ্কার করে তবে কী হবে তা কল্পনা করুন। সি ++ এর আইওস্ট্রিমগুলি ধীর হতে পারে এবং তাদের অপারেটরের পছন্দটি সবচেয়ে বড় নাও হতে পারে এবং তাদের ইন্টারফেসটি কাজ ব্যবহার করতে পারে তবে তারা মূলত সুরক্ষিত হওয়ার গ্যারান্টিযুক্ত এবং ডিআরওয়াই লঙ্ঘিত হয় না এবং সেগুলি সহজেই বাড়ানো যেতে পারে। এটি এমন কিছু নয় যা সম্পর্কে বলা যেতে পারে printf

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

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

স্কট মায়ারস লিখেছেন:

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

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

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

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

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

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


9
@ ডিড এমএমজি: এটি 100% ভুল এবং এই বিন্দুটি অনুপস্থিত যে এটি অবশ্যই সি ++ এর ডাউনগ্রেড, যা সবেমাত্র রয়েছে std::functionএবং আপনি শেষ করেছেন। কেন? কারণ আপনারও উদাহরণস্বরূপ, ফাংশন পয়েন্টার রয়েছে। এটা ঠিক D এর একই জিনিস: ডি এর "ফাংশন" ফাংশন পয়েন্টার আছে, এবং ডি এর "প্রতিনিধিদের" হিসাবে একই সি ++ এর std::function(-setup বলা হবে যে বিল্ট-ইন)। এখানে কোথাও কোনও "ডাউনগ্রেড" নেই - এবং তাদের মধ্যে 1: 1 চিঠিপত্র রয়েছে, সুতরাং আপনি যদি সি ++ এর সাথে পরিচিত হন তবে তা মোটেই বিভ্রান্তিকর হওয়া উচিত নয়।
মেহরদাদ

10
@ মার্ক ট্র্যাপ: আমি অবশ্যই স্বীকার করব যে আমি এই বিষয়ে আপনার অবস্থান সম্পর্কে যথেষ্ট বুঝতে পারি না - মন্তব্যগুলি ব্যবহার করা উচিত নয়, আপনি কি জানেন যে একটি উত্তরে মন্তব্য করছেন?
ক্লিকভারবট

6
@ মার্ক ট্র্যাপ: আমার বক্তব্যটি হ'ল এখানে বেশিরভাগ মন্তব্য অপ্রচলিত ছিল না (আপনি যে মেটা আলোচনাটি বিশেষভাবে সংযুক্ত করেছেন সেগুলি ইতিমধ্যে মূল পোস্টে অন্তর্ভুক্ত করা হয়েছে এমন পরামর্শগুলিতে প্রযোজ্য), তবে পোস্টটিতে সত্যিকারের ভুলত্রুটি চিহ্নিত করেছেন, যা এখনও বিদ্যমান ।
ক্লিকভারবোট

7
বিন্যাসে একটি নোট: ডি এর ফর্ম্যাট ফাংশনটি টাইপসেফ (সুরক্ষা / ওভারফ্লো সমস্যাগুলি সমাধান করে) এবং ডিআরওয়াই লঙ্ঘন করে না কারণ ফর্ম্যাট স্ট্রিংটি কেবলমাত্র আর্গুমেন্টগুলি কীভাবে বিন্যস্ত করা উচিত তা তাদের ধরণের নয় specif এটি ডি এর টাইপসেফ বৈচিত্রের জন্য ধন্যবাদ। সুতরাং, সেই আপত্তি কমপক্ষে পুরোপুরি অবৈধ।
জাস্টিন ডাব্লু

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

1

সি ++ এ আমি যে বিষয়টির প্রশংসা করি তা হ'ল একটি ফাংশন আর্গুমেন্ট ডকুমেন্ট করার ক্ষমতা বা পয়েন্টারের পরিবর্তে সি ++ রেফারেন্স হিসাবে মান ফেরত দেওয়া, অতএব একটি অ- nullমান নেওয়া বোঝায় ।

ডি সংস্করণ:

class A { int i; }

int foo(A a) {
    return a.i; // Will crash if a is null
}

int main() {
    A bar = null;
    // Do something, forgetting to set bar in all
    // branches until finally ending up at:
    return foo(bar);
}

সি ++ সংস্করণ:

class A { int i; };

int foo(A& a) {
    return a.i; // Will probably not crash since
                // C++ references are less likely
                // to be null.
}

int main() {
    A* bar = null;
    // Do something, forgetting to set bar in all
    // branches until finally ending up at:
    // Hm.. I have to dereference the bar-pointer
    // here, otherwise it wont compile.  Lets add
    // a check for null before.
    if (bar)
        return foo(*bar);
    return 0;
}

সুষ্ঠু হওয়ার জন্য আপনি Aডি-তে তৈরি করে structএবং foo()-আরগমেন্টটি চিহ্নিত করে ref(ক্লাসগুলি রেফারেন্স টাইপ এবং স্ট্রাক্ট ডি-তে মান ধরণের, সি # এর সমতুল্য) দিয়ে সি ++ এর খুব কাছাকাছি যেতে পারেন ।

আমি বিশ্বাস করি NonNullableপরিবর্তে ডি স্ট্যান্ডার্ড লাইব্রেরি নির্মাণ হিসাবে ক্লাসগুলির জন্য একটি টেম্পলেট তৈরি করার পরিকল্পনা রয়েছে । এমনকি আমি শুধু এর সংক্ষিপ্ততা পছন্দ Type&তুলনায় NonNullable(Type)এবং ডিফল্ট (ভালো কিছু রেন্ডারিং অ-nullable পছন্দ করেন Typeএবং Nullable(Type))। তবে ডি এর জন্য এটি পরিবর্তন করতে খুব দেরি হয়ে গেছে এবং আমি এখন অফ-টপিকের বাইরে চলে যাচ্ছি।


3
ডি তে ফাংশন আর্গুমেন্ট এবং রিটার্ন মান উভয়ই refআপনাকে সি ++ এর মতো একই প্রভাব দিতে চিহ্নিত করা যেতে পারে &। একটি প্রধান পার্থক্য হ'ল এটি refএমনকি সাময়িক সময় নেবে না const
জোনাথন এম ডেভিস

আমি পছন্দ করি যেভাবে কীভাবে স্থানীয় ভেরিয়েবলগুলিতে রেফারেন্স ফিরিয়ে দেওয়া নিষিদ্ধ, আপনার মন্তব্য পড়ার আগে পর্যন্ত আমি সে সম্পর্কে অবগত ছিলাম না। তবে আপনি সি-ডিরিফারেন্স অপারেটর আপনাকে ভাবিয়ে তুলবে এমন উপায়ে চিন্তা না করেই কোনও স্থানীয়-নাল রেফারেন্সটি ফিরে আসতে পারেন।
2:58

আপনি বিভ্রান্তিকর জিনিস। ক্লাস সবসময় রেফারেন্স হয় এবং এটি রেফ থেকে পৃথক। ডি-তে রেফারেন্সগুলি জাভায় রেফারেন্সের মতো। তারা পয়েন্টার পরিচালিত। রেফ দ্বারা পাস করা বা ফিরে আসা সি -+ এর সাথে পাস করা বা ফিরে আসার মতো। রেফ দ্বারা ক্লাসের রেফারেন্সটি পাস করা যেমন সি ++ তে & (যেমন এ * ও) এর সাথে একটি পয়েন্টারটি পাস করার মতো। ক্লাসগুলি স্ট্যাকের উপরে যায় না। হ্যাঁ, ননলেবল এমন শ্রেণীর রেফারেন্সের পক্ষে এটি সম্ভব করে তোলে যা নন-নাল হওয়ার গ্যারান্টিযুক্ত ছিল তবে এটি রেফ থেকে সম্পূর্ণ পৃথক। আপনি সি ++ কোডে যা করার চেষ্টা করছেন তা ডি তে কাজ করে না কারণ ক্লাসগুলি স্ট্যাকের দিকে যায় না। স্ট্রাক্টস করেন।
জোনাথন এম ডেভিস

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

2
ভাষার মান দ্বারা সি ++ রেফারেন্স বাতিল করা যায় না ("সম্ভবত নাল হবে না" বলা ভুল কারণ এটি নাল হতে পারে না)। আমি চাই কোন শ্রেণীর জন্য বৈধ মান হিসাবে নাল বাতিল করার কোনও উপায় ছিল।
জাস্টারবার্গ

1

ডি এর চেয়ে সি ++ "আরও ভাল করে" এর মধ্যে সবচেয়ে গুরুত্বপূর্ণ বিষয়টি হ'ল লিগ্র্যাসি লাইব্রেরিতে হস্তক্ষেপ করা । বিভিন্ন 3D ইঞ্জিন, ওপেনসিএল এবং একই রকম al যেহেতু ডি নতুন, এটির থেকে বেছে নেওয়া বিভিন্ন লাইব্রেরির তুলনায় অনেক কম পরিমাণ রয়েছে।

সি ++ এবং ডি এর মধ্যে আরেকটি গুরুত্বপূর্ণ পার্থক্য হ'ল সি ++ এর একাধিক আর্থিক স্বতন্ত্র বিক্রেতারা রয়েছে তবে ২০১৪ সাল পর্যন্ত ডি কার্যত কেবলমাত্র একজন , দ্বি -ম্যান দল তৈরি করেছেন। এটি আকর্ষণীয় যে "দ্বিতীয় উত্স নীতি" যা বলে যে প্রকল্পগুলি কখনই প্রযুক্তি, উপাদানগুলির উপর নির্ভর করে না, যার কেবলমাত্র একক, একক, বিক্রেতা রয়েছে, এমনকি এটি সফ্টওয়্যারটির জন্য ধারণ করে বলে মনে হয়।

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

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

ওরাকল ইসিকে একটি জাভা এসই specific স্পেসিফিকেশন অনুরোধ এবং লাইসেন্স দিয়েছিলেন যা স্ববিরোধী, স্পষ্টের স্বাধীন বাস্তবায়নের বিতরণকে কঠোরভাবে সীমাবদ্ধ করে এবং সর্বাধিক গুরুত্বপূর্ণভাবে, অনুমিতের স্বাধীন ওপেন সোর্স বাস্তবায়নের বিতরণকে নিষিদ্ধ করে।

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

সারাংশ:

প্রযুক্তি ব্যবহারের জন্য প্রযুক্তি মূল্যায়ন করার সময়, প্রযুক্তির সর্বাধিক গুরুত্বপূর্ণ বৈশিষ্ট্য হ'ল লোকেরা, যারা এটি বিকাশ করে, সামাজিক প্রক্রিয়া, যেখানে উন্নয়ন ঘটে এবং আর্থিকভাবে স্বাধীন উন্নয়ন দলের সংখ্যা teams

প্রযুক্তি ওভার প্রযুক্তির বেশি করে টি -২০ ব্যবহার করা আরও সুবিধাজনক কিনা তা টি -২০ প্রযুক্তিগুলির বিক্রেতাদের উপর নির্ভর করে এবং প্রযুক্তি টি 1 টি প্রকল্পের সাথে সম্পর্কিত সমস্যাগুলি টি -2-এর তুলনায় আরও সস্তাভাবে সমাধান করতে দেয় কিনা depends উদাহরণস্বরূপ, যদি একক সরবরাহকারী ইস্যুটি উপেক্ষা করা হয়, তবে তথ্য সিস্টেমের জন্য জাভা সি ++ এর চেয়ে আরও ভাল "প্রযুক্তি" হবে, কারণ জাভা বাইনারিগুলিকে নতুন হার্ডওয়্যারে স্থাপনার সময় এবং মেমরি পরিচালনার সাথে সম্পর্কিত সফ্টওয়্যার ডেভলপমেন্ট কাজের পরিমাণ পুনঃসংশোধনের প্রয়োজন নেই because জাভা এর জন্য এটি সি ++ এর চেয়ে ছোট। প্রকল্পগুলি যা স্ক্র্যাচ থেকে উন্নত হয়, উদাহরণস্বরূপ যে প্রকল্পগুলি অন্যান্য লাইব্রেরির উপর নির্ভর করে না, তারা সি ++ এর চেয়ে ডি-তে উন্নততর হতে পারে, তবে অন্যদিকে, সি ++ এর একাধিক বিক্রেতা রয়েছে এবং তাই দীর্ঘমেয়াদে কম ঝুঁকিপূর্ণ । (জাভা উদাহরণ, যেখানে সান মাইক্রোসিস্টেমগুলি প্রায় ঠিক ছিল,

কিছু সি ++ সীমাবদ্ধতার পক্ষে একটি সম্ভাব্য কাজ ound

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

অপারেটিং সিস্টেম প্রক্রিয়াগুলির মধ্যে ব্যয়বহুল অপারেটিং সিস্টেম প্রক্রিয়া সূচনা এবং ডেটা অনুলিপি এড়ানোর জন্য, ছোট সি ++ কনসোল অ্যাপ্লিকেশনগুলির সেটটি একক সি ++ প্রোগ্রাম হিসাবে প্রয়োগ করা যেতে পারে যা রুবি / পাইথন / ইত্যাদি দ্বারা "সার্লেট" হিসাবে বুট করা হয়েছে। লিপি. রুবি / পাইথন / ইত্যাদি। স্ক্রিপ্ট প্রস্থান করার আগে সার্লেটটি বন্ধ করে দেয়। "সার্লেট" এবং রুবি / পাইথন / ইত্যাদির মধ্যে যোগাযোগ। স্ক্রিপ্টটি একটি লিনাক্স নামের পাইপ বা কিছু অনুরূপ প্রক্রিয়াতে স্থান নেয়।

প্রাথমিক কাজটি যদি খুব সহজেই টুকরো টুকরো টুকরো টুকরোতে ভাগ করে দেওয়া হয় যা 2 পূর্বে বর্ণিত শ্রেণিতে শ্রেণিবদ্ধ করা যেতে পারে, তবে চেষ্টা করার একটি বিষয় হতে পারে সমস্যাটির পুনরায় বাক্য তৈরি করা যাতে প্রাথমিক কাজটি পরিবর্তিত হয়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.