জাভা বিকাশকারীরা কি সচেতনভাবে RAII ত্যাগ করেছিল?


82

দীর্ঘ সময়ের সি # প্রোগ্রামার হিসাবে আমি সম্প্রতি রিসোর্স অ্যাকুইজিশন ইজ ইনিশিয়ালাইজেশন (আরআইআইআই) এর সুবিধা সম্পর্কে আরও জানতে এসেছি । বিশেষত, আমি আবিষ্কার করেছি যে সি # আইডিয়াম:

using (var dbConn = new DbConnection(connStr)) {
    // do stuff with dbConn
}

সি ++ সমতুল্য:

{
    DbConnection dbConn(connStr);
    // do stuff with dbConn
}

এর অর্থ হ'ল DbConnectionকোন usingব্লকের মতো সংস্থার ব্যবহার ঘেরে রাখা C ++ এ অপ্রয়োজনীয়! এটি সি ++ এর একটি বড় সুবিধা বলে মনে হচ্ছে। উদাহরণস্বরূপ DbConnection, আপনি উদাহরণস্বরূপ টাইপের সদস্য সদস্য এমন একটি শ্রেণিকে বিবেচনা করার সময় এটি আরও দৃinc় হয়

class Foo {
    DbConnection dbConn;

    // ...
}

সি # তে আমার IDisposableএইরকম ফু প্রয়োগ করতে হবে :

class Foo : IDisposable {
    DbConnection dbConn;

    public void Dispose()
    {       
        dbConn.Dispose();
    }
}

এবং সবচেয়ে খারাপ যে, প্রতিটি ব্যবহারকারীর একটি ব্লকে Fooআবদ্ধ থাকা মনে রাখতে হবে , যেমন:Foousing

   using (var foo = new Foo()) {
       // do stuff with "foo"
   }

এখন সি # এবং এর জাভা শিকড়গুলির দিকে তাকিয়ে আমি অবাক হয়ে যাচ্ছি ... জাভা বিকাশকারীরা কীভাবে পুরোপুরি প্রশংসা করেছিল যখন তারা স্তূপের পক্ষে স্ট্যাকটি ত্যাগ করেছিল এবং এভাবে আরআইআই ত্যাগ করেছিল?

(একইভাবে, হয়নি স্ট্রোভস্ট্রুপের সম্পূর্ণরূপে RAII তাৎপর্য উপলব্ধি করি?)


5
আমি নিশ্চিত না যে আপনি সি ++ এ সংস্থানগুলি সংযুক্ত না করে কী বিষয়ে কথা বলছেন। ডিবিসিঙ্কনেশন অবজেক্ট সম্ভবত তার ডেস্ট্রাক্টরের সমস্ত সংস্থান বন্ধ করে দেয়।
ম্যাপেল_শ্যাফ্ট

16
@ ম্যাপেল_শ্যাফ্ট, ঠিক আমার বক্তব্য! সি ++ এর সুবিধাটিই আমি এই প্রশ্নে সম্বোধন করছি। সি # তে আপনাকে "ব্যবহার করে" ... সি ++ তে রিসোর্সগুলি আবদ্ধ করতে হবে।
জোয়েলফ্যান

12
আমার বোধগম্যতা হ'ল একটি কৌশল হিসাবে, আরআইআইআই কেবল তখনই বোঝা গিয়েছিল যখন সি ++ কম্পাইলারগুলি আসলে উন্নত টেম্প্লেটিং ব্যবহার করতে যথেষ্ট ভাল ছিল যা জাভা পরে ভাল। সি ++ যে ব্যবহারের জন্য আসলে উপলব্ধ ছিল যখন জাভা তৈরি করা হয়েছে একটি খুব আদিম, শৈলী "শ্রেণীর সাথে সি" ছিল, সঙ্গে হয়তো , মৌলিক টেমপ্লেট যদি আপনি ভাগ্যবান ছিলেন।
শন ম্যাকমিলান

6
"আমার বোধগম্যতা হ'ল একটি কৌশল হিসাবে, আরআইআইআই কেবল তখনই বুঝতে পেরেছিল যখন সি ++ সংকলকরা আসলে উন্নত টেম্প্লেটিং ব্যবহার করতে যথেষ্ট ভাল ছিল যা জাভা পরে ভাল।" - এটা আসলে সঠিক নয়। প্রথম দিন থেকেই কনস্ট্রাক্টর এবং ধ্বংসকারীরা সি ++ এর মূল বৈশিষ্ট্য হয়ে উঠেছে, জাভালের আগে টেমপ্লেটগুলির ব্যাপক ব্যবহারের আগে এবং ভাল।
টেক্সাসে জিম

