أنواع C ++ القائمة الموحدة والافتراضية constructible

Question

والسبب هو أن منشئ المعلمة واحد من std::list<T> يتطلب T أن يكون نوع الافتراضي constructible؟ وأعني بذلك التعليمات البرمجية التالية لا ترجمة.

struct Foo { // does not have default constructor.
  Foo (int i) {} 
}
int main(void) {
  std::list<Foo> l(10);
}

ويبدو من الممكن استخدام بناء وتدمير التعابير كما ما قاموا به بالفعل في الأمراض المنقولة جنسيا :: ناقلات، ولكن مع مزيد من حفظ كتاب الطبقة القائمة.

وعلى صعيد ذات صلة، لماذا لا يكون وظيفة القدرات في القائمة؟ قد يزعم البعض أن هذه الوظيفة من شأنه أن يدفع تكلفة الذاكرة تخصيص مقدما والقضاء على النفقات العامة في وقت لاحق كما كنت push_back الكائنات. على الأقل سيجعل واجهات حاويتين تسلسل STL قليلا أكثر اتساقا.

Answer 1

والأمراض المنقولة جنسيا :: قائمة لايوجد وظيفة القدرة لأنه لا معنى له. فإنه لا يوجد لتغيير مثل ناقلات لا. انها قدرة محدودة فقط من قبل الذاكرة المتوفرة، والتي لا يتم تحديدها بسهولة.

ومن ما طلبت، وأعتقد أن كنت فعلا تريد احتياطي (). هذا هو لمرة واحدة للناقلات لأنه (سيء) يحتاج شيء من هذا القبيل. ليس هناك شرط معين لجعل جميع وظائف متناسقة عبر كافة الحاويات STL، وخاصة عندما جعل معنى للآخرين.

ويمكنك تحقيق نفس التأثير باستخدام مخصص مخصص. كما اقترح مانويل، والنظر في زيادة.

Answer 2

وليس هناك شرط عام على أن يكون نوع constructible الافتراضي - يجب أن يكون copyable وتنازل. لا تعمل التعليمات البرمجية بسبب محاولة إنشاء قائمة من 10 مادة - لديهم ليتم بناؤها بطريقة أو بأخرى وهكذا يجب استخدام منشئ افتراضي - ولكن فقط في هذه الحالة المحددة. إذا قمت بإنشاء قائمة فارغة وإضافة إلى ذلك، لن يكون هناك أي شرط من هذا القبيل.

والشيء نفسه ينطبق على غيرها من الحاويات - محاولة تجميع ما يلي:

#include <vector>

struct A {
    A( int x ) : z(x) {}
    int z;
};

std::vector <A> a(10);

وفيما يتعلق بالجزء الثاني من سؤالك، أريد فقط أن نلاحظ أن التناسق واجهة وليس معايير التصميم الرئيسي للحاويات القياسية - ليس هناك نية، على سبيل المثال، أن نوع واحد من الحاوية هو "قطرة في "بديلا لآخر. هناك مناقشة جيدة من هذا في البندين 1 و 2 من كتاب سكوت مايرز "STL الفعال".

Answer 3

نيل أجبت على السؤال الرئيسي .

ونلاحظ أيضا أن كنت في حاجة الى منشئ افتراضي عند الاتصال تغيير ().

ويمكنك التحايل على ذلك من خلال وجود قائمة STL من المؤشرات إلى كائنات ولكن أعتقد أن هذا كان بالفعل واضحا لك.

<اقتباس فقرة>   

وعلى صعيد ذات صلة، لماذا لا يكون ل   وظيفة القدرات في القائمة؟ تستطيع   يجادل بأن هذه الوظيفة من شأنه أن يدفع   ذاكرة تكلفة تخصيص مقدما و   القضاء على النفقات العامة في وقت لاحق كما كنت   كائنات push_back. على الأقل سوف   جعل واجهات اثنين STL   تسلسل حاويات أكثر قليلا   متسقة.

وأعتقد أن المشكلة هنا هي أن قوائم STL تسمح عبر قائمة الربط . إذا كنت ترغب في تخصيص ذاكرة مقدما، إلقاء نظرة على في زيادة بركة مخصص .

Answer 4

والسبب هو أنه عند إنشاء قائمة من العناصر ن (حيث n هو المعلمة التي تستخدم في البناء)، وقائمة تملأ هيكلها من العناصر ن بنسخ من T ().

SGI وثائق المحكمة الخاصة بلبنان لائحة .

Answer 5

<اقتباس فقرة>   

لماذا هو أن معلمة واحدة   منشئ الأمراض المنقولة جنسيا :: قائمة تتطلب T   أن يكون نوع الافتراضي constructible؟

ولأن هذه دالة البناء - القائمة مع عناصر (الرقم الذي قمت بتمرير كمعلمة) يخلق. وقيمة كل عنصر يكون الافتراضي. ويمكن أيضا استخدام منشئ مع معلمتين، لإنشاء قائمة مع العناصر التي سيتم تهيئة مع قيمة العنصر الثاني.

<اقتباس فقرة>   

وعلى صعيد ذات صلة، لماذا لا يكون ل   وظيفة القدرات في القائمة؟

وانها لا تملك المعنى، لأن تكلفة إضافة عناصر جديدة إلى القائمة قليلا بكثير مما كانت عليه في الحال مع النواقل.

<اقتباس فقرة>   

والأمراض المنقولة جنسيا :: ناقلات لا يكون مثل هذا   تقييد. سؤالي هو لماذا لا   استخدام نفس الأساليب   (خلق / تدمير التعابير) في   الأمراض المنقولة جنسيا :: قائمة كذلك؟

وليس من قيود. لأنه إذا كنت لا تستخدم هذا البناء، وليس مطلوبا مهيئ الافتراضية. نفس الشيء ينطبق على ناقلات.

Answer 6

وهكذا سؤالك هو حقا "لماذا لا يكون احتياطي والقدرة وظائف في القائمة؟"

والجواب على ذلك هو أنه لا يوجد سبب لحجز الذاكرة مقدما لائحة - إضافة عناصر جديدة لم يتطلب realloc ونسخ لعناصر القائمة، وليس هناك شرط أن الذاكرة عقد محتويات قائمة تكون متجاورة، والمكررات لا تحصل يبطل عند القيام list::push_back().

كل أولئك هم السبب في وجود vector<>::reserve()، وبعد أن الذاكرة في احتياطي عناصر جديدة هو السبب في vector<> سوف تؤدي new وضع في الذاكرة الخام.