بعد عمل أكثر من أربع مشاريع باستخدام مكتبة boost أصبحت من مشجعي استخدام هذه المكتبة خصوصاً (ومكتبات std عموماً) في جميع
المشاريع حيثما كان ذلك مناسباً. ربما حتى في برمجة الألعاب 😒
أكثر ما أعجبني في هذه المكتبة الـ functors والاستخدام الذكي والحذر لميزات اللغة (C++) وبالخصوص الـ templates  و الـ operator overloading لتنفيذ مزايا كنت أعتبرها مستحيلة في C++ كتمرير مؤشر لإجراء عضو في class ما!
ببساطة مذ استخدمت boost أصبحت برامجي سلسة وبسيطة وسريعة الفهم وبالتالي أصبحت أستطيع التركيز على ما يجب أن يركز عليه المبرمج: خوارزميات ومنطق برامجه. 😄
ما رأيكم؟ هل أستخدم هذه المكتبة أحد في هذه الشبكة؟ وما رأيكم باستخدامها في البرامج التي تتطلب سرعة عالية كالألعاب؟

-


لم أستخدمها كثيرا ( مجرد تجارب ) .. لكن أمضيت سنة في التفكير بها :-) .. هناك مزايا وهناك أمور لم أستوعبها من تجارب بسيطة ..
قبل ثلاث أيام فقط .. أعدت النظر فأعجبني فيها أحد أجزاء المشروع Serialization ..
http://www.boost.org/doc/libs/release/libs/serialization/
وسأحاول استخدامه في بعض المشاريع .. في حال نجحت في التعديل وازالة بعض الامور .. هل استخدمه أحد ... سبق أن شرح لي الاخ وسام عن طرق تنفيذ الـserialization .. ولكن هذه المكتبة يبدو أنها مكتملة..

- هناك مميزات أخرى .. مثلا مكتبة graph كأحد أجزاء المشروع , و Regular expression .. و I/O

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




أي أجزاء المكتبة تقصد .. هناك أجزاء كثيرة .. نريد أن نركز على الشيء الذي استخدمته أخي .. حتى تكون برامجنا أسهل أيضا .. 😏


String and text processing
Containers
Iterators
Algorithms
Function Objects and higher-order programming
.
.

هل هذا التعديل والإضافة على المكتبة؟ لا أدري لماذا تود القيام بهذا لكني لا أعتقد أن هناك ما يدعو لأي تعديل على مكتبات boost. أتمنى أن تشاركني أفكارك في هذا الموضوع.


نعم هذه أحد أهم النقاط السلبية لـ boost (و C++ بشكل عام) . تعقيدها الكبير وعدم وضوح رسائل الخطأ التي تظهر. إلا أنك ستتعلم أن تعتاد هذه الرسائل بعد بناء قليل من المشاريع باستخدامها وستجد الرسائل منطقية ويمكن فهمها لا بل تفاديها أيضاً.
أذكر هنا أن هناك جهود حثيثة وملموسة في بعض الأحيان لتحسين رسائل الخطأ التي تظهر.

استخدمت الأجزاء التالية:
- boost::operators: لتنفيذ جميع العمليات الحسابية المتعلقة ببعضها بكتابة عملية واحدة منها فقط مما يقلل نسبة الخطأ ويقلل النسخ واللصق (كتنفيذ عملية مقارنة المساواة (==) باستخدام عملية المقارنة  (<))
- boost::lambda و boost::bind: من الأجزاء التي استخدمها بشكل مكثف لتبسيط برامجي وجعلها مقروءة ومركزة. حيث تختصر الكثير من التعريفات المؤقتة التي تقرضها طبيعة الـ functors.
- boost::shared_ptr: أيضاً من الأجزاء التي استخدمها بكثرة. مذ بدأت باستخدامها لم أكتب تعليمة delete واحدة ولم ينتج في برامجي أي memory leak. كل هذا وبدون أي تأثير يذكر على الأداء بالمقارنة مع الـ Garbage Collectors. بصراحة لا أدري لم لا يستخدمها الكثير هي و std::auto_ptr
- boost::asio: أستخدم هذه المكتبة في مشروعي الحالي لتسهيل عمليات الكتابة والقراءة من الـ sockets بشكل تزامني أو غير تزامني.

