সি ++ 11 ডায়ামিক / শেয়ার্ড লাইব্রেরির সীমানার মধ্যে স্টাড লাইব অবজেক্টগুলি পাস করার উদ্বেগকে সম্বোধন করেছে? (যেমন dlls এবং তাই)?

Question

সি ++ সম্পর্কে আমার একটি বড় অভিযোগ হ'ল ডায়নামিক লাইব্রেরির (যেমন dll / so) গণ্ডির বাইরে স্টাড লাইব্রেরি অবজেক্টগুলি পাস করা অনুশীলনে কতটা কঠিন।

স্ট্যান্ড লাইব্রেরি প্রায়শই কেবল শিরোনাম হয়। যা কিছু দুর্দান্ত অপ্টিমাইজেশান করার জন্য দুর্দান্ত। তবে, dll এর জন্য এগুলি প্রায়শই বিভিন্ন সংকলক সেটিংস দিয়ে নির্মিত হয় যা কোনও স্টাড লাইব্রেরি পাত্রে অভ্যন্তরীণ কাঠামো / কোডকে প্রভাবিত করতে পারে। উদাহরণস্বরূপ, এমএসভিসিতে একটি dll পুনরুদ্ধারকারী ডিবাগিং দিয়ে তৈরি করতে পারে অন্যটি এটি বন্ধ করে দেয়। এই দুটি dlls চারপাশে স্ট্যান্ড কনটেইনার পাস করার ইস্যুতে চলতে পারে। যদি আমি এক্সপোজ std::stringআমার ইন্টারফেসে, আমি নিশ্চয়তা দিতে পারে না কোড ক্লায়েন্টের জন্য ব্যবহার করছে std::stringআমার লাইব্রেরির একজন সঠিক মিল IS std::string।

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

আমার প্রশ্ন হ'ল সি ++ 11 এই সমস্যাগুলি সমাধান করার জন্য কিছু করার চেষ্টা করেছিল কিনা?

Comments

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

— ডোনাল ফেলো

দয়া করে পার্থক্য করুন এটা এস এর মধ্যে কঠিন DLL। এর মধ্যে SOএটি সর্বদা ঠিক কাজ করে।

— জানু হুডেক

কড়া কথায় বলতে গেলে, এটি কেবল সি ++ সমস্যা নয়। অন্যান্য ভাষার সাথে এই সমস্যা থাকা সম্ভব।

— মিঃফক্স

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

— এসডিজি

@ এসডিজি: ডিফল্ট পতাকা এবং ডিফল্ট দৃশ্যমানতার সাথে এটি কাজ করে। আপনি যদি এগুলি পরিবর্তন করেন এবং সমস্যায় পড়েন তবে এটি আপনার সমস্যা এবং অন্য কারও নয়।

— জানু হুডেক

Answer 1

আপনি যেটি এসটিএল ঠিক করেছেন - আসলে তৃতীয় পক্ষের লাইব্রেরির যে কোনও কিছু যা টেম্প্লেটেড - কোনও পাবলিক সি ++ এপিআই এ সেরা এড়ানো হবে। আপনি নিয়মাবলীর দীর্ঘ তালিকা অনুসরণ করতে চান http://www.ros.org/reps/rep-0009.html#deber ABI ভাঙ্গন রোধ করার জন্য সংজ্ঞা যা প্রোগ্রামিংকে জনসাধারণের সি +++ এপিআইগুলিকে স্বাচ্ছন্দ্যময় করে তোলে।

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

