কেন সি # তে কনস্ট্যান্ড প্যারামিটারগুলি অনুমোদিত নয়?


102

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

আমি নীচের মতো আমার পদ্ধতিটি কেন ঘোষণা করতে পারি না?

    ....
    static void TestMethod1(const MyClass val)
    {}
    ....
    static void TestMethod2(const int val)
    {}
    ....

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

3
এই প্রশ্নের এ বড় আলোচনা: "C # const-শুদ্ধি": stackoverflow.com/questions/114149/const-correctness-in-c
tenpn

মান প্রকারের জন্য [আউট / রেফ] রয়েছে তবে রেফারেন্স প্রকার নয়। এটি একটি আকর্ষণীয় প্রশ্ন।
কেনি

4
এই প্রশ্নে কীভাবে সি # এবং ভাষা-অজ্ঞাতদৃষ্টির ট্যাগ থাকতে পারে?
সিজে

1
পার্শ্ব প্রতিক্রিয়াবিহীন অপরিবর্তনীয় ডেটা এবং ফাংশনগুলি সম্পর্কে তর্ক করা সহজ। আপনি এফ # fsharpforfunandprofit.com/posts/is-your-language- অযৌক্তিকভাবে
কর্নেল আতঙ্ক

উত্তর:


59

অন্যান্য ভাল উত্তরের পাশাপাশি, আমি সি-স্টাইলের দৃ const়তা সি # তে না রাখার আরও একটি কারণ যুক্ত করব। তুমি বলেছিলে:

আমরা পরামিতিটিকে কনস্ট হিসাবে চিহ্নিত করি যাতে নিশ্চিত হয়ে যায় যে তার রাজ্যটি পদ্ধতিতে পরিবর্তিত হবে না।

কনস্ট যদি বাস্তবে এটি করে থাকে তবে তা দুর্দান্ত হবে। কনস্ট এটি করে না। কনস্ট মিথ্যা!

কনস্ট কোনও গ্যারান্টি সরবরাহ করে না যা আমি আসলে ব্যবহার করতে পারি। ধরুন আপনার কাছে এমন একটি পদ্ধতি রয়েছে যা কোনও কনস্ট জিনিস নেয়। দুটি কোড লেখক রয়েছে: কলার লেখার ব্যক্তি এবং কলি লেখার ব্যক্তি । কলি লেখক এই পদ্ধতিটিকে একটি দৃ const়তা তৈরি করেছেন made দুটি লেখক কী ধারণা করতে পারেন যে বিষয়টি সম্পর্কে অদৃশ্য?

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

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

কনস্ট ইন সি একটি গাইডলাইন ; এর মূল অর্থ "আপনি এই জিনিসটিকে পরিবর্তনের চেষ্টা না করার জন্য আমাকে বিশ্বাস করতে পারেন"। এটি টাইপ সিস্টেমে থাকা উচিত নয় ; উপাদান টাইপ সিস্টেম একটি হওয়া উচিত সত্য বস্তু সম্পর্কে আপনি সম্পর্কে একটি না যুক্তি করতে গাইডলাইন ব্যবহারের জন্য।

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

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

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

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


34
দুঃখিত, তবে আমি এই যুক্তিটি খুব দুর্বল বলে মনে করি যে কোনও বিকাশকারী মিথ্যা বলতে পারে তা কোনও ভাষায়ই প্রতিরোধ করা যায় না। অকার্যকর foo (কনট এ এবং এ) যা বস্তুকে a সংশোধন করে তা int কাউন্টপ্লেস (ঝুড়ি খ) থেকে পৃথক নয় যা নাশপাতিগুলির সংখ্যা ফেরত দেয়। এটি কেবল একটি বাগ, যে কোনও ভাষায় সংকলিত একটি বাগ।
আলেসান্দ্রো তেরুজি

55
" কলি কনস্টটকে ফেলে দিতে নির্দ্বিধায় ... " ওহহহহহ… (° _ °) এটি আপনি এখানে তৈরি করছেন এটি একটি অগভীর যুক্তি। কলিটি কেবল এলোমেলো মেমরির অবস্থানগুলি সহ লিখতে শুরু করে 0xDEADBEEF। তবে উভয়ই খুব খারাপ প্রোগ্রামিং হবে এবং যে কোনও আধুনিক সংকলক তাড়াতাড়ি এবং মজাদারভাবে ধরা পড়ে। ভবিষ্যতে উত্তর লেখার সময় দয়া করে কোনও ভাষার পিছনের দরজা ব্যবহার করে প্রযুক্তিগতভাবে কী সম্ভব তা সত্যিকারের আসল-ওয়ার্ল্ড কোডে যা সম্ভব তা নিয়ে বিভ্রান্ত করবেন না। এর মতো স্কেওড তথ্য কম অভিজ্ঞ পাঠকদের বিভ্রান্ত করে এবং এসও-তে তথ্যের মানকে হ্রাস করে।
স্লিপ ডি থম্পসন

