এইচটি :: ম্যাপের কীগুলি থেকে রিসোর্স চুরি করা অনুমোদিত?


15

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

প্রশ্ন : আমি কি কোনও সমস্যা ছাড়াই এটি করতে পারি বা mapএটির জন্য যেমন অপ্রত্যাশিত বাগগুলি যেমন ডেস্ট্রাক্টর এর কারণ হতে পারে যা আমি এটি এমনভাবে অ্যাক্সেস করি std::mapনি যার জন্য নয়?

এখানে একটি উদাহরণ প্রোগ্রাম:

#include<map>
#include<string>
#include<vector>
#include<iostream>
using namespace std;
int main(int argc, char *argv[])
{
    std::vector<std::pair<std::string,double>> v;
    { // new scope to make clear that m is not needed 
      // after the resources were stolen
        std::map<std::string,double> m;
        m["aLongString"]=1.0;
        m["anotherLongString"]=2.0;
        //
        // now steal resources
        for (auto &p : m) {
            // according to my IDE, p has type 
            // std::pair<const class std::__cxx11::basic_string<char>, double>&
            cout<<"key before stealing: "<<p.first<<endl;
            v.emplace_back(make_pair(std::move(const_cast<string&>(p.first)),p.second));
            cout<<"key after stealing: "<<p.first<<endl;
        }
    }
    // now use v
    return 0;
}

এটি আউটপুট উত্পাদন করে:

key before stealing: aLongString
key after stealing: 
key before stealing: anotherLongString
key after stealing: 

সম্পাদনা: আমি একটি বড় মানচিত্রের সম্পূর্ণ সামগ্রীর জন্য এটি করতে চাই এবং এই উত্স চুরির মাধ্যমে গতিশীল বরাদ্দ সংরক্ষণ করতে চাই।


3
এই "চুরি" এর উদ্দেশ্য কী? মানচিত্র থেকে উপাদান সরাতে? তাহলে কেন কেবল তা (মানচিত্র থেকে উপাদানটি মুছবেন) না? এছাড়াও, একটি constমান পরিবর্তন করা সর্বদা ইউবি হয়।
কিছু প্রোগ্রামার ডিউড

স্পষ্টতই এটি গুরুতর বাগগুলি নিয়ে যাবে!
রেজায়েব

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

1
@ ALX23z আপনার কাছে এই বক্তব্যের কোনও উত্স আছে? আমি ভাবতে পারছি না কীভাবে কোনও পয়েন্টার অনুলিপি করা মেমরির পুরো অঞ্চলটি অনুলিপি করার চেয়ে ব্যয়বহুল।
সেবাস্তিয়ান হফম্যান

1
@ সেবাস্তিয়ানহফম্যানের সাম্প্রতিক সিপ্পিকনে এটি উল্লেখ করা হয়েছিল যে কোন আলাপ সম্পর্কে নিশ্চিত নয়। জিনিসটির std::stringস্বল্প-স্ট্রিং অপ্টিমাইজেশন রয়েছে। এর অর্থ যে অনুলিপি করা এবং চালনা করার বিষয়ে কিছু অ-তুচ্ছ যুক্তি রয়েছে এবং কেবল পয়েন্টার এক্সচেঞ্জই নয় এবং বেশিরভাগ সময় মুভিং করাকে বোঝানো হয় - যাতে আপনি দীর্ঘ স্ট্রিংয়ের সাথে ডিল করেন না। পরিসংখ্যানগত পার্থক্য যাই হোক না কেন ছোট ছিল এবং সাধারণত এটি স্ট্রিং প্রসেসিংয়ের ধরণের উপর নির্ভর করে অবশ্যই তা পরিবর্তিত হয় surely
ALX23z

উত্তর:


18

আপনি const_castএকটি constপরিবর্তনশীল সংশোধন করতে ব্যবহার করে অপরিজ্ঞাত আচরণ করছেন । এটা করবেন না। এর কারণ constহ'ল মানচিত্রগুলি তাদের কী অনুসারে বাছাই করে। তাই জায়গায় জায়গায় একটি কী সংশোধন করা মানচিত্রটি অন্তর্নিহিত অন্তর্নিহিত অনুমানটি ভঙ্গ করছে।

আপনার কোনও পরিবর্তনশীল থেকে const_castঅপসারণ এবং সেই পরিবর্তনশীলটি সংশোধন করার জন্য কখনও ব্যবহার করা উচিত নয় ।const

