سؤال

في C ++، أعتقد أن طريقة أفضل للتعامل مع إعادة التخصيص هي استخدام متجهات STL، حيث تضمن مواقع التخزين المتجاورة.

لدي سؤال زوجين لفهم الفرق:

  1. هل هناك أي سيناريو أحتاج إليه RealLoc. أكثر من ناقلات؟
  2. هل هناك أي شيء آخر (بصرف النظر عن ناقل) ما يعادل RealLoc. في C ++؟

شكرا،

هل كانت مفيدة؟

المحلول

هذا فقط vector, ، وهو مضمون أن يكون لديك ذاكرة متجاورة. ليس الآخرين.

realloc هي وظيفة إدارة الذاكرة C. لا يتم تشجيع استخدامه في رمز C ++. إليك Stristrup تخبرك لماذا: لماذا لا تحتوي C ++ أي ما يعادل Reallec ()؟

ومع ذلك، فإن REALLOC () مضمون فقط للعمل على المصفوفات المخصصة بواسطة maloc () (والوظائف المماثلة) التي تحتوي على كائنات دون منشئ نسخ محددة من قبل المستخدم. أيضا، يرجى تذكر أن هذا يتعارض مع توقعات ساذجة، Reallec () في بعض الأحيان نسخ صفيف حجيتها.

نصائح أخرى

مجموعة وظائف C (malloc، calloc، reallec، مجانا) هي عمليات الذاكرة الخام. سيقومون بإنشاء / تعديل / إصدار / مخزن مؤقت معين في الذاكرة، ولكن الذاكرة لن يكون لها أي نوع ولا يتم استدعاء أي منشئين.

C ++ ليس لديه ما يعادل RealLoc., ، ولكن فقط systyfeafe تعادل malloc / مجانا من خلال استخدام جديد جديد[ و حذف / حذف [. وبعد إصدارات C ++ ستحصل على الذاكرة من النظام و تهيئة ذلك عن طريق استدعاء المنشئين المناسبين. استخدام حذف سوف ندعو المدمرين للكائنات ثم حرر الذاكرة. إصدارات C و C ++ غير متوافقة، إذا حصلت على الذاكرة malloc. (حتى إذا قمت بتسمية المنشئ في الموقع في الذاكرة المستلمة) لا يمكنك إصدارها حذف / حذف [ لأنها سلوك غير محدد.

استخدام RealLoc. في C ++ قد تكون غير آمنة، حيث سيتم نسخ الكائنات Bitwise من منطقة ذاكرة واحدة إلى التالي. في بعض الأحيان لن تتعامل الكائنات الخاصة بك بشكل صحيح مع تحركات الذاكرة (قل أن الكائن الخاص بك يحتوي على سمة وإشارة إليها، بعد تحريكها Bitwise، ستظهر المرجع إلى الموضع القديم بدلا من السمة الحقيقية). في داخل المتجه, ، كلما تحتاج الذاكرة إلى النمو، يتم الحصول على ذاكرة جديدة مع الجديد[ ثم جميع الكائنات هي نسخة (أو نسخ مصممة) في المراكز الجديدة باستخدام عمليات C ++ المناسبة قبل حذف العناصر القديمة.

حينما المتجه ينمو في الحجم (الحجم المحجوز، غير المستخدمة الحجم) سيقوم بإنشاء منطقة ذاكرة جديدة كاملة و نقل جميع الكائنات. من ناحية أخرى، ستقوم RealLoc بنقل كتلة الذاكرة فقط إلى موضع آخر إذا لم يكن هناك مساحة متجاورة كافية بعد المؤشر تنمو هو - هي. ثلاثة أبعاد لا تقلل من الحجم. أبدا. عند مسح العناصر، لا تزال الذاكرة المحجوزة محتفظ بها.

أخيرا، هناك مستوى أعلى من التجريد في المتجه مما كانت عليه في RealLoc حتى بالنسبة لأنواع الجراب (من الآمن أن يتم نقلها بتشبئ C-Like). ما يعادل ذلك المتجه سيكون هو بنية تحمل المؤشر إلى مخزن المؤشرات العازلة للذاكرة، وعدد العناصر المستخدمة ومجموعة محفوظة (حجم المخزن المؤقت) ومجموعة الوظائف التي تتعامل مع الحصول على المزيد من الذاكرة حسب الحاجة وتحديث الفهارس مع كل عملية.

يتم ضمان الذاكرة المتجاورة أيضا بواسطة RealLoc لذلك هذا ليس سببا لعدم استخدامه.

ومع ذلك، أفضل استخدام متجه في C ++ نظرا لأنه على مستوى أعلى من التجريد، وبالتالي يجعل الرمز يسهل الكتابة.

السبب الوحيد المحتمل الذي يمكنني التفكير فيه لاستخدام RealLoc (أكثر من المتجهات) لسيناريو من نوع الصفيف، هو السرعة الخام. هو - هي مايو يكون أسرع. وأؤكد كلمة "مايو" - التدبير، لا تخمن!

ومع ذلك، يجب عليك التعامل مع RealLocations الخاص بك، وهو أكثر عمل. أنا أفضل رمز يدير أبطأ قليلا (على افتراض أنه لا يزال يعمل بسرعة كافية، بالطبع)، إذا كان بإمكاني تسليمه والحصول على أسرع.

واحدة من الفوائد الرئيسية لنظام السوق الأمراض المنقولة بالتنمية الجنسية (STD) هي أنه عندما ينمو نفسها داخليا من النمو بشكل طبيعي، فاختار حجم أكبر من الحجم الحالي (عادة - ولكن دائما مضاعف ثابت). هذا يعني أن push_back's قد أطفو (1) تكلفة.

سوف تعطيك RealLoc التحكم الأكثر دقة في كيفية تخصيص الذاكرة، ولكن مع قوة كبيرة تأتي مسؤولية كبيرة. إذا كنت تفعل كل ما تفعله هو ما يعادل push_back، وأنت realloc في كل مرة تقوم فيها بإضافة عنصر، وهذا هو يحتمل عملية O (ن) على كل إضافة إلى الصفيف.

أعتقد أنه فقط متجه فقط.

أنا لم أر أي شخص يقترح استخدام RealLoc في C ++.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top