استخدم أجزاء أخرى أيضاً إلا أن هذه المكتبات هي أول ما يخطر ببالي عندما أتحدث عن تسهيل وتنظيم برامجي. كما أنني أستخدم الـ STL containers والجميل في boost أنها تتعامل معها بشكل سلس ودونما عناء لا بل تسهل كثيراً من عملياتها مثل BOOST_FOREACH

لاأقصد التعديل على طريقة serialization إنما مجرّد اعادة كتابة stream بأنواعها الثلاث
حيث أنّ لدى مطوّري المكتبة بعد النظر الكافي ليتوقعوا مايريده الشمّري , ☺

اقتباس من الموقع :



جواب السؤال لماذا أريد اعادة كتابة كلاسات القراءة والكتابة ؟

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

هذا ما تتيحه المكتبة ولكن يبدو أننا أمام مهمة شاقة .. لا أرى abstract classes انما templates معقدة ..
http://www.boost.org/doc/libs/1_38_0/boost/archive/text_oarchive.hpp



ألقيت نظرة عليها .. رائعة بصراحة .. هناك أمور لاتخطر على البال وعملوها مثل operators , لكن بالنسبة للـboost::shared_ptr , أعتقد أن أغلب المطوّرين لايستخدموه .. لانهم لايثقون بعمله , مثلا , متى يقوم بازالة الكائن من الذاكرة , يقولون بعد نهائية المجال scope , هل هذا ما نريده دائما !
عموما , لا أستطيع أن أتكلّم كثيرا عن المؤشرات الذكية , لأني لم استخدمها كثيرا هي الاخرى , ولكن مما ذكرته أخي , فأنت تشجعنا على استخدامها.

- بالمناسبة , قرأت أنه في لغة السي بلس القادمة c++ 0x , سيضمّون بعض من أجزاء boots إلى المكتبة القياسية مثل Regular expression و hash ..

- وهذا موقع  وجدته بعد قراءة موضوعك , يشرح كل جزء من المكتبة بمثال , أحببت طريقته في الشرح , سأضعه هنا حتى لايضيع :-) , وبالمرّة نتعلّم اللغة الكورية ...
http://www.kmonos.net/alang/boost/classes

بدأت بإستخدام boost مؤخراً، سمعت عنها الكثير فيما مضى، واعتقد إنها تستحق سمعتها الجيدة، الأجزاء التي إستخدمها حتى الآن:
- boost.smart_ptr: للتخلص من إدارة الذاكرة اليدوية.
- boost.intrusive: توفر containers و algorithms شبيهه بـ STL, استخدمها لمهام محددة, عادة بسبب فرق الأداء الذي تقدمه في حالات خاصة مقارنة بعناصر مكتبة STL, على سبيل المثال حالياً استخدمها لبناء Render Queue للمشاهد وترتيب عناصره بالشكل الصحيح بسرعة.
- boost.unordered: استخدم unordered_map بدل hash_map.
- boost.signals: إدارة وصلات signal/slot (استخدمها بكثرة)
- boost.random: عدد من خوارزميات توليد الاعداد العشوائية تعطي توزيع افضل من إجراء rand.
 
مجموعة بسيطة فعلاً 😒 .
 
أفكر في إستخدام المكتبات التالية ايضاً:
- boost.interprocess و/أو boost.MPI
- boost.bind
 
أكثر ما احبه بخصوص Boost هو الوثائق الرائعة التي تصاحب كل مكتبة وهي فعلاً شيء اساسي، جميعنا يعرف كم من الصعب فهم الأكواد المكتوبة بالكامل بواسطة حيل الـ templates. 😏
 
اما بالنسبة للأداء، أعتقد إنها مناسبة للتطبيقات عالية السرعة بل تتفوق على البدائل المتاحة، وعادةً ما اقوم بعمل بإختبارات للسرعة على أي جزء أشك في أداءه.
مثلاً: unordered_map أسرع من  stdext::hash_map. (في العمليات الثلاثة الرئيسية: البحث, الإضافة, والحذف)