বলা হচ্ছে, সি ++ 17 আপনার সমস্যার সমাধান রয়েছে: std::mapএর extractফাংশন:

#include <map>
#include <string>
#include <vector>
#include <utility>

int main() {
  std::vector<std::pair<std::string, double>> v;
  std::map<std::string, double> m{{"aLongString", 1.0},
                                  {"anotherLongString", 2.0}};

  auto extracted_value = m.extract("aLongString");
  v.emplace_back(std::make_pair(std::move(extracted_value.key()),
                                std::move(extracted_value.mapped())));

  extracted_value = m.extract("anotherLongString");
  v.emplace_back(std::make_pair(std::move(extracted_value.key()),
                                std::move(extracted_value.mapped())));
}

এবং না using namespace std;। :)


ধন্যবাদ, আমি এটি চেষ্টা করব! তবে আপনি কি নিশ্চিত যে আমি যেমন করেছিলাম তেমন করতে পারি না? মানে আমি mapঅভিযোগ করব না যদি আমি এর পদ্ধতিগুলি না বলি (যা আমি করি না) এবং অভ্যন্তরীণ ক্রমটি তার ধ্বংসকারীটির পক্ষে গুরুত্বপূর্ণ না?
ফিনজ

2
মানচিত্রের কীগুলি তৈরি করা হয়েছে const। কোনও constবস্তুকে রূপান্তর করা হ'ল তাত্ক্ষণিক ইউবি, পরে কিছু আসলে তাদের অ্যাক্সেস করে কিনা।
HTNW

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

2
@ ফিনজ যেমন আপনি পুনরুক্তিটিতে দেখতে পাচ্ছেন extract যখন পুনরাবৃত্তি হিসাবে আর্গুমেন্ট ব্যবহার করার সময় ধ্রুবক জটিলতা রীতিমতো পরিণত হয়েছে। কিছু ওভারহেড অনিবার্য, তবে এটি সম্ভবত যথেষ্ট পরিমাণে গুরুত্বপূর্ণ হবে না। আপনার যদি বিশেষ প্রয়োজনীয়তাগুলি এর আওতাভুক্ত না হয় তবে আপনাকে mapএই প্রয়োজনীয়তাগুলি সন্তুষ্ট করে নিজের প্রয়োগ করতে হবে। stdপাত্রে সাধারণ সাধারণ কাজের application.They জন্য বোঝানো হয় নির্দিষ্ট ব্যবহারের ক্ষেত্রে জন্য অপ্টিমাইজ করা হয় না।
আখরোট

@ এইচটিএনডাব্লু আপনি কি কীগুলি তৈরির বিষয়ে নিশ্চিত const? এই ক্ষেত্রে আপনি দয়া করে আমার যুক্তিটি কোথায় ভুল তা নির্দেশ করতে পারেন ।
ফিনজ

4

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

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

উদ্বেগ

এই নকশাটি নিয়ে বেশ কয়েকটি উদ্বেগ উত্থাপিত হয়েছে। আমরা তাদের এখানে সম্বোধন করব।

অপরিবর্তিত আচরণ

তাত্ত্বিক দৃষ্টিকোণ থেকে এই প্রস্তাবের সবচেয়ে কঠিন অংশটি হ'ল নিষ্কাশিত উপাদানটি তার কনস্টের মূল ধরণটি ধরে রাখে। এটি এর বাইরে চলে যাওয়া বা এটি পরিবর্তন করতে বাধা দেয়। এটি সমাধানের জন্য, আমরা কী অ্যাকসেসর ফাংশন সরবরাহ করেছি, যা নোড হ্যান্ডেল দ্বারা পরিচালিত উপাদানটিতে কীটিতে অবিচ্ছিন্ন অ্যাক্সেস সরবরাহ করে। সংকলক অপ্টিমাইজেশনের উপস্থিতিতে এটি সঠিকভাবে কাজ করে তা নিশ্চিত করার জন্য এই ফাংশনটির বাস্তবায়ন "যাদু" প্রয়োজন। এটি করার একটি উপায় হ'ল pair<const key_type, mapped_type> এবং এর ইউনিয়নের সাথে pair<key_type, mapped_type>। এগুলির মধ্যে রূপান্তরটি std::launderনিষ্কাশন এবং পুনরায় অন্তর্ভুক্তির অনুরূপ একটি প্রযুক্তি ব্যবহার করে নিরাপদে প্রভাবিত হতে পারে ।

