STL امكانات هائلة .. ولكن مهجورة,

bashmohandes كتب:

هذا أيضاً لا يعني أن الdefault هو by value لأنه ببساطة لا يوجد شئ اسمه default في مبادئ اللغة بمعنى أن اللغة تدعم كل من الpass by ref و الpass by value و لكل منها طريقته في الsyntax و على المبرمج اختيار ما يناسبه ...

و يمكتك أيضاً أن تقوم بعمل implement للinterface IClonable و تستخدم object.MemberWiseColne لعمل نسخة طبق الأصل من الobject و لكن في النهاية احتجت أن تكتب بعض الكود بنفسك لعمل هذا.. أما ال++C فيمكنها عمل هذا مباشرة باستخدام الCopy Constructor دون كتابة المزيد من الأكواد

في النهاية المشكلة ليست في اللغة بل المشكلة في هل استخدمتها بطريقة صحيحة أم لا

المشكلة ان الـ C++‎ لا تساعدك كثيرا على استخدامها بالشكل "الصحيح".

quote name='Sultan_Althibity' date='Jul 19 2006, 11:54 AM'

post='516588']

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

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

أكثر من مبادئ البرمجـة الشيئيـة ... إذا كنت هكذا فالسي هي البديل الأفضل لأنها أسرع من السي بلس بلس بمراحل

أخوي سلطان يوجد حل وسط بين البرمجة الشيئية والإهتمام على المميزات المقدمة مع إهمال الأداء وبين إستعمال السي وإهمال OOP ومميزاته

وهو الإعتماد على البرمجة الشيئية مع الإبعاد قدر الإمكان عن الvirtual بحيث لا يتأثر الأداء فقط لا غير ;)

اقتباس

هـو ثلاثة أنواع تعدد الأوجـه ؛ تعدد أوجـه الدالات ، تعدد أوجـه العـملياتoperator مثل + و - و < ، تعدد أوجـه الكائنـات وهـو الأفضل

الله يفتح عليك :D

b.m.s كتب:

أخوي سلطان يوجد حل وسط بين البرمجة الشيئية والإهتمام على المميزات المقدمة مع إهمال الأداء وبين إستعمال السي وإهمال OOP ومميزاته

وهو الإعتماد على البرمجة الشيئية مع الإبعاد قدر الإمكان عن الvirtual بحيث لا يتأثر الأداء فقط لا غير ;)

الله يفتح عليك :D

هذا مثال آخر لمشاكل السي بلص بلص و حلولها الغير عملية.

الحل هذا اللذي تفضلت بوصفه بالحل الوسط هو في الحقيقة حل تعجيزي.

هناك حل افضل منه, و هو مطبق في لغة D, و هو ببساطة ان يقوم الكومبايلر بتفحس جميع الـ classes و يرى ما هي الـ methods اللتي تحتاج ان تكون virtual, يعني يشوف هل هناك كلاس مشتق من هذا الكلاس يقوم بعمل override ام لا؟

اما الحل في السي بلص بلص .. فهو تعجيزي, لانه يطالب المبرمج ان يقوم بنفسه بتقرير فيما اذا كنت بحاجة الى جعل الـ method ان يكون virtual او لا.

فإذا نسيت وضع virtual في مكان تحتاجه, فإن البرنامج لن يعمل بالشكل اللذي تتوقعه.

و اذا وضعت virtual في مكان غير مناسب, فإنك ستتسبب في بطئ في البرنامج لا داعي له.

لذلك كثير من المبرمجين يعتمدون مبدأ: خليه دائما virtual للاحتياط

و لا يقومون بالتدقيق الا اذا كانوا يريدون اقصى درجات الـ optimization, و لكن هذا غباء من اللغة, لان هذه الـ optimization يستطيع الكومبايلر ان يقوم بها بشكل آلي و بلمح البصر .. بينما يستغرق المبرمج ربما ساعات في تضبيطها لوحده بشكل يدوي

لذلك فلغة D لا تحتوي على كلمة virtual بالرغم من انها موجهة نحو الانظمة و انتاج برامج عالية الأداء

http://www.digitalmars.com/d/function.html

All non-static non-private member functions are virtual. This may sound inefficient, but since the D compiler knows all of the class hierarchy when generating code, all functions that are not overridden can be optimized to be non-virtual. In fact, since C++ programmers tend to "when in doubt, make it virtual", the D way of "make it virtual unless we can prove it can be made non-virtual" results on average much more direct function calls. It also results in fewer bugs caused by not declaring a function virtual that gets overridden.

وضع virtual أو عدم وضعها ليست قضية ففي الjava جميع الmethods تعتبر virtual اذا لم تقرر العكس و تكتب قبلها final أما في الdotnet فيجب أن تضع قبل الmethod كلمة virtual بنفسك