8
@ জিমআইনটেক্সাস: আমি মনে করি শন এর কোথাও কোথাও সত্যের মৌলিক বীজ রয়েছে (যদিও টেমপ্লেট নয় তবে ব্যতিক্রম ক্রোকস)। কনস্ট্রাক্টর / ডেস্ট্রাক্টররা প্রথম থেকেই সেখানে ছিলেন, তবে সেখানে গুরুত্ব এবং রাইআইআই ধারণাটি প্রাথমিকভাবে ছিল না (আমি যে শব্দটির সন্ধান করছি) তা উপলব্ধি করা হয়নি। পুরো RAII কতটা গুরুত্বপূর্ণ তা বুঝতে পেরে কম্পাইলারদের ভাল হতে কয়েক বছর এবং কিছু সময় নিয়েছিল।
মার্টিন ইয়র্ক

উত্তর:


38

এখন সি # এবং এর জাভা শিকড়গুলির দিকে তাকিয়ে আমি অবাক হয়ে যাচ্ছি ... জাভা বিকাশকারীরা কীভাবে পুরোপুরি প্রশংসা করেছিল যখন তারা স্তূপের পক্ষে স্ট্যাকটি ত্যাগ করেছিল এবং এভাবে আরআইআই ত্যাগ করেছিল?

(একইভাবে, স্ট্রস্ট্রুপ কীভাবে আরআইআইয়ের তাৎপর্যকে পুরোপুরি উপলব্ধি করেছিল?)

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

যথেষ্ট মজার বিষয়, এমনকি স্ট্রস্ট্রপও যখন তিনি তাদের নকশাটি তৈরি করেছিলেন তখন নির্বিচারবাদী ধ্বংসকারীদের গুরুত্ব সম্পর্কে অবগত ছিলেন না। আমি উদ্ধৃতিটি খুঁজে পাচ্ছি না, তবে আপনি যদি সত্যিই এটির মধ্যে থাকেন তবে আপনি তার সাক্ষাত্কারগুলির মধ্যে এটি এখানে পেতে পারেন: http://www.stroustrup.com/interviews.html


11
@ ম্যাপেল_শ্যাফ্ট: সংক্ষেপে, এটি সম্ভব নয়। আপনি যদি ডিটারমিনিস্টিক আবর্জনা সংগ্রহের কোনও উপায় আবিষ্কার করেন (যা সাধারণভাবে অসম্ভব বলে মনে হয় এবং গত দশকের সমস্ত জিসি অপ্টিমাইজেশানকে কোনও অবস্থাতেই অবৈধ করে তোলে) তবে আপনাকে স্ট্যাক-বরাদ্দকৃত অবজেক্টগুলি প্রবর্তন করতে হবে, তবে এটি বেশ কয়েকটি ক্যান খোলে কীটপতঙ্গ: এই পদার্থগুলির জন্য শব্দার্থবিজ্ঞানের প্রয়োজন, সাবটিপিংয়ের সাথে "স্লাইসিং সমস্যা" (এবং তাই কোনও বহুত্ববাদ), ঝুঁকিপূর্ণ পয়েন্টার যদি না আপনি সম্ভবত এটির উপর উল্লেখযোগ্য বিধিনিষেধ স্থাপন করেন বা বিশাল অসম্পূর্ণ প্রকারের সিস্টেম পরিবর্তন করেন। এবং এটি আমার মাথার উপরের অংশে।

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

26
@delan। আমি সি ++ স্মার্ট পয়েন্টার manualমেমরি ম্যানেজমেন্ট কল করব না । তারা আরও একটি নির্বিচারে জরিমানা শস্য নিয়ন্ত্রণযোগ্য আবর্জনা সংগ্রাহকের মতো। সঠিকভাবে স্মার্ট পয়েন্টার ব্যবহার করা হলে মৌমাছির হাঁটু হয় es
মার্টিন ইয়র্ক

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

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

60

হ্যাঁ, সি # এর ডিজাইনার (এবং, আমি নিশ্চিত, জাভা) নির্দিষ্টভাবে নির্বিচার চূড়ান্তকরণের বিরুদ্ধে সিদ্ধান্ত নিয়েছে। আমি এন্ডার্স হেজলসবার্গকে 1999-2002 এর প্রায় একাধিকবারের বিষয়ে জিজ্ঞাসা করেছি।

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

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

সে কারণে আপনি কোনও প্রোগ্রামিং সিস্টেমে প্রতিটি বস্তুর উপর নির্বিচারে চূড়ান্তকরণ চান না যেখানে "(প্রায়) সবকিছুই একটি বস্তু।" সুতরাং আপনাকে ডিটারমিনিস্টিক চূড়ান্তকরণের একটি থেকে সাধারণভাবে ট্র্যাক করা অবজেক্টটিকে পৃথক করতে এক ধরণের প্রোগ্রামার-নিয়ন্ত্রিত সিনট্যাক্স প্রবর্তন করতে হবে

