আমার কেন স্ট্যান্ড :: get_temporary_buffer দরকার?


84

আমার কী উদ্দেশ্যে ব্যবহার করা উচিত std::get_temporary_buffer? স্ট্যান্ডার্ড নিম্নলিখিত বলে:

N সংলগ্ন টি অবজেক্টগুলি সঞ্চয় করার জন্য পর্যাপ্ত স্টোরেজটির পয়েন্টার পান।

আমি ভেবেছিলাম যে বাফারটি স্ট্যাকের জন্য বরাদ্দ করা হবে, তবে এটি সত্য নয়। সি ++ স্ট্যান্ডার্ড অনুসারে এই বাফারটি আসলে অস্থায়ী নয়। এই ফাংশনটির কী কী সুবিধা রয়েছে বিশ্বব্যাপী ফাংশন থেকে ::operator new, যা বস্তুগুলিও তৈরি করে না। আমি কি ঠিক বলছি যে নীচের বিবৃতিগুলি সমান?

int* x;
x = std::get_temporary_buffer<int>( 10 ).first;
x = static_cast<int*>( ::operator new( 10*sizeof(int) ) );

এই ফাংশনটি কি কেবল সিনট্যাক্স চিনির জন্য বিদ্যমান? কেন temporaryএর নামে আছে?


একটি ব্যবহারের ক্ষেত্রে ডাঃ ডবস জার্নালে, জুলাই 01, 1996 এ অ্যালগরিদম বাস্তবায়নের জন্য পরামর্শ দেওয়া হয়েছিল :

যদি কোনও বাফার বরাদ্দ না করা যায়, বা যদি এটি অনুরোধের চেয়ে ছোট হয় তবে অ্যালগরিদম এখনও সঠিকভাবে কাজ করে, এটি কেবল ধীর হয়ে যায়।


4
এফওয়াইআই, std::get_temporary_bufferসি ++ 17 এ অবমুক্ত করা হবে।
ডেকিং

4
@ ডিকিং হ্যাঁ এটি সি ++ ২০ এ এবং ভাল কারণে (নীচে উল্লিখিত হিসাবে) মুছে ফেলা হবে। সুতরাং দর্শকদের সাথে সরানো ..
নিকস

উত্তর:


44

স্ট্রোভস্ট্রুপের মধ্যে বলছেন "সি ++ Programming Language" ( §19.4.4 , ব):

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

তিনি দুটি ক্রিয়াকলাপের সাথে পরিচয়ও শুরু করেন:

অ্যালগরিদমগুলি প্রায়শই গ্রহণযোগ্যভাবে সম্পাদনের জন্য অস্থায়ী স্থানের প্রয়োজন হয়।

... তবে কোথাও অস্থায়ী বা দীর্ঘমেয়াদী সংজ্ঞা দেওয়া হয়নি বলে মনে হচ্ছে ।

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

অবাক করে দিয়ে তিনি কয়েক বছর পরে আবিষ্কার করেছিলেন যে এসটিএল বাস্তবায়ন সরবরাহকারী সমস্ত বড় বিক্রেতারা এখনও এই ভয়ঙ্কর বাস্তবায়ন ব্যবহার করছেন [...]


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

9
জি ++ 4.5 এর সাথে একই - মনে হয় এটি ভাল উদ্দেশ্যযুক্ত কিন্তু বিক্রেতারা অগ্রাহ্য করেছেন।
জর্জিট ফ্রিজচে

4
তাদের মত শোনা উচিত যে তাদের এই কার্যকারিতাটি ক্লাসে আবৃত করা উচিত ছিলcrazy_allocator
0xbadf00d

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

@ জাল্ফ এটি সি ++ 17 :) এ অবমূল্যায়িত হয়েছে ( সিপ্রেফারেন্স.কম অনুসারে )।
4LegsDrivenCat

17

মাইক্রোসফ্টের স্ট্যান্ডার্ড লাইব্রেরি লোকটি নিম্নলিখিতটি এখানে ( এখানে ) বলেছেন :

  • আপনি কখন 'get_temporary_buffer' ব্যবহার করবেন তা ব্যাখ্যা করতে পারেন

