إلى STL أو !STL، هذا هو السؤال [مغلق]

Question

مما لا شك فيه أنني سأختار استخدام STL لمعظم مشاريع برمجة C++.لكن السؤال الذي طُرح عليّ مؤخرًا هو: "هل هناك أي حالات لن تستخدم فيها المحكمة الخاصة بلبنان؟"...

كلما فكرت في الأمر أكثر، أدركت أنه ربما ينبغي أن تكون هناك حالات أختار فيها عدم استخدام المحكمة الخاصة بلبنان...على سبيل المثال، مشروع كبير جدًا وطويل الأمد من المتوقع أن تستمر قاعدة شفرته لسنوات...ربما يستحق حل الحاوية المخصصة الذي يناسب احتياجات المشاريع بدقة التكلفة الأولية؟ما رأيك، هل هناك أي حالات تختار فيها عدم المحكمة الخاصة بلبنان؟

Answer 1

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

ويمكنك أيضا اختيار عدم استخدام STL في قضية معينة لحاويات أكثر قابلية للتطبيق موجودة والتي ليست في مستوى الحالي، مثل دفعة :: مجموعة أو تعزيز :: unordered_map.

Answer 2

الأسباب الرئيسية لعدم استخدام STL هي:

1. تطبيق C++ الخاص بك قديم ويتمتع بدعم سيئ للقوالب.
2. لا يمكنك استخدام تخصيص الذاكرة الديناميكية.

كلاهما متطلبات غير شائعة جدًا في الممارسة العملية.

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

Answer 3

هناك العديد من المزايا لاستخدام stl.بالنسبة لمشروع طويل الأجل، تفوق الفوائد التكاليف.

1. قدرة المبرمجين الجدد على فهم الحاويات من اليوم الأول مما يمنحهم مزيدًا من الوقت لتعلم الكود الآخر في المشروع.(بافتراض أنهم يعرفون بالفعل STL مثل أي مبرمج C++ مختص)
2. إن إصلاح الأخطاء في الحاويات أمر مرهق ويضيع الوقت الذي يمكن إنفاقه في تحسين منطق العمل.
3. على الأرجح أنك لن تكتبها كما يتم تنفيذ المحكمة الخاصة بلبنان على أي حال.

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

وترقيمها لسيمبيان.

وSTLPort لا تدعم سيمبيان 9، وبالتالي فإن القضية ضد استخدام STL أضعف مما كان عليه أن يكون ( "أنه غير متوفر" هو حالة مقنعة جدا)، ولكن STL لا يزال غريبا على كافة المكتبات سيمبيان، لذلك قد تكون أكثر مشكلة من مجرد فعل الأشياء بالطريقة سيمبيان.

وبطبيعة الحال فإنه يمكن القول على هذه الأسس أن الترميز لسيمبيان ليست "لC ++ برمجة المشاريع".

Answer 8

ومعظم المشاريع التي عملت على كان مصدر برنامج الطريق أقدم من أي إصدار صالحة للاستعمال حقا من STL - ولذلك اخترنا ألا ندخله الآن

Answer 9

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

Answer 10

مقدمة:

STL هي مكتبة رائعة ومفيدة في كثير من الحالات، لكنها بالتأكيد لا تحل جميع المواقف.إن الإجابة على STL أو !STL تشبه الإجابة على سؤال "هل تلبي STL احتياجاتك أم لا؟"

إيجابيات المحكمة الخاصة بلبنان

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

كونترا المحكمة الخاصة بلبنان

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

الجوانب التالية ليست سوى أمثلة قليلة، ولكنها في الأساس نتيجة لهذه الحقيقة:STL هي مكتبة حقيقية ذات حدود.