সি # তে আপনার usingকীওয়ার্ড রয়েছে যা সি # 1.0 তে কী হয়েছে তার নকশায় বেশ দেরিতে এসেছিল। পুরো IDisposableজিনিসটি বেশ কুৎসিত এবং এক জন আশ্চর্য হয় যে বয়লার-প্লেট প্যাটার্নটি স্বয়ংক্রিয়ভাবে প্রয়োগ করা যেতে পারে এমন শ্রেণিগুলিকে চিহ্নিত usingকরে সি ++ ডিস্ট্রাক্টর সিনট্যাক্স নিয়ে কাজ করা আরও মার্জিত হবে কিনা ?~IDisposable


2
সি ++ / সিএলআই (। নেট) কী করেছে সে সম্পর্কে কী, যেখানে পরিচালিত হিপগুলিতে থাকা বস্তুগুলির স্ট্যাক-ভিত্তিক "হ্যান্ডেল" রয়েছে, যা আরআইএএ সরবরাহ করে?
জোয়েলফ্যান

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

5
এটি এখন পর্যন্ত একমাত্র সঠিক উত্তর - এটি কারণ জাভা ইচ্ছাকৃতভাবে (অ-আদিম) স্ট্যাক-ভিত্তিক অবজেক্টস নেই।
ব্লুরাজা - ড্যানি পিফ্লুঘুফ্ট

8
@ পিটার টেইলর - ঠিক আছে তবে আমি অনুভব করি যে সি # এর অ-নিরস্তুত্ববাদী ধ্বংসকারী খুব কম মূল্যবান, যেহেতু আপনি কোনও ধরণের সীমাবদ্ধ সংস্থান পরিচালনার জন্য এটির উপর নির্ভর করতে পারবেন না। সুতরাং, আমার মতে, ~সিনট্যাক্সটি সিনট্যাকটিক চিনির জন্য সিনট্যাক্স ব্যবহার করা আরও ভাল ছিলIDisposable.Dispose()
ল্যারি ওব্রায়ান

3
@ ল্যারি: আমি একমত সি ++ / সিএলআই সিন্ট্যাকটিক চিনির জন্য ব্যবহার করে এবং এটি সি # সিনট্যাক্সের চেয়ে অনেক বেশি সুবিধাজনক। ~IDisposable.Dispose()
dan04

41

মনে রাখবেন যে জাভা 1991-1995 সালে বিকাশ করা হয়েছিল যখন সি ++ অনেক আলাদা ভাষা ছিল। ব্যতিক্রম (যা RAII প্রয়োজনীয় করে তোলে ) এবং টেমপ্লেটগুলি (যা স্মার্ট পয়েন্টারগুলি কার্যকর করতে সহজ করে তোলে) "নতুন-ফিঙ্গেল" বৈশিষ্ট্য ছিল। বেশিরভাগ সি ++ প্রোগ্রামার সি থেকে এসেছিল এবং ম্যানুয়াল মেমরি পরিচালনা করতে অভ্যস্ত ছিল।

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

তাহলে কেন মূল্য শব্দার্থের পরিবর্তে রেফারেন্স শব্দার্থ ব্যবহার করবেন?

কারণ এটি ভাষাটিকে অনেক সহজ করে তোলে ।

  • Fooএবং এর Foo*মধ্যে বা এর মধ্যে foo.barএবং এর মধ্যে সিন্ট্যাক্টিক পার্থক্যের প্রয়োজন নেই foo->bar
  • ওভারলোডেড অ্যাসাইনমেন্টের কোনও প্রয়োজন নেই, যখন সমস্ত অ্যাসাইনমেন্টটি পয়েন্টারটি অনুলিপি করে।
  • অনুলিপি নির্মাণকারীর প্রয়োজন নেই। ( মাঝে মাঝে একটি স্পষ্ট অনুলিপি ফাংশনের clone()প্রয়োজন হয় Many
  • privateঅনুলিপি নির্মাণকারীকে ঘোষণা operator=করার এবং কোনও শ্রেণি অপ্রয়োজনীয় করার দরকার নেই। যদি আপনি অনুলিপি করা কোনও শ্রেণীর অবজেক্টগুলি না চান তবে আপনি এটি অনুলিপি করার জন্য কেবল কোনও ফাংশন লিখবেন না।
  • swapফাংশন প্রয়োজন হয় না । (যদি না আপনি কোনও ধরণের রুটিন লিখেন))
  • সি ++ 0-স্টাইলের মূল্য সংক্রান্ত রেফারেন্সের প্রয়োজন নেই।
  • (এন) আরভিওর দরকার নেই।
  • কাটানোর কোনও সমস্যা নেই।
  • কম্পাইলারের পক্ষে অবজেক্ট লেআউটগুলি নির্ধারণ করা সহজ, কারণ রেফারেন্সগুলির একটি নির্দিষ্ট আকার থাকে।