8
"কনস্ট ইন সি একটি গাইডলাইন;" আপনি যে কিছু কথা বলছেন তার জন্য উত্সকে উদ্ধৃত করা এখানে আপনার কেসকে সত্যই সহায়তা করবে। আমার শিক্ষা ও শিল্পের অভিজ্ঞতায় উদ্ধৃত বিবৃতিটি সিতে হোগওয়াশ কনস্টের মতো হ'ল বাধ্যতামূলক বিল্ট-ইন বৈশিষ্ট্য যেমন টাইপ সিস্টেম নিজেই রয়েছে - উভয়ই যখন প্রয়োজন হয় তখন তাদের ঠকানোর পিছনে দরজা রয়েছে (সত্যিকার অর্থে সি এর সবকিছুই) তবে প্রত্যাশিত কোড দ্বারা 99.99% বই ব্যবহার করা হবে।
স্লিপ ডি থম্পসন

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

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

24

সি # তে কোনও সংবিধানের নির্ভুলতা না থাকার একটি কারণ হ'ল এটি রানটাইম স্তরে বিদ্যমান নেই। মনে রাখবেন যে রান টাইমের অংশ না থাকলে সি # 1.0 এর কোনও বৈশিষ্ট্য ছিল না।

এবং সিএলআর-এর কাছে দৃ correct়তার সঠিক ধারণা না থাকার কয়েকটি কারণ উদাহরণস্বরূপ:

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

কনস্টের সঠিকতা কেবলমাত্র C ++ তে উপস্থিত একটি ভাষা বৈশিষ্ট্য in সুতরাং সিএলআর কেন চেক করা ব্যতিক্রম (যা জাভা ভাষার একমাত্র বৈশিষ্ট্য) এর প্রয়োজন হয় না কেন সেই একই যুক্তিতে অনেকটা উত্সাহিত হয়।

এছাড়াও, আমি মনে করি না যে আপনি পশ্চাদপটে সামঞ্জস্যতা না ভেঙে কোনও পরিচালিত পরিবেশে এই জাতীয় মৌলিক ধরনের সিস্টেম বৈশিষ্ট্যটি প্রবর্তন করতে পারেন। সুতরাং কখনও সি # বিশ্বে প্রবেশের দৃ const়তা সম্পর্কে বিশ্বাস করবেন না।


আপনি কি নিশ্চিত যে জেভিএম এর এটি নেই। আমি জানি এটি এটি আছে। আপনি জাভাতে সর্বজনীন স্ট্যাটিক অকার্যকর টেস্টমেথড (চূড়ান্ত ইন ভ্যাল) চেষ্টা করতে পারেন।
ছদ্ম

2
ফাইনাল আসলেই কনস্ট নয়। আপনি এখনও রেফারেন্স আইআইআরসি তে ক্ষেত্র পরিবর্তন করতে পারেন, কেবল মান / রেফারেন্স নয়। (যা যাইহোক মান দ্বারা পাস করা হয়, সুতরাং আপনাকে প্যারামিটারের মান পরিবর্তন করা থেকে বিরত করার জন্য এটি আরও সংকলক কৌশল))
রুবেন

1
আপনার 3 য় বুলেটটি কেবল আংশিকভাবে সত্য। বিসিএল কলগুলির জন্য কনস্ট্যান্ড প্যারামিটার থাকা কোনও ব্রেকিং হবে না কারণ তারা চুক্তিকে কেবল আরও বিশদভাবে বর্ণনা করে। "এই পদ্ধতিটি অবজেক্টের স্থিতি পরিবর্তন করবে না" এর বিপরীতে "এই পদ্ধতিটি আপনাকে একটি কনস্ট মান প্রদান করতে হবে" যা ভেঙে যাবে
রুন এফএস

2
এটি পদ্ধতির অভ্যন্তরে প্রয়োগ করা হয়েছে তাই এটি ছাত্রলীগে প্রবর্তন করা কোনও ব্রেকিং পরিবর্তন হবে না।
রুন এফএস

1
এমনকি রান-টাইম এটি প্রয়োগ করতে না পারলেও, এমন একটি বৈশিষ্ট্য পাওয়া সহায়ক হবে যা নির্দিষ্ট করে কোনও ফাংশনকে refপ্যারামিটারে লেখার অনুমতি দেওয়া / প্রত্যাশা করা উচিত (বিশেষত স্ট্রাক্ট পদ্ধতি / বৈশিষ্ট্যগুলির ক্ষেত্রে this)। যদি কোনও পদ্ধতি সুনির্দিষ্টভাবে বলে যে এটি কোনও refপ্যারামিটারে লিখবে না , তবে সংকলকটি কেবল পঠনযোগ্য মানগুলি পাস করার অনুমতি দেবে। বিপরীতভাবে, যদি কোনও পদ্ধতি এটি লিখতে বলে যে this, সংকলককে কেবল পঠনযোগ্য মানগুলিতে এই জাতীয় পদ্ধতিতে অনুরোধ করা উচিত নয়।
সুপারক্যাট