• الاستثناءات:تتابع STL الاستثناءات، لذلك إذا لم تتمكن لأي سبب من الأسباب من قبول الاستثناءات (على سبيل المثال.السلامة الحرجة)، لا يمكنك استخدام STL.يمين!قد يتم تعطيل الاستثناءات، لكن هذا لا يحل تصميم ترحيل STL عليها وسيؤدي في النهاية إلى حدوث عطل.

• الحاجة إلى بنية بيانات محددة (غير مدرجة بعد):رسم بياني، شجرة، الخ.

• القيود الخاصة للتعقيد:قد تكتشف أن حاوية STL للأغراض العامة ليست هي الأمثل لرمز الاختناق الخاص بك.

• اعتبارات التزامن:إما أنك تحتاج إلى التزامن ولا توفر STL ما تحتاجه (على سبيل المثال.لا يمكن (بسهولة) استخدام قفل القارئ والكاتب بسبب ثنائي الاتجاه [] operator).يمكنك إما تصميم حاوية تستفيد من الخيوط المتعددة للوصول/البحث/الإدراج/أي شيء أسرع بكثير.

• يجب أن تناسب STL احتياجاتك، ولكن العكس صحيح أيضًا:تحتاج إلى تلبية احتياجات STL.لا تحاول استخدام std::vector في وحدة تحكم دقيقة مضمنة مع 1K من ذاكرة الوصول العشوائي غير المُدارة.

• التوافق مع المكتبات الأخرى:ربما لأسباب تاريخية، لا تقبل المكتبات التي تستخدمها STL (على سبيل المثال.تستخدم QtWidgets بشكل مكثف قائمة QList الخاصة بها).قد لا يكون تحويل الحاويات في كلا الاتجاهين هو الحل الأفضل.

---

تنفيذ الحاوية الخاصة بك

بعد قراءة ذلك، يمكن أن تفكر:"حسنًا، أنا متأكد من أنني قد أفعل شيئًا أفضل لحالتي المحددة مما تفعله المحكمة الخاصة بلبنان." انتظر!

يصبح تنفيذ الحاوية الخاصة بك بشكل صحيح مهمة ضخمة بسرعة كبيرة:لا يقتصر الأمر على تنفيذ شيء ناجح فحسب، بل قد يتعين عليك:

• قم بتوثيقها بعمق، بما في ذلك القيود وتعقيد الخوارزمية وما إلى ذلك.
• توقع الأخطاء وحلها
• الاحتياجات الإضافية الواردة:كما تعلمون، هذه الوظيفة مفقودة، وهذا التحويل بين الأنواع، وما إلى ذلك.
• بعد فترة من الوقت، قد ترغب في إعادة البناء وتغيير جميع التبعيات (بعد فوات الأوان؟)
• ....

من المؤكد أن الكود المستخدم بعمق في الكود مثل الحاوية هو شيء يستغرق وقتًا للتنفيذ، ويجب أن يتم تنفيذه بعناية.

---

باستخدام مكتبة الطرف الثالث

"ليس STL" لا يعني بالضرورة العرف.هناك الكثير من المكتبات الجيدة على شبكة الإنترنت، حتى أن بعضها يتمتع بترخيص مفتوح المصدر مسموح به.

يعد إضافة أو عدم إضافة مكتبة تابعة لجهة خارجية موضوعًا آخر، ولكنه يستحق النظر فيه.

Answer 11

ولقد وجدت مشاكل في استخدام STL في التعليمات البرمجية متعددة الخيوط. حتى لو كنت لا تشارك كائنات STL عبر المواضيع، العديد من تطبيقات استخدام بنيات آمنة غير موضوع (مثل ++ كمرجع عد بدلا من أسلوب زيادة متشابكة، أو وجود موزعي غير موضوع الآمن).

في كل من هذه الحالات، ما زلت اختارت لاستخدام STL وإصلاح المشاكل (هناك ما يكفي من السنانير للحصول على ما تريد).

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

Answer 12

والقضية الرئيسية رأيت هو الحاجة إلى دمج مع رمز القديمة التي تعتمد على عامل عدم رمي جديدة.