রেফারেন্স শব্দার্থবিজ্ঞানের মূল নেতিবাচক দিকটি হ'ল যখন প্রতিটি বস্তুর কাছে এটিতে একাধিক রেফারেন্স থাকে তখন কখন এটি মুছতে হয় তা জানা শক্ত হয়ে যায়। আপনি প্রায় কাছাকাছি আছে স্বয়ংক্রিয় মেমরি ব্যবস্থাপনা আছে।

জাভা একটি অ-নিরবচ্ছিন্ন আবর্জনা সংগ্রহকারী ব্যবহার করতে বেছে নিয়েছে।

জিসি কি সংঘবদ্ধ হতে পারে না?

হ্যাঁ এটা পারি. উদাহরণস্বরূপ, পাইথনের সি প্রয়োগকরণ রেফারেন্স গণনা ব্যবহার করে। এবং পরে চক্রযুক্ত আবর্জনা যেখানে রিফ্যাক্টস ব্যর্থ হয় তা পরিচালনা করতে ট্রেসিং জিসি যুক্ত করেছে।

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

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

তবে সি ++ / সিএলআই "স্ট্যাক অবজেক্টস" সম্পর্কে কী?

এগুলি ( মূল লিঙ্ক ) জন্যDispose কেবল সিনট্যাকটিক চিনি , অনেকটা সি # এর মতো । তবে এটি ডিটারমিনিস্টিক ধ্বংসের সাধারণ সমস্যার সমাধান করে না, কারণ আপনি একটি বেনাম তৈরি করতে পারেন এবং সি ++ / সিএলআই এটি স্বয়ংক্রিয়ভাবে নিষ্পত্তি করবে না।usinggcnew FileStream("filename.ext")


3
এছাড়াও, দুর্দান্ত লিঙ্কগুলি (বিশেষত প্রথমটি, যা এই আলোচনার সাথে অত্যন্ত প্রাসঙ্গিক)
ব্লুরাজা - ড্যানি পিফ্লুঘিওফ্ট

usingবিবৃতি অনেক পরিষ্করণ সংক্রান্ত সমস্যার চমত্কারভাবে পরিচালনা, কিন্তু আরও অনেক কিছু রয়ে গেছে। আমি প্রস্তাব দেব যে কোনও ভাষা এবং কাঠামোর জন্য সঠিক পন্থাটি হ'ল স্টোরেজ অবস্থানগুলির মধ্যে ঘোষকভাবে পৃথক করা হবে IDisposableযা না স্বীকৃতদের থেকে রেফারেন্সযুক্ত "মালিকানাধীন" ; কোনও সঞ্চয়ীকরণের মালিকানাধীন কোনও স্টোরেজ অবস্থানটি ওভাররাইটিং বা পরিত্যাগ করা IDisposableবিপরীত দিক নির্দেশকের অভাবে লক্ষ্যটিকে নিষ্পত্তি করা উচিত।
সুপারক্যাট

1
"অনুলিপি নির্মাণকারীর প্রয়োজন নেই" দুর্দান্ত লাগছে, তবে অনুশীলনে খারাপভাবে ব্যর্থ হয়। java.util. তারিখ এবং ক্যালেন্ডার সম্ভবত সবচেয়ে কুখ্যাত উদাহরণ। এর চেয়ে ভাল আর কিছু নেই new Date(oldDate.getTime())
কেভিন cline

2
iow RAII "পরিত্যক্ত" ছিল না, এটি কেবল পরিত্যক্ত হওয়ার মতোই ছিল না :) নির্মাতাদের অনুলিপি করার জন্য, আমি তাদের কখনই পছন্দ করি না, ভুল করাও খুব সহজ নয়, তারা কোথাও কাউকে গভীরভাবে নিচে রাখলে তারা মাথাব্যথার একটি স্থির উত্স হন're (অন্যথায়) একটি অনুলিপি তৈরি করতে ভুলে গিয়েছিলেন, যাতে হওয়া উচিত নয় এমন অনুলিপিগুলির মধ্যে সংস্থান ভাগ করা যায়।

20

জাভা 7 সি # এর অনুরূপ কিছু উপস্থাপন করেছে using: চেষ্টা করুন-সংস্থানসমূহের বিবৃতি

tryএক বা একাধিক সংস্থান ঘোষণা করে এমন একটি বিবৃতি। একটি রিসোর্স একটি অবজেক্ট হিসাবে এটি অবশ্যই প্রোগ্রামটি শেষ হওয়ার পরে এটি বন্ধ করে দেওয়া উচিত। try-সঙ্গে-সম্পদ বিবৃতি নিশ্চিত করে যে প্রতিটি রিসোর্স বিবৃতি শেষে বন্ধ করা হয়। যে কোনও অবজেক্ট প্রয়োগ করে java.lang.AutoCloseable, যার মধ্যে প্রয়োগ করা সমস্ত অবজেক্ট রয়েছে java.io.Closeable, এটি একটি উত্স হিসাবে ব্যবহার করা যেতে পারে ...