هذه وجهات نظر مختلفة و لا تؤثر في سرعة البرنامج في شئ فبمجرد ترجمة البرنامج لم يعد هناك virtual أو غير virtual

اقتباس

هذا مثال آخر لمشاكل السي بلص بلص و حلولها الغير عملية.

أخوي حسان لازم تعرف إن فلسفة ++C هي إنه ما تريده يجب أن تقوم به لا تلزمك على شئ مثلاٌ Garbage Collection لو فتحت المشاريع الكبيرة المكتوبة بالــ++C مثل firefox وغيرها تلقى إنه موجود فيها GC

وقوي كمان فكل شركة لها GC خاص بها وأيضاً خذ مثال C-style cast دائما الكتب تحذر منه حتى صاحب ++C يحذر منه وينصح بالإستغناء عنه ومع ذلك لم يمنعه في اللغة بل كمان تلقاه موجود في STL فهذه هي فلسفة ++C

اقتباس

الحل هذا اللذي تفضلت بوصفه بالحل الوسط هو في الحقيقة حل تعجيزي.

هناك حل افضل منه, و هو مطبق في لغة D, و هو ببساطة ان يقوم الكومبايلر بتفحس جميع الـ classes و يرى ما هي الـ methods اللتي تحتاج ان تكون virtual, يعني يشوف هل هناك كلاس مشتق من هذا الكلاس يقوم بعمل override ام لا؟

هذا هو الحل اللي ما له حل !!!! يعني الحين لو أنا أبرمج بلغة D وما أبي أستخدم الvirtual ما أقدر مجبور عليها !!!! يعني غصب الشغلة !!!!!!!!!!!

وكمان هل يكفي هذا للحكم أن هذه الدالة virtual من خلال overridden !!!! طيب ليه ما يكمل ويشوف الكود بتاعي هل أنا احتاج للvirtual !!! طبعاً مستحيل إذا "when in doubt, make it virtual" تنطبق على Compiler فإنه أول ما شافة الـــmethod صلحت لها overridden قام عملها virtual وما شاف إستخدامها هل تحتاج إلى virtual أو لأ .

اقتباس

و اذا وضعت virtual في مكان غير مناسب, فإنك ستتسبب في بطئ في البرنامج لا داعي له.

وكمان نفس الكلام ينطبق على الCompiler

اقتباس

لذلك فلغة D لا تحتوي على كلمة virtual بالرغم من انها موجهة نحو الانظمة و انتاج برامج عالية الأداء

إذا كانت D كل الدوال اللي مصلح لها overridden تعتبر virtual تنتج برامج عالية الأداء إذاً ما حال الـــSTL

والــ ++C بدونها ...

عموما أنا لا أريد أن أجعل من virtual قضية لكن مشكلة الربط المتأخر أنه يحرمك من كثير من optimization لأنه ببساطه لا يعلم الكمبايلر ماهي الدالة التي سوف تستدعى لذلك تعتبر functor في STL أسرع من الfunction العادية كمان حتى اللي في لغة الC

السلام عليكم

أنا لست خبيرا في ++c ، بس ماشي الحال

بالنسبة لي فأنا من أنصار الـ ++c و برأيي أن stl تحقق أداء جيدا و لكنني لست مطلعا على كيفية تصميم أو برمجة هذه المكتبة لذلك أضم صوتي إلى الصوت المنادي (كيف تعدد أشكال بدون virtual و ذلك باستخدام الـ templates) ؟

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

غيرت رأيي :D

بعد مراجعـة للقوالب وتعدد الأوجـه وجدت أن كلام b.m.s صادق فيما يخص أن تعدد الأوجـه polymorphism يمكن أن يحدث في وقت الترجمـة.

يوجد نوعـان من الـ polymorphism :

1- Dynamic Polymorphism: وهـو المعروف الذي نعرفـه.

2- Static Polymorphism: وهـو ما يكون فيه القوالب .

في النوع الثاني فإن تعدد الأوجـه يحدث بين كلاسات ليست من شجرة واحدة بل متفرقـة غير مرتبطـة ببعضها البعض والقاسم الوحيد المشترك بينها هـو اشتراكها في نفس مسميات الواجهـة .. فمثلاً إذا كان لدينا كلاسات: Rectangle و Line و Circle غير متوارثـة عـن بعضها إلا أنها بالتأكيد تمتلك دالة اسمها draw فإنه من الممكن استعـمال هذا النوع من تعدد الأوجـه معها.

أنظر إلى هذا المثال:

void myDraw (GeoObj const& obj)   // GeoObj is abstract base class 
{ 
	obj.draw(); 
}

وهـو يستعـمل النوع الأول ، ولكن أنظر إلى المثال التالي الذي يستعـمل النوع الثاني:

template <typename GeoObj> 
void myDraw (GeoObj const& obj)   // GeoObj is template parameter 
{ 
	obj.draw(); 
}