Answer 13

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

Answer 14

وستاندرد C ++ معاكس يسمح تطبيقات لبعض عمليات مكرر لرمي الاستثناءات . هذا الاحتمال يمكن أن يكون مشكلة في بعض الحالات. وبالتالي قد تنفيذ حاوية بسيطة الخاصة التي يتم ضمان عدم رمي استثناءات لعمليات حرجة.

Answer 15

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

وهذه يمكن تصنيفها بشكل معقول إلى ثلاث فئات رئيسية:

1) كفاءة ضعيف

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

واستخدام الذاكرة المتهورة وسوء يسيران جنبا إلى الأداء في متناول اليد، وذلك لأن تناول الذاكرة على ذاكرة التخزين المؤقت من قبل وحدة المعالجة المركزية في خطوط 64 بايت، وإذا كنت لا تستخدم محلة إشارة لصالحك، كنت النفايات دورات و KB الثمين من الذاكرة المؤقتة.

وعلى سبيل المثال، الأمراض المنقولة جنسيا :: قائمة تتطلب 24 بايت لكل عنصر بدلا من الأمثل 4.

https://lemire.me/blog/2016/09/15/the-memory-usage-of-stl-containers-can-be-surprising/

وهذا لأنه يتم تنفيذه من قبل التعبئة اثنين مؤشرات 64 بت (1)، int و 4 بايت من الحشو الذاكرة، بدلا من القيام بأي شيء أساسية مثل تخصيص كميات صغيرة من الذاكرة القريبة وحدة تتبع العناصر التي هي قيد الاستخدام، أو استخدام تقنية مؤشر XOR لتخزين كل من التكرار الاتجاهات في مؤشر واحد.

https://en.wikipedia.org/wiki/XOR_linked_list

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

2) القيود / الزاحف المعايير

وبطبيعة الحال، في بعض الأحيان المشكلة هي أن كنت بحاجة الى بعض وظيفة مشتركة تماما أو فئة حاوية مختلفة قليلا أن يكون فقط لم تنفذ في STL، مثل decrease_min () في طابور الأولوية.

ومن الممارسات الشائعة هو لثم إلى التفاف حاوية في فئة وتنفيذ وظائف في عداد المفقودين نفسك مع دولة إضافية خارجة عن الحاوية و / أو المكالمات متعددة لطرق الحاويات، والتي قد تحاكي السلوك المرغوب فيه، ولكن مع أداء بكثير انخفاض وO () تعقد أعلى من التنفيذ الحقيقي للبنية البيانات، لأن هناك أي وسيلة لتوسيع نطاق الأعمال الداخلية للحاوية. بدلا من ذلك كنت في نهاية المطاف يهرس حتى اثنين أو أكثر مختلفة حاويات معا لأنك في نفس الوقت تحتاج اثنين أو أكثر من الأمور التي تتعارض جوهريا في أي واحد نظرا حاوية STL، مثل كومة minmax، وTRIE (منذ تحتاج إلى أن تكون قادرة على استخدام مؤشرات الملحد )، وما إلى ذلك.

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

و3) التزامن / التوازي

وحاويات STL ليست ذات ألوان أو أقل من ذلك بكثير المتزامنة. في العصر الحاضر من وحدات المعالجة المركزية المستهلك 16 موضوع، فإنه من المستغرب أن يذهب إلى التقصير تنفيذ حاوية للغة الحديثة لا يزال يتطلب منك أن تكتب كائنات المزامنة حول كل الوصول إلى الذاكرة مثل انها 1996. وهذا هو، على أي برنامج مواز غير تافهة، نوع من صفقة كبيرة، لأن وجود الحواجز الذاكرة القوات المواضيع تسلسل تنفيذها، وإذا كانت هذه يحدث مع تكرار نفس مكالمة STL، يمكنك قبلتك الموازي وداعا الأداء.

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