আমরা অনুভব করি না যে এটি কোনও প্রযুক্তিগত বা দার্শনিক সমস্যা তৈরি করেছে। কারণ স্ট্যান্ডার্ড লাইব্রেরী বিদ্যমান এক অ পোর্টেবল এবং ঐন্দ্রজালিক কোডটি ক্লায়েন্ট পোর্টেবল C ++ (যেমন লিখতে পারি না লিখতে হয় <atomic>, <typeinfo>, <type_traits>, ইত্যাদি)। এটি ঠিক এরকম আরও একটি উদাহরণ। এই যাদুটি বাস্তবায়নের জন্য সংকলক বিক্রেতাদের যা যা প্রয়োজন তা হ'ল তারা ইউনিয়নগুলিতে অপ্টিমাইজেশনের উদ্দেশ্যে ইউনিয়নগুলিতে অপরিজ্ঞাত আচরণটি ব্যবহার করে না — এবং বর্তমানে কম্পাইলাররা ইতিমধ্যে এটি প্রতিশ্রুতি দেয় (যে পরিমাণে এখান থেকে এটি গ্রহণ করা হচ্ছে)।

এটি ক্লায়েন্টের উপর একটি বিধিনিষেধ আরোপ করে যে, যদি এই ফাংশনগুলি ব্যবহার করা হয় তবে এর চেয়ে আলাদা লেআউট রয়েছে এমনটিকে std::pairবিশেষীকরণ করা যায় না । আমরা বাস্তবে যে কেউ এটি করতে চায় তার সম্ভাবনা কার্যকরভাবে শূন্য এবং আমরা আনুষ্ঠানিক ভাষায় আমরা এই জোড়গুলির কোনও বিশেষায়িতকরণকে সীমাবদ্ধ করি না।pair<const key_type, mapped_type>pair<key_type, mapped_type>

নোট করুন যে মূল সদস্য ফাংশনটি এমন একমাত্র জায়গা যেখানে এই জাতীয় কৌশলগুলি প্রয়োজনীয় এবং পাত্রে বা জোড়ায় কোনও পরিবর্তন প্রয়োজন হয় না।

(জোর আমার)


এটি আসলে মূল প্রশ্নের উত্তরের একটি অংশ তবে আমি কেবল একটি গ্রহণ করতে পারি।
phinz

0

আমি মনে করি না যে এই const_castপরিবর্তন এবং পরিবর্তন এই ক্ষেত্রে অনির্ধারিত আচরণের দিকে নিয়ে যায় তবে দয়া করে মন্তব্য করুন যে এই যুক্তিটি সঠিক কিনা।

এই উত্তর দাবি করে যে

অন্য কথায়, আপনি যদি কোনও মূল কনস্ট অবজেক্টটি সংশোধন করেন এবং অন্যথায় না করেন তবে আপনি ইউবি পাবেন।

সুতরাং v.emplace_back(make_pair(std::move(const_cast<string&>(p.first)),p.second));প্রশ্নের লাইনটি ইউবিতে নেতৃত্ব দেয় না যদি এবং কেবলমাত্র যদি stringঅবজেক্টটি p.firstকোনও কনস্ট অবজেক্ট হিসাবে তৈরি করা হয় নি। এখন উল্লেখ্য যে রাজ্যগুলি সম্পর্কে রেফারেন্সextract

একটি নোড উত্তোলন উত্তোলক উপাদান থেকে পুনরাবৃত্তকারীকে অবৈধ করে তোলে। নিষ্কাশিত উপাদানের পয়েন্টার এবং রেফারেন্সগুলি বৈধ থাকে, তবে উপাদানটি নোড হ্যান্ডেলের মালিকানাধীন থাকা অবস্থায় ব্যবহার করা যায় না: যদি উপাদানটি কোনও ধারক মধ্যে inোকানো হয় তবে সেগুলি ব্যবহারযোগ্য হয়ে ওঠে।

সুতরাং যদি আমি সংশ্লিষ্ট , সেটির সংগ্রহস্থল অবস্থানে বাস চলতে। তবে নিষ্কাশনের পরে, আমাকে ড্রাগকম্যানির উত্তরের কোডের মতো সংস্থানগুলি সরিয়ে দেওয়ার অনুমতি দেওয়া হয়েছে । এর অর্থ এই যে তাই আরো বস্তুর ছিল না const অবজেক্ট হিসেবে মূলত তৈরি করা হয়েছে।extractnode_handleppmoveppstringp.first

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