সুতরাং আমি অনুমান করি তারা হয় সচেতনভাবে RAII বাস্তবায়ন না করা বেছে নেয়নি বা এরই মধ্যে তারা তাদের মন পরিবর্তন করেছিল।


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

9
@ প্যাট্রিক: এর, তাই না? usingআরআইআই-এর মতো নয় - এক ক্ষেত্রে কলার রিসোর্সগুলি নিষ্পত্তি করার বিষয়ে উদ্বিগ্ন হন, অন্য ক্ষেত্রে কলি এটি পরিচালনা করে।
ব্লুরাজা - ড্যানি পিফ্লুঘুফুট

1
+1 আমি চেষ্টা-সহ-সংস্থানগুলি সম্পর্কে জানতাম না; এটি আরও বয়লারপ্লেট ডাম্পিংয়ে দরকারী হওয়া উচিত।
jprete

3
-1 -র জন্য using-রিসোর্সগুলি আরআইআই-এর মতো নয় for
শন ম্যাকমিলান

4
@ শীন: একমত usingএবং এটি ইল্ক আরআইআইআইয়ের কাছাকাছি আর নেই।
ডেড এমজি

18

জাভা ইচ্ছাকৃতভাবে স্ট্যাক-ভিত্তিক অবজেক্টস (ওরফে মান-অবজেক্টস) নেই। এ জাতীয় পদ্ধতির শেষে অবজেক্টটি স্বয়ংক্রিয়ভাবে ধ্বংস হওয়া প্রয়োজন।

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

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


কেন জাভাতে স্ট্যাক-ভিত্তিক অবজেক্ট নেই?

(আদিম ব্যতীত ..)

কারণ স্ট্যাক-ভিত্তিক অবজেক্টগুলির হ্যাপ-বেসড রেফারেন্সগুলির চেয়ে আলাদা শব্দার্থবিজ্ঞান রয়েছে। সি ++ এ নিম্নলিখিত কোডটি কল্পনা করুন; এটার কাজ কি?

return myObject;
  • যদি myObjectস্থানীয় স্ট্যাক-ভিত্তিক অবজেক্ট হয় তবে অনুলিপি-নির্মাণকারীকে ডাকা হয় (যদি ফলাফলটি কোনও কিছুর জন্য নির্ধারিত হয়)।
  • যদি myObjectকোনও স্থানীয় স্ট্যাক-ভিত্তিক অবজেক্ট হয় এবং আমরা একটি রেফারেন্স ফিরিয়ে দিই তবে ফলাফলটি অনির্ধারিত।
  • যদি myObjectসদস্য / গ্লোবাল অবজেক্ট হয় তবে কপি-কনস্ট্রাক্টরকে ডাকা হয় (যদি ফলাফলটি কোনও কিছুর জন্য নির্ধারিত হয়)।
  • যদি myObjectকোনও সদস্য / গ্লোবাল অবজেক্ট হয় এবং আমরা একটি রেফারেন্স ফিরিয়ে দিই তবে রেফারেন্সটি ফেরত দেওয়া হয়।
  • যদি myObjectস্থানীয় স্ট্যাক-ভিত্তিক অবজেক্টের পয়েন্টার হয় তবে ফলাফলটি সংজ্ঞায়িত।
  • যদি myObjectকোনও সদস্য / গ্লোবাল অবজেক্টের পয়েন্টার হয় তবে সেই পয়েন্টারটি ফেরত দেওয়া হবে।
  • যদি myObjectহ্যাপ-ভিত্তিক অবজেক্টের পয়েন্টার হয় তবে সেই পয়েন্টারটি ফেরত দেওয়া হবে।

এখন একই কোড জাভাতে কি করে?

return myObject;
  • এর রেফারেন্স myObjectফিরিয়ে দেওয়া হয়েছে। ভেরিয়েবল স্থানীয়, সদস্য বা গ্লোবাল কিনা তা বিবেচ্য নয়; এবং চিন্তার জন্য কোনও স্ট্যাক-ভিত্তিক অবজেক্টস বা পয়েন্টার কেস নেই।

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


6
"RAII এর কোনও লাভ নেই" বলতে আপনি কী বোঝেন তা আমি জানি না ... আমি মনে করি আপনি "জাভাতে আরআইআইআই সরবরাহ করার ক্ষমতা নেই" বলে মনে করেন ... আরআইআই কোনও ভাষা থেকে স্বতন্ত্র ... এটি নেই "অর্থহীন" হয়ে যান কারণ 1 নির্দিষ্ট ভাষা এটি সরবরাহ করে না
জোয়েলফ্যান