على العكس. أجمل مافي boost::shared_ptr هو أنها تقوم بتحرير الذاكرة عندما تريد منها ذلك بالضبط ☺ (عندما لا يؤشر أي متغير لموقع الذاكرة المحجوزة. أي عندما تصبح الذاكرة يتيمة (orphan memroy)). وتقوم بذلك باستخدام المبدأ البسيط للـ reference counting لكن الجميل بالأمر هو أنك لن تحس بهذا الـ counter أبداً. أي أنه ليس هناك AddRef و Release كما هو الحال في الـ COM Objects 😄 .
أنا بالفعل أشجع الجميع على استخدامها. لكن أنصح بألا تتكون لدينا أفكار مسبقة عن الموضوع. وألا نتشبث برأينا لمجرد أن "الطريقة اليدوية هي الطريقة التي تعودت عليها". لن نعلم أبداً ما نضيع على أنفسنا إن اتبعنا أسلوب التفكير هذا ☺ .

أنا معك في هذه النفطة. حيث أن boost تضع سلاسة واجهاتها البرمجية بالنسبة لمن يريد تخصيصها في أسفل أولياتها بعد قائمة طويلة منها سهولة الاستخدام للمستخدم النهائي و (وهذه الألعن) كون المكتبة متداخلة بشكل وثيق مع بعضها ومع مكتبة STL كل هذا بالإضافة لكونها cross-platform 😖 .

نعم هذا صحيح. إن لم تخني الذاكرة فإن shared_ptr و bind من المكتبات التي ستضم لـ C++ 0x أيضاً 😒 .
وهي موجودة حالياً في جميع إصدارات Visual C++ 2008 تحت الـ namespace المسماة std::tr1


بصراحة هذه نفطة مهمة. لا أفهم لم يقوم البعض بكتابة containers خاصة بهم بدعوى أن مكتبات مثل STL و boost لا تحقق المطلوب من سرعة أو سهولة أو أو أو 😒 ...
برأيي إن استخدام مكتبات جاهزة مثل STL و boost سيسهل الأمر كثيراً على المستخدمين حيث لن يكونو مضطرين لتعلم خصوصيات كل مكتبة أو محرك وسيتمكنون من ربط أكثر من مكتبة وأكثر من جزء من برامجهم مع بعضها دون الحاجة لكتابة محولات لتحول من صيغة لأخرى فيضيع الأداء المزعوم الذي كسبوه 😳 .
أما بالنسبة للزيادة في السرعة فإنها (أغلب الأحيان) زيادة بسيطة (وأحياناً معدومة) لا تساوي الجهد الذي يصحبها 😲 . هناك طبعاً موضوع إدارة الذاكرة على أجهزة خاصة وهو أمر ضروري لا تراعيه المكتبات المذكورة إلا أنه يمكن تزويد هذه المكتبات بـ allocator يدعم هذه الإدارة دون الحاجة لإعادة اختراع كامل السيارة ☺ .

أؤيد عبد اللطيف جداً في ذلك. بالنسبة لمحرك ألعاب يعتمد على مصادر قد يتم استخدامها من قبل عدة أشياء، فإن الـ shared_ptr لا غنى عنه. مثلاً لديك إكساء يـُستخدم من قـِـبَـل 4 أجسام في مرحلة. وخرجت من المرحلة إلى مرحلة أخرى، حيث بقي فيها جسمان فقط يستخدمون هذا الإكساء، فإن الإكساء في هذه الحالة لن يتحرر لأن عدّاد الاستخدام قيمته 2. وعندما يتم إزالة هذه الأجسام فإن الإكساء سيتحرر تلقائياً وتصبح ذاكرته متاحة للغير.
 




احم 😳

جميل .. reference counting أراه مستخدم كثيرا في المحركات , مثل irrlicht و COM عموما , حيث يوجد كلاس IUnknown  على ما أذكر ( تغيّر اسمه الان ) ترث منه جميع الكلاسات .. ولكن لم أكن أتصوّر الفائدة منه إلا الان ..
 إذا باستخدامنا للـ shared_ptr , لا حاجة لعمل نظام للـ reference  counting .. بأنفسنا ..

شيء رائع , شكرا لكم ..