শেষ অবধি, আমি অনেকগুলি এমএসভিসি ঘৃণা এবং জিসিসির পক্ষের মন্তব্যগুলি দেখছি। এগুলি খুব ভুল তথ্যযুক্ত - ELF- তে জিসিসি মূলত এবং অপ্রত্যাশিতভাবে বৈধ এবং সঠিক সি ++ কোড তৈরি করতে অক্ষম। এর কারণগুলি অনেকগুলি এবং সৈন্যদল, তবে আমি খুব শীঘ্রই একটি কেস উদাহরণ উদ্ধৃত করব: ELF- তে জিসিসি সুরক্ষিতভাবে বুস্ট.পাইথন ব্যবহার করে লিখিত পাইথন এক্সটেনশনগুলি উত্পাদন করতে পারে না যেখানে বুস্ট. পাইথনের উপর ভিত্তি করে একাধিক এক্সটেনশন পাইথনে লোড হয়। এজন্য যে ইএলএফ এর গ্লোবাল সি সিম্বল টেবিল সহ ওডিআর লঙ্ঘনগুলি সেগফাল্টগুলির কারণ হিসাবে রোধ করার নকশার দ্বারা কেবলমাত্র অক্ষম, যদিও পিই এবং ম্যাকো এবং প্রকৃতপক্ষে প্রস্তাবিত সি ++ মডিউলগুলি সমস্ত মডিউল প্রতীক টেবিল ব্যবহার করে - যা ঘটনাক্রমে ব্যাপকভাবে প্রক্রিয়া সূচনাকালীন সময়েও বোঝায়। এবং আরও অনেক সমস্যা রয়েছে: একটি স্ট্যাক ওভারফ্লো দেখুন যা আমি সম্প্রতি উত্তর দিয়েছিhttps://stackoverflow.com/questions/14268736/symbol-visibility-exferences-runtime-error/14364055#14364055 উদাহরণস্বরূপ যেখানে সি ++ ব্যতিক্রম নিক্ষেপগুলি ELF এ মৌলিকভাবে ভাঙা হয়েছে।

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

Comments

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

— আলেসান্দ্রো স্টাম্যাটটো

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

— নিলাল ডগলাস

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

— আলেসান্দ্রো স্টাম্যাটটো

সমস্ত তৃতীয় পক্ষের টেম্পলেট সন্দেহজনক বলে দেওয়ার জন্য -1 কনফিগারেশন পরিবর্তন জিনিস কনফিগার করা হচ্ছে একটি টেমপ্লেট স্বাধীন কিনা।

— ডেড এমএমজি 17'13

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

— নিলাল ডগলাস

Answer 2

স্পেসিফিকেশন কখনও এই সমস্যা ছিল না। কারণ এটি "ওয়ান ডেফিনিশন রুল" নামে ধারণা রয়েছে যা চলমান প্রক্রিয়াতে প্রতিটি প্রতীকটির ঠিক একটি সংজ্ঞা রয়েছে বলে নির্দেশ দেয়।

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

উইন্ডোজ ডিএলএল একটি সংজ্ঞা বিধি লঙ্ঘন করে কারণ:

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

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

---

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

Comments

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

— জানু হুডেক

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

— জানু হুডেক

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

— মার্টিন বা

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

— জানু হুডেক

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

— ইউরো মিশেল্লি

Answer 3

না।

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

Comments

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

— জানু হুডেক

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

— পল মিশালিক

@ পোলমিচালিক সি ++ লিঙ্ক লিঙ্কটি কভার করে (9 ম পর্যায়) এবং এটি আমার কাছে মনে হয় যে কমপক্ষে ডিএলএল / এসওগুলির লোড-টাইম লিঙ্কিংটি পর্ব 9 এর মধ্যে চলে আসে That এর অর্থ হ'ল বাহ্যিক সংযোগের সাথে প্রতীকগুলি (রফতানি হোক বা না) লিঙ্কযুক্ত এবং মেনে চলতে হবে ওডিআর। লোডলিবারি / ড্লোপেনের সাথে ডায়নামিক লিঙ্কিং স্পষ্টত সেই প্রয়োজনীয়তার আওতায় পড়ে না।

— bames53

@ বেমস ৩৩: আইএমএইচও, এই ধরণের বক্তব্যের অনুমতি দেওয়ার জন্য চশমাগুলি খুব দুর্বল। একটি .dll / .so এর নিজস্ব হিসাবে একটি "প্রোগ্রাম" হিসাবে দেখা যেতে পারে। তদ্ব্যতীত, বিধিগুলি সন্তুষ্ট ছিল। রান-টাইমে অন্যান্য "প্রোগ্রামগুলি" লোড করার মতো কিছু মানদণ্ডের দ্বারা এতটাই সংক্ষিপ্ত হয়ে যায় যে এ সম্পর্কিত কোনও বিবৃতিটি বেশ স্বেচ্ছাচারী।

— পল মিশালিক

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

— বেমস 5৩