4
এটি কোনও বৈধ কারণ নয়। স্ট্যাক-ভিত্তিক RAII ব্যবহার করার জন্য কোনও বস্তুকে আসলে স্ট্যাকের উপরে থাকতে হবে না। যদি "অনন্য রেফারেন্স" এর মতো জিনিস থাকে তবে সুযোগের বাইরে চলে গেলে ধ্বংসকারীকে বরখাস্ত করা যায়। উদাহরণস্বরূপ দেখুন, কীভাবে এটি ডি প্রোগ্রামিং ভাষার সাথে কাজ করে: d-programming-language.org/exception-safe.html
নেমানজা ত্রিফুনোভিচ

3
@Nemanja: একটি বস্তু নেই আছে স্ট্যাক বাস করতে স্ট্যাক ভিত্তিক শব্দার্থবিদ্যা আছে, এবং আমি বলেন, এটি করেনি। তবে সমস্যাটি নয়; সমস্যাটি, যেমনটি আমি বলেছি, তা হ'ল স্ট্যাক-ভিত্তিক শব্দার্থবিদ্যা self
ব্লুরাজা - ড্যানি পিফ্লুঘিওফ্ট

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

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

17

এর গর্ত সম্পর্কে আপনার বিবরণ usingঅসম্পূর্ণ। নিম্নলিখিত সমস্যা বিবেচনা করুন:

interface Bar {
    ...
}
class Foo : Bar, IDisposable {
    ...
}

Bar b = new Foo();

// Where's the Dispose?

আমার মতে, আরআইআইআই এবং জিসি উভয়ই না থাকা একটি খারাপ ধারণা ছিল। জাভাতে যখন ফাইলগুলি বন্ধ করার কথা আসে তখন এটি malloc()এবং free()সেখানে।


2
আমি সম্মত হই যে RAII হল মৌমাছির হাঁটু। তবে usingজাভা ধরে সি # এর পক্ষে ক্লজটি দুর্দান্ত ধাপ। এটি নির্বিচারে ধ্বংসকে মঞ্জুরি দেয় এবং এভাবে সঠিক সংস্থান পরিচালনার (এটি আরআইআইয়ের মতো ঠিক তেমন ভাল নয়, তবে এটি করার জন্য এটি অবশ্যই একটি ভাল ধারণা)।
মার্টিন ইয়র্ক

8
"যখন জাভাতে ফাইলগুলি বন্ধ করার কথা আসে তখন এটি ম্যালোক () এবং সেখানে () মুক্ত করা যায়।" একেবারে।
কনরাড রুডলফ

9
@ কনরাড রুডল্ফ: এটি মলোক এবং বিনামূল্যে চেয়ে খারাপ। কমপক্ষে সি তে আপনার ব্যতিক্রম নেই।
নেমানজা ত্রিফুনোভিচ

1
@Nemanja: আসুন পরিষ্কার করা, আপনি পারেন free()মধ্যে finally
ডেডএমজি

4
@ লোকি: বেস ক্লাসের সমস্যা সমস্যা হিসাবে অনেক বেশি গুরুত্বপূর্ণ। উদাহরণস্বরূপ, আসলটি IEnumerableউত্তরাধিকার সূত্রে পায় নি IDisposable, এবং এখানে বিশেষ পুনরাবৃত্তিকারীদের একটি গোছা রয়েছে যা ফলস্বরূপ কার্যকর করা যায় নি।
ডেডএমজি

14

আমি বেশ বুড়ো। আমি সেখানে এসেছি এবং এটি দেখেছি এবং এটি সম্পর্কে আমার মাথাটি বার বার বেঁধে দিয়েছি।

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

এখন তারা ভাষা বর্ণনায় ফাইনালাইজার যুক্ত করেছে এবং জাভা কিছু গ্রহণ করেছে।

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

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

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

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

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

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

আইএমএইচও, উপায়। নেট সহজেই জাভার সবচেয়ে বড় ত্রুটি অনুলিপি করা হল এটির বৃহত্তম দুর্বলতা। .NET এর চেয়ে ভাল জাভা হওয়া উচিত নয় C