الفرق الوحيد بين الدالتين myDraw في المثالين السابقيـن ، هـو الـ GeoObj والتي كانت في المثال الأول base class وفي المثال الثاني فإنها template parameter ... وهذا هـو جوهر الـ Polymorphism : القدرة على أن يكون لواجهـة وحيدة عدة معالجات في نفس الوقت بغض النظر عـن الطريقة المستعـملة..

بالتالي فالآن الـ STL أصبحت راضي عـنها لأنها ترضي أطماعي التي كنت أريدها .. وهي فوائد تعدد الأوجـه :D

طبعـاً هذا الكلام بغض النظر عـن عيوبها -التي من الممكن تجاهلها- شكل الكـود السيء ، بطأ الترجمـة المعيب ، الأخطاء الكثيرة.

الأمثلة من كتاب C++ Templates: The Complete Guide .

اقتباس

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

ممكن توضح الفكرة أكتر ....... ؟؟؟

اقتباس

ممكن توضح الفكرة أكتر ....... ؟؟؟

آسف على التأخير الطويل أخي The Tornado ؛سأشرح تعدد الأوجـه Polymorphism بشكل مبسط ومقتضب للغاية.

تعريف تعدد الأوجه: هـو أن يكون للواجهـة الوحيدة القدرة على أن تقوم بأكثر من طريقة معالجـة. ومن الممكن أن نقسم تعدد الأوجـه إلى ثلاثة أقسام:

- تعدد أوجه الدوال: وهـو ما يطلق عليه التحميل الزائد.

- تعدد أوجه العـمليات: وهـو ما يطلق عليه التحميل الزائد للعـمليات مثل + و << وغيره.

- تعدد أوجه الفئات: وهـو الموضوع الأساسي لهذا المقال.

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

مثال مفيد:

سنتعامل هـنا مع أحد الأمثلة البسيطة والذي سيزودك بالكثير من الفهـم لهذه الميزة ، أنظر إلى هذا الكـود

class CLASS
{
public:
	void Put(ostream& s)
	{  s << " I am a class" << endl; }
};

هذا المثال بسيط للغاية جداً ، ويقوم الكلاس CLASS بإضافة دالة Put تقوم بكتابة الجملة I am a class ... دعـنا الآن نتعرف على فوائد تعدد الأوجـه ، لنفرض أنك في أحد برامجك استخدمت هذا الكلاس ، وكنت دائماً وكثيراً ما تكتب هذا السطر:

Object.Put (cout);

وهذا الأمر لا يقوم سوى بالطباعـة على الشاشـة ، ثم في أحد الأيام اكتشفت أنك تريد تطويراً آخر حيث أنك تريد توسيع الكلاس CLASS لتصبح الدالة Put قادرة على الطباعة على الملفات ، لحل هذه المشكلة فقد تقوم بزيادة تحميل الدالة Put ولكن ماذا لو كانت الدالة Put كبيرة الحجم نوعاً ما ، وماذا أيضاً لو كان الكلاس الذي يتعامل مع الملفات وهو ofstream ليست له نفس واجهـة الأب ostream ... لا يعتبر زيادة تحميل الدالة Put حلاً مثالياً لأنك في هذه الحالة تدخلت في مهـمـة صانع الكلاسات وبدلاً من أن تركز جهدك على استخدام الكلاسات فإنك ستركز أكثر على التفاصيل ، لحل هذه المشكلة فإن كل ما عليك هـو كتابة السطرين هذين:

ofstream K("Polymorphism.txt");
object.Put(K);

لاحظ أنك في هذا الحل لم تغير من الكلاس CLASS أي كـود ، هذه هي إحدى أكبر فوائد تعدد الأوجـه .... مهما قمت بالتطوير فإنك لن تحتاج إلى تغيير ما بداخل الكـود CLASS ، لنفرض أنك قررت أن تقوم الدالة Put بدلاً من الطباعة على الشاشة أن تطبع على لوحـة قنبلة نووية العبارة I am a class (هذا المثال اعتباطي) ، فإنك ستقوم بإنشاء كلاس جديد اسمه nuclearstream وستزوده بتعريف للعـملية << حتى تكون قادرة على التعامل مع الجهاز النووي .

في المثال السابق ، لاحظ في الدالة Put أن الكائن s من النوع ostream له أكثر من وجـه ، فمرة يكون قادراً على التعامل مع الشاشة ومرة يكون قادراً على التعامل مع الملفات ومرة يكون قادراً على التعامل مع الطابعة أو حتى مع سلاح نووي أو أي شيء آخر ، وبالتالي فإن الدالة Put ستقوم باستدعاء العـملية << وستترك كيفية تنفيذها لنوع الكائن.

هذا مثال مبسط للغاية حول فائدة تعدد الأوجـه وهـو يفيد للبدء في هذا الموضوع.

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