হালনাগাদ

আমি এখন এই মতামত যে এই উত্তরটি ভুল। আমি এটি মুছে ফেলছি না কারণ এটি অন্যান্য উত্তর দ্বারা রেফারেন্স করা হয়েছে।


1
দুঃখিত, ফিনজ, আপনার উত্তরটি ভুল। আমি এটি ব্যাখ্যা করতে একটি উত্তর লিখব - এটি ইউনিয়নগুলির সাথে কিছু করার আছে এবং std::launder
এলএফ

-1

সম্পাদনা: এই উত্তরটি ভুল। দয়া করে মন্তব্যগুলি ভুলগুলি চিহ্নিত করেছে, তবে আমি এটি মুছে ফেলছি না কারণ এটি অন্যান্য উত্তরে উল্লেখ করা হয়েছে।

@ द्रুকম্যান আপনার প্রথম প্রশ্নের জবাব দিয়েছিল, এতে বলা হয়েছে যে কীগুলি mapবল প্রয়োগ করার ফলে mapঅভ্যন্তরীণ ডেটা কাঠামোটি নির্মিত হয়েছে এমন সুশৃঙ্খলা ভঙ্গ করে (লাল-কালো গাছ)। তবে extractপদ্ধতিটি ব্যবহার করা নিরাপদ কারণ এটি দুটি কাজ করে: কীটি মানচিত্রের বাইরে সরিয়ে নিয়ে মুছে ফেলুন, সুতরাং এটি মানচিত্রের সুশৃঙ্খলাটিকে মোটেই প্রভাব ফেলবে না।

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


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

আমি যথাক্রমে এমএসভিসি 14.24.28314 এবং ক্ল্যাং 9.0.0 ব্যবহার করে দুটি পরীক্ষাও করেছিলাম এবং তারা একই ফলাফল পেয়েছিল।

map<string, int> m;
m.insert({ "test", 2 });
m.insert({ "this should be behind the 'test' string.", 3 });
m.insert({ "and this should be in front of the 'test' string.", 1 });
string let_me_USE_IT = std::move(const_cast<string&>(m.find("test")->first));
cout << let_me_USE_IT << '\n';
for (auto const& i : m) {
    cout << i.first << ' ' << i.second << '\n';
}

আউটপুট:

test
and this should be in front of the 'test' string. 1
 2
this should be behind the 'test' string. 3

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

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


2
"ডিকনস্ট্রাক্ট করার সময় এটি সমস্যা সৃষ্টি করবে কিনা তা সমস্যা নয়" " প্রযুক্তিগতভাবে সঠিক, যেহেতু পূর্বনির্ধারিত আচরণ (কোনও constমান পরিবর্তন করা ) এর আগে ঘটেছিল। তবে, " move[[ফাংশন] " আর্গুমেন্টটি নিশ্চিত করে যে কোনও শ্রেণীর স্থানান্তরিত হওয়ার পরে এটি [অবজেক্ট]] ডিকনস্ট্রাক্ট করা নিরাপদ "এটি ধারণ করে না: আপনি কোনও constবস্তু / রেফারেন্স থেকে নিরাপদে সরাতে পারবেন না , যেহেতু এর জন্য পরিবর্তন প্রয়োজন, যা constবাধা দেয়। আপনি ব্যবহার করে এই সীমাবদ্ধতাটি ঘিরে কাজ করার চেষ্টা করতে পারেন const_cast, তবে সেই মুহুর্তে আপনি ইউবি না হলে আপনি গভীরভাবে বাস্তবায়নের সুনির্দিষ্ট আচরণের দিকে চলে যাচ্ছেন।
হাফমেল

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

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

তবে এখানে আমি মনে করি যে আমরা নিশ্চিত হতে পারি যে অবজেক্টগুলি কেবল পঠনযোগ্য স্মৃতিতে রাখা হয়নি কারণ পরে extract, আমরা খুব একই বস্তু থেকে সরানোর অনুমতি পেয়েছি, তাই না? (আমার উত্তর দেখুন)
phinz

1
দুঃখিত, আপনার উত্তরের বিশ্লেষণটি ভুল। আমি এটি ব্যাখ্যা করতে একটি উত্তর লিখব - এটি ইউনিয়নগুলির সাথে কিছু করার আছে এবংstd::launder
এলএফ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.