আইএমএইচও, ব্লকগুলি 'ব্যবহার' করার মতো বিষয়গুলি হ'ল ডিটারমিনিস্টিক ক্লিনআপের জন্য সঠিক পদ্ধতি, তবে আরও কয়েকটি জিনিসও প্রয়োজন: (১) তাদের ধ্বংসকারীরা যদি কোনও ব্যতিক্রম ছুঁড়ে ফেলে তবে বস্তুগুলি নিষ্পত্তি হয়ে যায় তা নিশ্চিত করার একটি উপায়; (২) নির্দেশের Disposeসাথে চিহ্নিত সমস্ত ক্ষেত্রে কল করার জন্য একটি রুটিন পদ্ধতি স্বয়ংক্রিয়ভাবে উত্পন্ন করার একটি উপায় usingএবং IDisposable.Disposeএটি স্বয়ংক্রিয়ভাবে কল করা উচিত কিনা তা নির্দিষ্ট করে; (3) অনুরূপ একটি নির্দেশ using, কিন্তু যা কেবল Disposeব্যতিক্রম ক্ষেত্রে কল করবে ; (4) এর বিভিন্নতা IDisposableযা একটি Exceptionপ্যারামিটার গ্রহণ করবে এবং ...
সুপারক্যাট

... যা usingউপযুক্ত হলে স্বয়ংক্রিয়ভাবে ব্যবহার করা হবে ; পরামিতি হবে nullযদি usingব্লক স্বাভাবিকভাবে থেকে বেরিয়ে গেছে, বা অন্য নির্দেশ করবে কি ব্যতিক্রম যদি এটা ব্যতিক্রম মাধ্যমে থেকে প্রস্থান মুলতুবী করা হয়েছে। যদি এই জাতীয় জিনিসগুলি বিদ্যমান থাকে তবে কার্যকরভাবে সংস্থানগুলি পরিচালনা করা এবং ফুটো এড়ানো সহজ হবে।
সুপারক্যাট

11

"থিঙ্কিং ইন জাভা" এবং "থিংকিং ইন সি ++" র লেখক এবং সি ++ স্ট্যান্ডার্ড কমিটির সদস্য ব্রুস এক্কেলের মতামত, অনেক ক্ষেত্রে (শুধু আরআইআই নয়), গোসলিং এবং জাভা দল তাদের কাজ করেনি বাড়ির কাজ.

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

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

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

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

তালিকাটি এমন পর্যায়ে চলে গেছে যেখানে এটি কেবল ক্লান্তিকর ...


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

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

2
@ জর্জিও একটি নির্দিষ্ট দৃষ্টান্ত এবং ভাষা পরিবারে বিদ্যমান ভাষা অধ্যয়ন করা নতুন ভাষা বিকাশের জন্য প্রয়োজনীয় হোমওয়ার্কের একটি অংশ। এটি এমন একটি উদাহরণ যেখানে তারা কেবল জাভা দিয়ে ঝাঁকুনি দিয়েছিলেন। তাদের দেখার জন্য সি ++ এবং স্মার্টটাক ছিল। এটি কখন বিকাশ করা হয়েছে তা দেখার জন্য সি ++ এর জাভা ছিল না।
জেরেমি

1
@ জ্ঞাওমে: "জাভা বেশ কয়েকটি ইস্যুতে নৌকাকে মিস করেছে বলে মনে হচ্ছে, যার কয়েকটি সরাসরি রাইয়ের সাথে সম্পর্কিত": আপনি কি এই বিষয়গুলি উল্লেখ করতে পারেন? আপনার পোস্ট করা নিবন্ধটি আরআইআইআইয়ের উল্লেখ করে না।
জর্জিও

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

10

সবচেয়ে ভাল কারণ এখানে বেশিরভাগ উত্তর চেয়ে সহজ।

আপনি স্ট্যাক বরাদ্দকৃত বস্তুগুলি অন্য থ্রেডে পাস করতে পারবেন না।

থামুন এবং এটি সম্পর্কে চিন্তা করুন। ভাবতে থাকুন .... সবাই যখন আরআইআইতে এত আগ্রহী তখন এখন সি ++ এর থ্রেড ছিল না। এমনকি চারপাশে অনেকগুলি বস্তু পাস করার পরে এমনকি এরলং (প্রতি থ্রেডের পৃথক স্তূপগুলি) অভিনব হয়ে ওঠে। সি ++ কেবলমাত্র সি ++ 2011 সালে একটি মেমরি মডেল পেয়েছে; আপনার সংকলকের "ডকুমেন্টেশন" উল্লেখ না করেই আপনি এখন সি ++ তে সমঝোতা সম্পর্কে প্রায় যুক্তি করতে পারেন।

জাভা একাধিক থ্রেডের জন্য (প্রায়) প্রথম দিন থেকেই ডিজাইন করা হয়েছিল।

আমার কাছে এখনও "দ্য সি ++ প্রোগ্রামিং ল্যাঙ্গুয়েজ" এর পুরানো কপিটি পেয়েছি যেখানে স্ট্রস্ট্রপ আমাকে আশ্বাস দেয় যে আমার থ্রেড লাগবে না।

দ্বিতীয় বেদনাদায়ক কারণটি কাটা কাটা এড়ানো।


1
একাধিক থ্রেডের জন্য তৈরি করা জাভাও ব্যাখ্যা করে যে কেন জিসি রেফারেন্স গণনার ভিত্তিতে নয়।
dan04