12

আমি বিশ্বাস করি যে দুটি কারণ সি # সঠিকভাবে সঠিক নয়।

প্রথমটি হ'ল বোধগম্যতা । কয়েকটি সি ++ প্রোগ্রামার কনস্ট-সঠিকতা বোঝে। এর সাধারণ উদাহরণটি const int argসুন্দর, তবে আমি এটিও দেখেছি char * const * const arg- অবিচ্ছিন্ন অক্ষরগুলির কাছে ধ্রুবক পয়েন্টারগুলির একটি ধ্রুবক পয়েন্টার। ফাংশনগুলিতে পয়েন্টারগুলিতে সংশোধন-নির্ভুলতা হ'ল সম্পূর্ণ নতুন স্তরে আবদ্ধ হওয়া।

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

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

যাইহোক, আমি বিশ্বাস করি এটি অসম্ভব: দ্বিতীয় কারণ (বাক্য গঠন) সমাধান করা বেশ কঠিন হবে, যা প্রথম কারণ (বোধগম্যতা) আরও বেশি সমস্যার সৃষ্টি করবে।


1
আপনি ঠিক বলেছেন যে সিএলআরকে সত্যই এই সম্পর্কে উদ্বিগ্ন হওয়ার দরকার নেই, যেহেতু কেউ তথ্য ব্যবহার করার জন্য modoptএবং modreqমেটাডেটা স্তরে এই তথ্য সংরক্ষণ করতে পারে (যেমন সি + / সি এল আই ইতিমধ্যে করেছে - দেখুন System.Runtime.CompilerServices.IsConst); এবং এটি তুচ্ছভাবে কনস্ট পদ্ধতিতেও প্রসারিত হতে পারে।
পাভেল মিনায়েভ

এটি সার্থক তবে একটি টাইপসেফ পদ্ধতিতে করা দরকার। আপনি যে গভীর / অগভীর কনড্রাস্টের কথা উল্লেখ করেছেন তা কীটপতঙ্গের পুরো ক্যানটি খোলে।
ব্যবহারকারীর 1496062

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

2
যে প্রোগ্রামাররা কনস্ট-নেস বুঝতে পারে না তাদের সি ++ এ প্রোগ্রামিং করা উচিত নয়।
স্টিভ হোয়াইট

5

constএর অর্থ সি # তে "কমপাইল-টাইম ধ্রুবক", সি ++ তে যেমন "কেবল পঠনযোগ্য নয় তবে অন্য কোড দ্বারা সম্ভবত পরিবর্তনযোগ্য"। constসি # তে সি ++ এর মোটামুটি এনালগ হয় readonlyতবে এটি কেবল ক্ষেত্রগুলিতে প্রযোজ্য। এ ছাড়া, কোনও সি ++ নেই - যেমন সি # তে কনস্ট্যান্ডের নির্ভুলতার ধারণা।

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


সুতরাং আপনারা মনে করেন এমএস পদ্ধতিতে কনস্টাম পরামিতি রাখতে 'শোরগোল' পছন্দ করে।
ছদ্ম

1
আমি "শব্দ" কী তা নিশ্চিত নই - আমি বরং এটিকে "উচ্চ ব্যয় / বেনিফিট অনুপাত" বলি call তবে অবশ্যই আপনার অবশ্যই সি # টিমের একজনের অবশ্যই আপনাকে অবশ্যই বলা দরকার।
পাভেল মিনায়েভ

সুতরাং আমি যেমন এটি আর্দ্রায়িত করি ততই আপনার যুক্তি হ'ল দৃ const়তাটিকে সহজ রাখার জন্য সি # এর বাইরে রাখা হয়েছিল। সেইটার জন্য ভাবেন.
স্টিভ হোয়াইট

2

এটি সি # 7.2 (ডিসেম্বর 2017 ভিজ্যুয়াল স্টুডিও 2017 15.5 সহ) এর পর থেকে সম্ভব।

কেবল স্ট্রাক্ট এবং বেসিক ধরণের জন্য ! , ক্লাসের সদস্যদের জন্য নয়।

আপনাকে অবশ্যই inযুক্তিটিকে রেফারেন্স দ্বারা ইনপুট হিসাবে প্রেরণ করতে হবে । দেখা:

দেখুন: https://docs.microsoft.com/en-us/dotnet/csharp/language-references/keywords/in-parameter-modifier

আপনার উদাহরণের জন্য:

....
static void TestMethod1(in MyStruct val)
{
    val = new MyStruct;  // Error CS8331 Cannot assign to variable 'in MyStruct' because it is a readonly variable
    val.member = 0;  // Error CS8332 Cannot assign to a member of variable 'MyStruct' because it is a readonly variable
}
....
static void TestMethod2(in int val)
{
    val = 0;  // Error CS8331 Cannot assign to variable 'in int' because it is a readonly variable
}
....
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.