এটির একটি খুব বিশেষ উদ্দেশ্য রয়েছে। মনে রাখবেন যে এটি নতুন (নোহ্রো) এর মতো ব্যতিক্রম ছুঁড়ে না, তবে এটি নতুন (নোহ্রো) এর বিপরীতে বস্তুগুলিও তৈরি করে না।

এটি অভ্যন্তরীণভাবে স্ট্যাটিলে_ পার্টিশন () এর মতো অ্যালগরিদমে এসটিএল দ্বারা ব্যবহৃত হয়। এটি ঘটে যখন N3126 25.3.13 [alg.partitions] / 11 এর মতো ম্যাজিক শব্দ থাকে: স্থিতি_ পার্টিশন () এর জটিলতা থাকে "সর্বাধিক (শেষ - প্রথম) * লগ (শেষ - প্রথম) অদলবদল, তবে কেবলমাত্র লিনিয়ার সংখ্যার অদলবদল যদি সেখানে থাকে যথেষ্ট অতিরিক্ত স্মৃতিশক্তি " যখন "যদি অতিরিক্ত অতিরিক্ত মেমরি থাকে তবে" যাদু শব্দগুলি উপস্থিত হয়, এসটিএল কাজের স্থান অর্জনের জন্য get_temporary_buffer () ব্যবহার করে। যদি এটি করতে পারে তবে এটি আরও দক্ষতার সাথে অ্যালগরিদমটি প্রয়োগ করতে পারে। যদি এটি না পারে, কারণ সিস্টেমটি বিপজ্জনকভাবে মেমোরির বাইরে চলেছে (বা জড়িত ব্যাপ্তিগুলি বিশাল)

এসটিএল 999% ব্যবহারকারীদের get_temporary_buffer () সম্পর্কে কখনও জানতে হবে না।


9

স্ট্যান্ডার্ড বলছে এটি উপাদান পর্যন্ত স্টোরেজ বরাদ্দ nকরে। অন্য কথায়, আপনার উদাহরণটি কেবল 5 টি সামগ্রীর জন্য যথেষ্ট পরিমাণে বড় বাফারকে ফিরিয়ে দিতে পারে।

যদিও এটির জন্য ভাল ব্যবহারের ক্ষেত্রে কল্পনা করা বেশ কঠিন বলে মনে হচ্ছে। সম্ভবত আপনি যদি খুব স্মৃতি-সীমাবদ্ধ প্ল্যাটফর্মে কাজ করছেন তবে এটি "যথাসম্ভব স্মৃতিশক্তি" পাওয়ার সুবিধাজনক উপায়।

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


4

কী উদ্দেশ্যে আমার ব্যবহার করা উচিত std::get_temporary_buffer?

ফাংশনটি সি ++ 17 এ অবমূল্যায়ন করা হয়েছে, সুতরাং সঠিক উত্তর এখন "অকারণে, এটি ব্যবহার করবেন না"।


2
ptrdiff_t            request = 12
pair<int*,ptrdiff_t> p       = get_temporary_buffer<int>(request);
int*                 base    = p.first;
ptrdiff_t            respond = p.sencond;
assert( is_valid( base, base + respond ) );

প্রতিক্রিয়া অনুরোধ চেয়ে কম হতে পারে ।

size_t require = 12;
int*   base    = static_cast<int*>( ::operator new( require*sizeof(int) ) );
assert( is_valid( base, base + require ) );

বেসের আসল আকারটি প্রয়োজনের চেয়ে বৃহত্তর বা সমান হতে হবে


2

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

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


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

আমি এখন দেখেছি যে বর্জন এ সম্পর্কে কী বলে এবং তিনি বলেছেন যে এটি প্রাথমিকভাবে ছাড়াই দ্রুত বরাদ্দের জন্য তৈরি করা হয়েছে। সুতরাং এটি কেবলমাত্র বরাদ্দকারী (অ প্রাথমিককরণ) শূন্য * অপারেটর নতুন (আকার_t আকার) এর মতো হবে তবে এটি বরাদ্দকরণের চেয়ে দ্রুত, কারণ এটি পূর্ব বরাদ্দ করা হয়েছে।
ড্যানিয়েল মুনোজ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.