4
@ নিমঞ্জাটিফ্রিভনোভিচ: আপনি সি ++ / সিএলআই কে জাভা বা সি # এর সাথে তুলনা করতে পারবেন না, এটি প্রায় নিয়ন্ত্রিত সি / সি ++ কোডের সাথে ইন্টারঅ্যাক্টের প্রকাশের উদ্দেশ্যে তৈরি করা হয়েছিল; এটি আরও একটি নিয়ন্ত্রিত ভাষার মতো যা এর থেকে বিপরীতে .NET কাঠামোর অ্যাক্সেস দেয়।
অ্যারোনআউট

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

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

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

5

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

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


7
"গি-দ্য-প্রোগ্রামার-এ-চ্যান্স-টু-রোল-তাদের নিজস্ব দর্শন" আপনার প্রোগ্রামারদের দ্বারা লিখিত গ্রন্থাগারগুলিকে একত্রিত করতে হবে যা প্রতিটি তাদের নিজস্ব স্ট্রিং ক্লাস এবং স্মার্ট পয়েন্টার রোল করে।
dan04

@ ডান04 সুতরাং পরিচালিত ভাষাগুলি যা আপনাকে প্রাক-সংজ্ঞায়িত স্ট্রিং ক্লাস দেয়, তারপরে আপনাকে সেগুলি বানর-প্যাচ করার অনুমতি দেয়, এটি যদি আপনি এমন লোকের মতো হন যে কোনও ভিন্ন নিজস্ব-ঘূর্ণিত স্ট্রিং মোকাবেলা করতে না পারে তবে এই বিপর্যয়ের প্রতিকার recipe বর্গ।
gbjbaanb

-1

আপনি ইতিমধ্যে Disposeপদ্ধতিতে সি # তে এর মোটামুটি সমতুল্য ডাকলেন । জাভাও আছে finalizeদ্রষ্টব্য: আমি বুঝতে পারি যে জাভার চূড়ান্তকরণটি অ-নিরঙ্কুশ এবং পৃথক Dispose, আমি কেবল এটিই ইঙ্গিত করছি যে তাদের দু'জনেরই জিসির পাশাপাশি সংস্থান পরিষ্কার করার পদ্ধতি রয়েছে।

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

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

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


12
সবার আগে জাভার "চূড়ান্তকরণ" হ'ল অ-নিরোধক ... এটি সি # এর "নিষ্পত্তি" বা সি ++ এর ধ্বংসকারীদের সমতুল্য নয় ... এছাড়াও, আপনি যদি সি ++ ব্যবহার করেন তবে আবর্জনা সংগ্রহকারীও রয়েছে। নেট
জোয়েলফ্যান an

2
@ ডিড এমএমজি: সমস্যাটি হ'ল আপনি বোকা নাও হতে পারেন, তবে অন্য ব্যক্তি যিনি সবেমাত্র সংস্থাটি ছেড়ে গেছেন (এবং যে কোডটি আপনি এখন রক্ষণ করেছেন সেটিই সম্ভবত) থাকতে পারে।
কেভিন

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

3
ডেড এমএমজি কি বলেছে। সি ++ সম্পর্কে অনেকগুলি খারাপ জিনিস রয়েছে। তবে আরআইআইআই তাদের দীর্ঘ প্রসারিত করে নয় isn't প্রকৃতপক্ষে, রিসোর্স ম্যানেজমেন্টের জন্য যথাযথভাবে অ্যাকাউন্টিং করার জন্য জাভা এবং .NET এর অভাব (কারণ মেমরিই একমাত্র সম্পদ, তাই না?) তাদের বৃহত্তম সমস্যা।
কনরাড রুডলফ

8
আমার মতে চূড়ান্তকরণকারী একটি বিপর্যয় ডিজাইন বুদ্ধিমান। যেহেতু আপনি ডিজাইনার থেকে অবজেক্টটির ব্যবহারকারীর কাছে কোনও অবজেক্টের সঠিক ব্যবহার বাধ্য করছেন (মেমরি পরিচালনার ক্ষেত্রে নয় তবে রিসোর্স ম্যানেজমেন্টের ক্ষেত্রে নয়)। সি ++ এ রিসোর্স ম্যানেজমেন্ট সঠিক হওয়া (শুধুমাত্র একবারেই করা হয়েছে) ক্লাস ডিজাইনারের দায়িত্ব। জাভাতে এটি রিসোর্স ম্যানেজমেন্ট সঠিক হওয়া ক্লাস ব্যবহারকারীর দায়িত্ব এবং এভাবে আমাদের যখন ক্লাসটি ব্যবহার করা হয় ততবারই এটি করতে হবে। stackoverflow.com/questions/161177/…
মার্টিন ইয়র্ক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.