ما هو أكثر المفاهيم غموضاً حول ++c برأيك ؟!

هلا أخوي خالد

الحمد لله لا يوجد شئ غامض لدي بالنسبة للغة ال++C , أتذكر أني كنت أتتبع كود الأسمبلي حتى أفهم آلية ال Virtual method , والله كانت أيام ... :lol:

لكن

اقتباس

ما نريده هو رأيك فيما ينقص اللغة أو فيما لو أزيل من اللغة لكان أفضل!

أرى أنه يجب أن تبتعد لغة ++C عن لغة ال C ... من ناحية دعمها لsyntaxis الثانية ... فاللغة الآن تتوسع لتدعم مميزات اللغات الجديدة لكن مع المحافظة على المميزات القديمة , وهذا يساعد في عملية ال compatiblity لكنه وهنا المشكلة الأكبر أنه يجعل اللغة كبيرة كبيرة جداً -_-

هذا ما لدي فقط ...

اكره جدا ال OOP Syntax

وعليكم السلام .

اقتباس

أو حتى لماذا لا يوجد شيء معين في اللغة أو لماذا يوجد ذلك الشيء!

- أتمنى حذف بعض الامور الثانوية ( التي لاداعي لها ) , مثل تبسيط عملية تمرير البارمترات .. لو تكون مثل لغة السي شارب by value و by reference بأسلوب واحد وموحد ... الان .. نعمل كذا :

void func(int x);//1
void func(int*x);//2
void func(int&x);//3
void func(const int a);//4
void func(const int *a);//5
void func(const int &a);//6

// الاختصار
void newFunc(int x); // يعتبرها المترجم مثل الحالة رقم 6
void newFunc(int &x);

,هكذا مع return value .

أيضاً .. مع طرق الوراثة مالها داعي

class B:protected A
class B:private A

- عدد من الكلمات المحجوزة مالها داعي .. مثل register ( على ما أذكر ) .. الخ.

- التوافقية مع لغة السي ومكتباتها , لاداعي له (كما قال الاخ بندر ) .. ( هو فقط للمحافظة على الزبائن ) , من يريد تعلّم السي فليتعلّمها بشكل مستقل عن السي بلس .

- OOP ليس ببساطة وجمال الجافا ( لايوجد interface , انما يجب أن تقوم بنفسك بوضع كل الدوال abstract , ولاتضع constructor وتكون الدوال public ... بينما الجافا .. تقوم بذلك بكلمة واحدة هي interface ) , الوراثة المتعددة يمكن الاستغناء عنها .

-نريد تضمين Boost بشكل كامل , ونريد تحديث سريع للغة وليس بعد سنين طويلة .

بس :D

العديد من الأمور تصيبني بصداع في سي++

آخرها كانت رسالة الخطأ unresolved external symbol ... hooker.lib

تأكدت أن الدالة معرفة جيدة و أضفت ال .h الموجودة في مشروع ثاني و تأكدت من مسار المكتبة .lib، و جربت و جربت عدة طرق حتى مللة، أغلقت الفيزوال ستوديو ثم فتحته مجددا فإخفت رسالة الخطء :blink:

يبدو أني إكتشفت ثغرة في الفيزوال ستوديو :lol:

اقتباس

ماهو أكثر الأمور التي واجهتها في ++C و لم تدخل عقلك لا بالطول و لا بالعرض,

كثيرة و أغلبها كرهتها حتى نسيت إسمها أهمها التحويل بين الأنواع

أرى أن تطوير برمجيات MFC و WIN32 أفضل طريقة لإحتراف السي++

السلام عليكم ...

أهلاً أخي بندر :)

اقتباس

أرى أنه يجب أن تبتعد لغة ++C عن لغة ال C ... من ناحية دعمها لsyntaxis الثانية ... فاللغة الآن تتوسع لتدعم مميزات اللغات الجديدة لكن مع المحافظة على المميزات القديمة , وهذا يساعد في عملية ال compatiblity لكنه وهنا المشكلة الأكبر أنه يجعل اللغة كبيرة كبيرة جداً

هذا الموضوع بالفعل كبير جداً, أقصد أنه تم نقاشه من قبل كبار مبرمجي ++C مراراً و تكراراً.

حسب ما فهمته من قرار Stroustrup باستخدام C كقاعدة و البناء فوقها, لسببين رئيسيين.

الأول, هو أن اللغة أصلاً مجربة, لكن C وقتها حسبما أعرف (عام 79) لم تكن بالشهرة التي اكتسبتها في الثمانينيات و لكنها بالفعل كانت مستخدمة على نطاق واسع و يقول أن أي لغة جديدة كانت ستجلب معها ميزات و سلبيات,

و السلبيات ستكون أكثر, لأن المبرمجين سيضطرون للاعتياد عليها أولاً, و من ثم لابد من تعديل جوانب اللغة جذرياً بعد تجربتها, لذلك قرر أن تكون C كقاعدة لأنها لغة صحيحة التصميم من الأساس حسب قوله,

السبب الآخر, هو الاستفادة من المكتبات المكتوبة بـ C مباشرة, و ربما هذا هو السبب الحقيقي بالمناسبة لانتشار ++C, لأنه لاتوجد حاجة لكتابة كل شيء من جديد, و بالفعل نجح نجاحاً باهراً في هذا الأمر :)

و لكن Stroustrup قال بأن هذا الأمر عائق حقيقي في تطور ++C, و يقصد بذلك التوافقية مع C... هناك مغالطات في فهم العلاقة بين C و بين ++C,

البعض يعتقد أن C (الحالية) هي أصل ++C, و في الحقيقة أن هذا عار عن الصحة تماماً, ++C الحالية و C الحالية هما أخوة لا أكثر, ++C ورثت ما يسمى K&R C أو C الأصلية, التي تم اختراعها في الستينات,

بينما C الحالية ورثت من ++C الكثير, و أشهر مثال, هو أن C الحالية بشكل أو بآخر strong type language, و هذا ما كانت ++C الرائدة فيه,

فمثلاً, في C الأصلية يمكنك فعل التالي ::

void fun(int x)
{
	// do something with x!
}
.
.
float x = 5.0;
fun(x);

و لكن x عند تمريرها للدالة لن يتم تحويلها لـ int, أي أن x سترسل على حالها بنفس الـ bit-representation تماماً, و هذا يعني أن C الأصلية كانت weakly typed language.

بينما حالياً نأخذها دون تفكير أن المتغير سيتم تحويله تلقائياً و سيقوم المترجم بإدراج بعض الكود للتحويل بين النوعين, و هذا ما قامت به ++C منذ البداية, ببساطة C أخذت هذا المفهوم من ++C,

بالطبع هذه التوافقية لن تستمر كثيراً, فمثلاً في cpp0x تم استبدال معنى auto, أصبحت auto تستخدم في عملية الـ type inference من العبارات لتحديد نوع المتغيرات,

و هذه إحدى أفضل الميزات التي تم إضافتها لـ cpp0x برأيي, فمثلاً,

auto complexNumber = 5 + 3i;

سيصبح بإمكانك كتابة هذا الشيء في cpp0x بسهولة, auto تحدد نوعية المتغير و في حالتنا complex و 3i تسمى user-defined literals....

عموماً تم استحداث auto للتخلص من عناء كتابة الكثير من السطور لا أكثر و لكنها فعالة جداً حسب تجربتي خصوصاً عند التعامل مع الـ iterators و إن كنت لاتحب تعريفات الـ templates الطويلة, و لمن يحب تجربتها فهي موجودة في ++g النسخة الرابعة,

برأيي أن C99 هي من بدأت بالقضاء على التوافقية و ليس ++C, لذلك لا أعتقد أن هناك أهمية كبيرة بعد الآن لهذه التوافقية بشكل كبير بعد تطور ++C بهذا الشكل...

عموماً, تبقى ميزات هذه التوافقية كبيرة جداً, يمكنك استخدام gmp مباشرة في ++C بينما في باقي اللغات لابد من عمل wrapping و هكذا,

هي نعمة كبيرة و نقمة كبير في نفس الوقت,

أفدنا إن كان لديك تعليق حول الموضوع, هل ميزات هذه التوافقية أكثر من مضارها أم العكس ؟

تحياتي ...

السلام عليكم....

أهلاً أخي ASDen :)

اقتباس

اكره جدا ال OOP Syntax

معك حق, و ليس فقط syntax الـ oop بل اللغة بشكل عام ليست جميلة من ناحية الكود نفسه, و بالتأكيد مادام أنك ترى أكواد python فلن تستسيغ أكود ++C :)

و لكن دعني أقول لك شيئاً, ++C أبسط من Java و أبسط من #C من ناحية OOP و في نفس الوقت لديها إمكانيات أكبر و معقدة بمسافات ضوئية أكثر منهم :)

كيف يمكن أن نجمع بين هذين الأمرين ؟

حسناً معقدة أتفق معك في ذلك و لا تحتاج إلى أن تقرأ ما قاله أحد الخبراء حول OOP في ++C :

و لكن, بصراحة مطلقة OOP ليست من أولويات ++C, ربما كانت موضة في السبعينيات, في الثمانينيات, في التسعينيات و لكنها الآن حالها كحال الـ procedural programming لديها نواقص في جوهر المفهوم نفسه, و ليس في كيفية تطبيقه في اللغات مهما كانت اللغة,

السبب الذي يؤدي بالكثير إلى الضياع في ++C هو التفكير من خلال Smalltalk في لغة تعاكس مفهوم Smalltalk في البرمجة الكائنية, Java و #C هما الوريثتان الشرعيتان لـ Smalltalk بالإضافة إلى بنت أبيها Ruby :)

دائماً ما تفكر في ++C من خلال الوراثة و تعدد الأشكال حصراً, بينما في ++C هما أداتان يمكن أن تستعملها أو تتركها و في الغالب ليس هناك حاجة لهما, الخطأ هو الاعتقاد أن الـ classes في ++C أنشئت لهذا الغرض فقط :huh:

عراب ++C في البرمجة الكائنية هي Simula, في Smalltalk كل شيء عبارة عن كائن, بينما في Simula أنت من تقوم بإنشاء الـ classes كـ Abstract Data Types لا أقل و لا أكثر,

و إن بدأت التفكير بهذه الطريقة في ++C سترى الكثير من الأناقة في اللغة, فكر في الـ classes على أنها أنواع جديدة, على أنها أنواع مثلها مثل int أو double أو أي نوع أصلي في اللغة,

و لديك إمكانية محاكاة أي نوع, هذه هي طريقة Simula.... الـ OOP تعني الوراثة و تعدد الأشكال المبنية على الـ ADT. لذلك "إن احتجت" للوراثة و تعدد الأشكال, فلديك الأدوات اللازمة,

التعقيد الناشئ ليس من الوراثة و تعدد الأشكال في ++C, و لكنه من التفكير من خلال Smalltalk OOP في ++C.

لست ألقي محاضرة في OOP :lol: و لكن هناك إساءة استخدام رهيبة أراها من حولي لهذا المفهوم, كل من أراه يريد أن يكون تصميم برنامجه Pure OOP, و إن ظهر أن التصميم سيء يقال أنك لم تصممه بطريقة كائنية حقيقية!

المكان الوحيد لترى فيه الوراثة و تعدد الأشكال في ++C هي مكتبة الـ iostream, الباقي "كله" عبارة عن ADTs,

من أول مكتبة ++C لآخرها لا ترى الوراثة مستخدمة إلا في عدة زاويا, البعض يعتقد من النظرة الأولى أن هذا ضعف, و لكن برأيي أنه يرى من خلال نظارات Smalltalk :)

دعني أعطيك مثالاً على معنى جمال OOP في ++C أو لنقل الـ classes ....

typedef ttmath::Int<128> bigint; // 512-bit number. 128 * 4(word_size)

bigint n = 1258;

if(n % 2 == 0)
	std::cout << "even number";
else
	std::cout << "odd number";

التفكير في أن الفئات لابد أن تكون قابلة للوراثة و أن الوصول يتم عن طريق مؤشر, و أنه لابد من فتح الطريق في المستقبل لوراثة هذه الفئة, أمر غير منطقي في ++C, لأن bigint هو عبارة عن bigint لا أكثر و لا أقل,

و لا معنى أصلاً لوراثته, و هذا حال فئات المكتبة القياسية من بدايتها لنهايتها, لايمكنك وراثة string ولا vector و لا map و لا shared_ptr في boost.... ماذا يمكن أن يرث من string ؟

هذا مالدي و إن شاء الله يكون هناك المزيد من النقاش حول النقطة, لتعريف نقاط قوة ++C و نقاط ضعفها في هذا الموضوع لاحقاً, هذا الموضوع من أكثر المواضيع التي أريد التطرق لها :)

تحياتي ...

برأيي الشخصي ان الc++ لم تترك مجالا الا وطرقته ..

وغيرت امورا كثيره في عالم البرمجة . وهذا لا يختلف عليه اثنين ..

ولكن بالنسبة لدراستي السي++ صراحة لم اواجه مشاكل ولكن فقط قليلا بالمؤشرات في بدايتها .. لانها شئ معقد قليلا في اوله ..

اما في ما بعد .. اصبح الامر اسهل والحمدلله ..

ولكن انا دائما اسال ..

هل الطرق البرمجية المعقدة التي يتبعها المبرمجون بالسي ++ .. من الممكن ان نحلها بطرق اسهل .؟

يعني مثلا هناك اشياء اجدها في كودات صراحة اسمعها لاول مره .. مع العلم انني مع اللغه منذ 6 او5 سنين ..

اكره المسائل التاليه بكود السي .. وهي عندما نتطرق الى

_if def

فصراحة دائما ما اسال نفسي .. لماذا هي موجودة ..

وكذلك بالنسبة لاستخدام 0x00000..

فهذه اكرهها جدا .. مع العلم ان اغلب الكودات تحتاج اليها .. لكنني ارى انها مزعجه قليلا .. صح ؟؟ ام هي عندي فقط ..

------------------

شوف الصدفة .. قبل ان انتهي من الكتابة وجدتها في توقيعك يا خالد ..

-------------------------------

من ناحية اللغه .. اللغه كبيرة .. واتساعها وتطويراتها تزيد يوما بعد يوم . واجد من باب انها شئ جيد وقوي ولكن مزعج من جانب اخر.. لاننا حرنا صراحة . هل ندرس ونستعمل QT .. ام ندرس MFC .. ام نستعمل .. او هذه .... ..

وهذه الامور جعلت منها لغة اكبر مما موضوع لها في وقتها والسبب سهولة تعاملها مع الاجزاء ..

@ MSDen ..

اقتباس

اكره جدا ال OOP Syntax

بالعكس .. ارى انه من اجمل ما فيها هي OOP ..

قبل اكثر من سنة .. بقيت ليومين اقرأ بمسالة غابت عن عقول الكثيرين .. فكرت فيها وجربتها وبالفعل تفكيري بمحله ..

وهي مسالة حجم الصنف الفارغ او مايسمى Empty Class .. بقيت لايام ابحث عن سبب المشكله .. قرات حل بياران نفسه وقرات مواضيع الى ان احسست انني شبعت من الموضوع .. وبعد ايام قمت بوضعه كلغز ليستفيد منه الاخرين ..

الامور التي اخاف منها في السي هي الvector وال templet ..

تحياتي العطرة ..

اقتباس

دائماً ما تفكر في ++C من خلال الوراثة و تعدد الأشكال حصراً, بينما في ++C هما أداتان يمكن أن تستعملها أو تتركها و في الغالب ليس هناك حاجة لهما, الخطأ هو الاعتقاد أن الـ classes في ++C أنشئت لهذا الغرض فقط

احسنت ياخالد ..

هذا هو ما معروف عن الoop ...

عندما تجد اي شرح للoop تجد ان من الاولويات هي الوراثة .. ولكن انا برايي هناك امور اهم بكثير .. واجمل ..

فقد تعاملت كثيرا مع الoverloading .. ورايت انها اسهل واجمل شئ بالoop .. احس انني اقوم باضافات للغه ..

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

اقتباس

اكره جدا ال OOP Syntax

صراحة هو السبب الأساسي الذي لم اتعلم ال C++ بسببه حتى الآن!!

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

class B:protected A
class B:private A

يالشمري , أي شيء إلا الوراثة , المعاملات private , protected جميلة جدا وتعطي مرونة للأجيال التالية وليس للجيل الوارث الأول فقط , يعني مثلا الفئة A الأب , ترث منها مباشرة الفئة B وترث من B فئة أخيرة C , أي أن C هي حفيد A .

الآن بعض المتغيرات في A لاأريد ظهورها في C وإنما أريدها أن تظهر في B فقط , بالتالي أجعل نوع الوراثة private حيث ستنزل المتغيرات وتورث ل B كأنها private variables , وبالتالي لو كانت الوراثة من B إلى C من النوع Public فلن تظهر أيضا :)

 

[color= #0000ff;]class A

[color= #000000;]{

[color= #0000ff;]protected[color= #000000;]:

[color= #0000ff;]int private_variable;

[color= #000000;]};

 

[color= #0000ff;]class B[color= #000000;]: [color= #0000ff;]private A [color= #007f00;]// private_variable will appear for class B members

[color= #000000;]{

[color= #0000ff;]public[color= #000000;]:

[color= #0000ff;]int q,w,e;

[color= #000000;]};

 

[color= #0000ff;]class C[color= #000000;]: [color= #0000ff;]public B [color= #007f00;]// private_variable will not appear for class C members

[color= #000000;]{

[color= #0000ff;]public[color= #000000;]:

[color= #0000ff;]int r,t,y;

[color= #000000;]};

في رأيي C++ هي الكمال بعينه , ولاأحب لغات OOP الكاملة كما الجافا والسي# , ومن الأفضل أن تحصل على أكبر قدر من المرونة لتخرج من المآزق البرمجية بدون تغيير الهيكيلية بشكل كامل في أي لحظة , لم أجرب أكواد البايثون لكن يستحيل أن تكون فيها مرونة OOP في سي++ .

السلام عليكم ....

شكراً لأخي هيثم على الإضافة القيمة, سأضيف من عندي قليلاً :)

أولاً الشمري :D

بالنسبة للأنواع في ++C فهناك المتغيرات العادية و المؤشرات و المراجع, عن نفسي لا أستخدم المؤشرات مباشرة, و إنما فقط داخل الكائنات, و غالباً ما استخدم الـ smart pointers من boost...

بالنسبة للمراجع أتمنى أن تريني كيف تقوم بكتابة swap في Java :happy: بالطبع للكائنات سهلة, و لكن أريد أن أرى swap للـ primitves :P

بالنسبة للثوابت, فعلى العكس, أرى أنها self documentation للكود, بدلاً من ذكر ذلك في التوثيقات لديك المترجم لإخبارك بحصول أي انتهاك :)

هل تسمع عن Teach Yourself Programming in Ten Years

يقول أن أحد أفضل المبرمجين الذين قابلهم في حياته خريج ثانوية :)

و انظر ماذا يقول خريج الثانوية هذا حول Java التي أزعجتنا بها :P

بالنسبة للوراثة الـ private و الـ protected فلا أدري مالصعوبة فيهم...

الوراثة التي نتكلم عنها دائماً في ++C تسمى public inheritance.. فمثلاً لو كان derived يرث base فإن derived is base صحيح ؟

حسناً في الوراثة الـ private و الـ protected الأمر ليس كذلك, الصنف المشتق ليس من نوع الصنف الأب!

ماهذا بدأنا التخريف صحيح ؟

الأمر بسيط جداً,

في حبيبتك Java ألا تقوم بكتابة Helper methods و هذه الدوال تكون private ؟

حسناً, مارأيك بأن ++C تحقق أهداف OOP و Java لا تحققها في هذا المجال بالتحديد!

تصور أننا نقوم ببناء Queue, و نريد أن نحدد ما هي الـ low level data structure لهذا الطابور الذي نقوم ببنائه.

في Java سنقوم بتعريف ArrayList على سبيل المثال داخل الصنف Queue ثم سنقوم باستخدامه, بكل بساطة Composition. في ++C يمكنك استخدام الـ private inheritance لتقوم بنفس العمل,

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

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

template <class T>
class Queue : private std::vector<T>
{
	void add(const T& value)
	{
		push_back(value);
	}
};

لنا عودة مع OOP من جديد, و لكن بعد مدة :)

اقتباس

-نريد تضمين Boost بشكل كامل , ونريد تحديث سريع للغة وليس بعد سنين طويلة .

أتفق معك في هذا, و لكن على الأقل أضمن أن ما كتبته قبل عشر سنوات مازال يعمل دون أدنى مشكلة, بدلاً من تحديث اللغة في فترات متقاربة,

Stroustrup حينما سئل, قال أنا لست من النوع الذي يغير شيئاً من الـ syntax لأن ذوق بعض الناس لا يلائمه,

عندما سأضيف شيئاً, سأضيفه لكي يضيف major impact على الطريقة التي يتبعها المبرمجون :)

لذلك ترى أن OOP بعدها الـ Exceptions بعدها الـ Templates بعدها الـ Metaprogramming,

قفزات كبيرة نسبياً, و مع cpp0x قفزة كبرى بصراحة و ليست قصيرة :)

تحياتي ...

السلام عليكم ...

اقتباس

آخرها كانت رسالة الخطأ unresolved external symbol ... hooker.lib

أعتقد أننا بدأنا نرى العيوب الحقيقية في ++C مع رد أخي بن العيد بصراحة :)

أحد أكثر الأمور التي تجعلني أبكي في ++C و C هي نظام المكتبات, أو ما يسمى في لغات أخرى packages أو assemblies....

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

لم أكن أفهم حتى وقت قريب القوانين الأساسية لكيفية ربط عدة قطع منفصلة من الكود مع بعضها البعض, السبب طبعاً C, و نظام الـ modules الغريب فيها و الذي اتبعته ++C لأجل التوافقية,

في المرفقات نظام packages مقترح منذ زمن, و لكن لن يتم تطبيقه في cpp0x و لكن بكل تأكيد هناك نظام جديد بعد عدة سنوات من الآن,

بالمناسبة فقط, أعجبني نظام Java في موضوع الـ packages و كيفية عمل import لأي مكتبة بسهولة بالغة :)

تحياتي ...

cpp_packages.pdf

السلام عليكم ...

اقتباس

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

حسناً, لا أعرف حتى الآن كيفية كتابة مؤشرات الدوال, أفهم ماهي و لكن لم أستخدمها إلا في عدة أمثلة منذ تعلمتها فقط.

في ++C هناك شيء اسمه functor, يسمى في لغات أخرى closure .... أبسط و أجمل و أسرع ببساطة هكذا.

خذ مثلاً دالة للقيام بعملية التكامل المحدد كتبتها الآن, و قل لي هل تستطيع فهم الـ functor من خلال هذا المثال ؟

و لحساب التكامل المحدد لأي functor لديك قم بعمل التالي لا غير :)

يمكنك إضافة functors جديدة إلى الكود دون المساس بدالة التكامل على الإطلاق, و من ثم تمرير الـ functors المطلوبة إلى integrate حسب الرغبة,

بالطبع مع إضافة الـ lambda expressions سيصبح بإمكاننا كتابة الدوال الصغيرة مباشرة مكان استدعاء الدالة نفسها (الـ functor) :

أرى أن طريقة ++C أنظف, و فوق كل هذا يقوم المترجم بعملية inlining للمعامل () و بذلك تلغي عملية الـ indirection في حالة مؤشرات الدوال و يصبح كودك أسرع بلاشك :)

تحياتي ...

اقتباس

class B:protected A

class B:private A

اهه ..لم أعرف فائدتها من قبل .. شكراً أخي هيثم + خالد . رأيتها غير موجودة في الجافا .. ولم أضطر لاستخدامها فظننت أنها غير مفيدة :D

بالمناسبة .. أؤيّد ماقاله الاخ بن العيد عن مسألة تحويل الأنواع في لغة السي - السي بلس .. لازلت أتذكّر كثيراً من المعاناة أيام Win32 API .

لكن أظن أنّه بعد Boost زالت كثير من البلاوي :D .

السلام عليكم ...

أخت رغد :

اقتباس

هل يا ترى يستطيعوا تطوير المراجع عـ الأقل لتصبح كافية و مغنية عن المؤشرات تماماً

تكون المؤشرات موجودة و لكن بيعملوا استقلالية للغة ++C عـ الأقل بهالخصوص؟

لا يمكنك تطوير المراجع لاستبدال المؤشرات :)

المؤشرات هي الحالة العامة, و المراجع هي حالة خاصة. الفرق أن المراجع أكثر أماناً من المؤشرات حتى من الموجودة في Java و #C.

فمثلاً, في الـ Copy Constructor في ++C على الشكل التالي ::

C++
class Test
{
	Test(const Test& other)
	{
		// code for copying only.
	}
};

في Java :

Java
class Test
{
	public Test(Test other)
	{
		if(other != null)
		{
			// copy only if other != null.
		}
	}
}

لاحظي أنه لابد من التحقق أن Test في حالة Java من حيث كونه كائناً حقيقياً, و ليس مرجعاً فحسب, فربما كان لا يشير إلى شيء, بينما في ++C المراجع لابد من تهيئتها دائماً.

المراجع اخترعت في الأصل لحل مشكلة محددة ثم ظهر أنها طريقة متفوقة في إرسالة عناوين المتغيرات بطريقة جميلة حقيقة بدلاً من المؤشرات في ++C,

و لكن المشكلة الحقيقية التي تم حلها باستخدام المراجع هي عملية إعادة تعريف المعاملات operators overloading....

فمثلاً, دون وجود المراجع كان يجب كتابة التالي ::

std::vector<int> list(3);

*(list[0]) = 1;
*(list[1]) = 2;
*(list[2]) = *(list[0]) + *(list[1]);

و بالطبع سيء جداً جداً من ناحية الكتابة و القراءة, و لابد من أخذ البال من جميع مشاكل المؤشرات من أن المؤشر يؤشر إلى شيء حقيقي بالطبع,

بينما مع الـ references ::

std::vector<int> list(3);

list[0] = 1;
list[1] = 2;
list[2] = list[0] + list[1];

أجمل :) و لايوجد داع لأي عملية تحقق....

الفروق بين المؤشرات و المراجع بسيطة...

هذا ملخص بسيط للفروق ::

int x = 5, y = 10;
int& r = x;

1) int sum = r + y; // you do not need to say '*r' automatically dereferenced.

2) r = y; // WRONG, 'r' can only have one thing pointing at during its life, only at its infancy;)

تحياتي ..

السلام عليكم ورحمة الله وبركاتة

ارى عيب واحد فى c++ وهو عيب ليس شامل للكل ولكن البعض يقع فية

ارى ان c++ هى لغة واسعة الادوات بحيث تشمل معظم مايدور فى عالم البرمجة

ولكن هذا عيب وميزة فى نفس الوقت

العيب ان (سى++ تخدع البعض بحيث لا ياخذون الوقت الكافى لكى يتمرسوا)

فيمكنك ان تجرى بين اجزاء اللغة دون ان تلتفت ان عليك التمرس فى نقطة معينة

فمثلا هل اخذت وقتك الكافى لكى تتقن الدوال والموشرات وoop وووو ؟

ربما ولكن هناك الكثير يتسرعون ولا يتمرسون ظنا ان اللغة جزء لا يتجزء

لذلك انصح المتسرعين ان يبداو بالسى وهذا كفيل بانة يعطيك الوقت الكافى لكى تتمرس مع syntax السى وطريقة تفكير كومبيلر السى و التمرن مع الموشرات وكيفية تاثر الذاكرة بالكود وتعلم تحليل وانشاء الخوارزميات واتقان استعمال اللغة ككل ويستحسن ان تتدرب على مشروع متوسط يكون pure c لكى تاخذ خبرتك منها .

ومن ثم الانتقال الى c++ ولكن ليس انتقال ككل ولكن كتعلم oop ودمجها مع معرفتك السابقة بالسى ومن ثم التمرن على انشاء نماذج oop والتمرن عليها بالكود ايضاء

ومن ثم الانتقال الى تعلم المكتبات المتقدمة وتعلم موضوعات مثل generic و المواضيع الاخرى المتقدمة .

فهل انت متفقين معى ان السى++ لا يجب ان تاخذ كقطعة واحدة ؟البعض ينجح فى ذلك ولكن ارى البعض منهم لهم نقاط ضعف فى نقطة من النقاط السابقة وذلك بسبب التسرع وعدم اخذ الوقت الكافى لتمرسها وهناك البعض يسافرون بين اجزاء اللغة اثناء التعلم وهذا يسبب تشتتهم وهناك البعض يمل ويذهب ليتعلم لغة على حد ظنة اسهل

السلام عليكم ,,

أخ محمد :)

لغة ++C بالفعل معقدة إن لم تكن الأكثر تعقيداً على الإطلاق بالفعل, و لكن هذا لا يجعل منها لغة سيئة كما يعتقد البعض.

المشكلة الحقيقية برأيي أن هناك الكثير ممن يخلطون بين اللغة نفسها و بين الـ frameworks.... بدون framework لغة ++C لافائدة منها!

بالطبع عندما يبدأ الشخص بتعلم البرمجة ربما لن يستطيع التفريق بين المترجم و بين اللغة نفسها, دع عنك اختيار الـ framework المناسب.

اللغات الأخرى "غالباً" تأتي مع framework أساسي, لذلك عندما يقال Java يقصد اللغة و كل مايأتي مع اللغة, بينما الاعتماد على frameworks خارجية شبه معدوم خصوصاً في حالة المبتدئين.

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

إن كنت تريد البرمجة لإنتاج شيء مفيد بـ ++C فعليك تعلم framework سواء كان Qt لإنتاج تطبيقات سطح المكتب, سواء كان الـ framework الخاص بأجهزة الألعاب كـ ps3 أو wii أو غيرهما الكثير و الكثير....

هناك مشكلة كبيرة حقيقة في تدريس هذه اللغة!

الغالبية العظمى تدرس هذه اللغة على أنها C مضافاً إليها إضافات, وهذا ما أسمعه كثيراً من كثير من المبرمجين, رغم أن طريقة ++C تختلف كثيراً عن C مع وجود مفهوم واحد, هو تمكين المبرمج من الـ low level stuff always!

و لكن C تفرض عليك هذا الأسلوب بينما ++C تمكنك منه دون فرضه. يمكن أن تشاهد أكواد في ++C فيها Abstraction أعلى من جميع اللغات, و يمكنك أن ترى معاملات الـ bit جنباً إلى جنب!

عندما تحتاج إلى شيء تجده موجوداً.

البعض يعتقد أنه يجب عليه أن يستخدم المؤشرات, رغم أنه بإمكاننا كتابة برامج "كاملة" دون حتى أن ترى مؤشراً واحداً في ذلك البرنامج, و لكن إن احتجت للمؤشرات فهي موجود, استخدمها!

أخيراً, هناك نصيحة من مخترع اللغة, يقول بأن اللغة expert friendly بمعنى أن الخبراء غالباً يجدونها منطقية أكثر من المبتدئين, لأنها توفر لهم الأدوات الضرورية لبناء الأنظمة على اختلافها.

لذلك ينصح المبتدئين, (و أنا أخذت بنصيحته منذ قرأتها صراحة), أن لا تفكر في "دقائق" اللغة و "خباياها", و قم بتصميم برنامجك تصميماً صلباً, و جرب كتابته بـ ++C لتكتشف الفرق.

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

كالبرمجة الكائنية أو الـ functional أو الإجرائية, و لكن في ++C فأنت من يختار الأسلوب المناسب للقطعة المناسبة و كل هذه الأساليب تعمل مع بعضها دون مشاكل!

بالمناسبة هذا هو اسلوب python الحقيقي, و هو الأفضل برأيي.

=====================================

عند كتابتي للرد لم أرى رد الأخ the programmer 1 :)

الأساليب التي تدعمها ++C رسمياً مع الإصدارة القادمة cpp0x هي ::

البرمجة الإجرائية كـ C.

البرمجة الكائنية كـ Simula مع الـ polymorphism.

الـ metaprogramming من خلال الـ preprocessor و الـ templates.

الـ functional من لغات عديدة كـ ML و غيرها و Lisp و غيره.

مقارنة الـ templates بالـ Generics غير عادل صراحة,

لأن الـ Generics في Java و #C فائدته محدودة, فقط في الـ Containers لا أكثر على ما أعتقد لأنه أفضل من الطريقة الكائنية بلاشك, رغم ذلك يبقى الـGenerics بمثابة 1+ لهاتين اللغتين في النهاية.

الـ Templates لغة برمجة داخل ++C, حتى أبسط الأمور التي تستطيع القيام بها الـ Templates تقف الـ Generics عاجزة عنها, ربما لأن مصمم #C أراد تسهيل الأمر و معه حق نسبياً.

An Introduction to C# Generics

فمثلاً, في ++C يمكنك كتابة دالة على الشكل التالي ::

template <class T>
T addTwoVariables(const T& first, const T& second)
{
	return first + second;
}

يمكنك فعل هذا بـ Java و #C و لكن بطريقة تلغي فائدة الـ Metaprogramming بشكل كبير :)

تحياتي ...

كلام صحيح يا اخ خالد

ولكن بعد مدة من تعلم سى++ وجدت نفسى ماتعلمتة هو السى + معلومات اساسية عن oop

وعندما اقراء كتب فى السى اجدنى اعرفها بشكل جيد وباختلاف بسيط فى syntax

وكن بهذا المستوى ماذا بامكانى ان افعل فى السى++ بالطبع انك محق ان سى++ تعطى لك الحرية فلتستعمل cout او printf ولكن المشكلة هى framework

فالسى توفر لك frame work جيدة للعمل بهذا المستوى مثل gtk+ ولكن السى++ ولناخذ كيوت كمثال ستحتاج منك اكثر من ذلك من تعلم مواضيع اخرى فى oop و generic والخ

اتمنى ان يتوفر لدى الصبر حتى النهاية ولكن لماذا كل هذا التاخير قبل العمل على frame work حقيقية.

وبالطبع العمل على مشاريع حقيقية و frame work حقيقى يختلف تماما عن الاكواد الصغيرة من اجل التعلم

فهى ستعطينى خبرة التعامل مع الكومبيلر و debugger وادوات التطوير (مثل ادوات تنظيم السورس) وخبرة عملية والالتحام مع المشاريع الواقعية وايضاء خبرى سى هى جزء من خبرة سى ++ فكيف ستكتسب تلك الخبرة فى وسط كبر السى++ (بالطيع ممكن ولكنة اصعب من اكتسابة من تطوير pure c )

فلا يمكن توفير frame work للسى++ دون تطلبة للالمام بالسى++ بحد يزيد بكثير عن السى

ولايمكن استخدام السى الا عن طريق فكر السى (كلغة mid-level )

أعتقد أن مشكلة ال++C في انها ظهرت في فترة وسيطة لم تكن فيها الObject Oriented هي الاسلوب العام للبرمجة و أيضاً لم يكن الGUI أو الواجهة الرسومية هي الطريقة الأكثر انتشاراً لعمل الUI و لهذا هي في النهاية تقف في منتصف الطريق بين الprocedural programming و الObject oriented كما أنها تعتمد طريقة في الOOP غير كل اللغات الأخرى فهي تدعم الMulit class inheritance و لا تدعم مبدأ الinterface كما أنها اللغة الوحيد التي تدعم (أو ربما ابتدعت) مبدأ الfriend و هو برأيي أكبر خطأ لأنه يقضي على مبدأ الencapsulation و هو أهم مبدأ في الOOP .

الشئ الاخر هي أنها لم تعطي و لو حتى تلميح على كيفية تطوير الواجهة الرسومية و لم تعطي أيضاً أي طريقة قياسية للMulti Threading و هو بالاضافة الى ضعف الframework المصاحب لها و الذي لا يحوي سوى أساسيات الأساسيات فلا يوجد دعم للشبكات أوالتشفير أو التعامل مع الصور و الوسائط المتعددة و غيرها من المميزات و هي التي جعلت ال++C محصورة في برمجة النظم و جعلت الكود صعب التنفيذ على نظم تشغيل مختلفة.

Khaled.Alshaya كتب:

السلام عليكم ,,

أخ محمد :)

لغة ++C بالفعل معقدة إن لم تكن الأكثر تعقيداً على الإطلاق بالفعل, و لكن هذا لا يجعل منها لغة سيئة كما يعتقد البعض.

المشكلة الحقيقية برأيي أن هناك الكثير ممن يخلطون بين اللغة نفسها و بين الـ frameworks.... بدون framework لغة ++C لافائدة منها!

بالطبع عندما يبدأ الشخص بتعلم البرمجة ربما لن يستطيع التفريق بين المترجم و بين اللغة نفسها, دع عنك اختيار الـ framework المناسب.

اللغات الأخرى "غالباً" تأتي مع framework أساسي, لذلك عندما يقال Java يقصد اللغة و كل مايأتي مع اللغة, بينما الاعتماد على frameworks خارجية شبه معدوم خصوصاً في حالة المبتدئين.

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

إن كنت تريد البرمجة لإنتاج شيء مفيد بـ ++C فعليك تعلم framework سواء كان Qt لإنتاج تطبيقات سطح المكتب, سواء كان الـ framework الخاص بأجهزة الألعاب كـ ps3 أو wii أو غيرهما الكثير و الكثير....

هناك مشكلة كبيرة حقيقة في تدريس هذه اللغة!

الغالبية العظمى تدرس هذه اللغة على أنها C مضافاً إليها إضافات, وهذا ما أسمعه كثيراً من كثير من المبرمجين, رغم أن طريقة ++C تختلف كثيراً عن C مع وجود مفهوم واحد, هو تمكين المبرمج من الـ low level stuff always!

و لكن C تفرض عليك هذا الأسلوب بينما ++C تمكنك منه دون فرضه. يمكن أن تشاهد أكواد في ++C فيها Abstraction أعلى من جميع اللغات, و يمكنك أن ترى معاملات الـ bit جنباً إلى جنب!

عندما تحتاج إلى شيء تجده موجوداً.

البعض يعتقد أنه يجب عليه أن يستخدم المؤشرات, رغم أنه بإمكاننا كتابة برامج "كاملة" دون حتى أن ترى مؤشراً واحداً في ذلك البرنامج, و لكن إن احتجت للمؤشرات فهي موجود, استخدمها!

أخيراً, هناك نصيحة من مخترع اللغة, يقول بأن اللغة expert friendly بمعنى أن الخبراء غالباً يجدونها منطقية أكثر من المبتدئين, لأنها توفر لهم الأدوات الضرورية لبناء الأنظمة على اختلافها.

لذلك ينصح المبتدئين, (و أنا أخذت بنصيحته منذ قرأتها صراحة), أن لا تفكر في "دقائق" اللغة و "خباياها", و قم بتصميم برنامجك تصميماً صلباً, و جرب كتابته بـ ++C لتكتشف الفرق.

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

كالبرمجة الكائنية أو الـ functional أو الإجرائية, و لكن في ++C فأنت من يختار الأسلوب المناسب للقطعة المناسبة و كل هذه الأساليب تعمل مع بعضها دون مشاكل!

بالمناسبة هذا هو اسلوب python الحقيقي, و هو الأفضل برأيي.

=====================================

عند كتابتي للرد لم أرى رد الأخ the programmer 1 :)

الأساليب التي تدعمها ++C رسمياً مع الإصدارة القادمة cpp0x هي ::

البرمجة الإجرائية كـ C.

البرمجة الكائنية كـ Simula مع الـ polymorphism.

الـ metaprogramming من خلال الـ preprocessor و الـ templates.

الـ functional من لغات عديدة كـ ML و غيرها و Lisp و غيره.

مقارنة الـ templates بالـ Generics غير عادل صراحة,

لأن الـ Generics في Java و #C فائدته محدودة, فقط في الـ Containers لا أكثر على ما أعتقد لأنه أفضل من الطريقة الكائنية بلاشك, رغم ذلك يبقى الـGenerics بمثابة 1+ لهاتين اللغتين في النهاية.

الـ Templates لغة برمجة داخل ++C, حتى أبسط الأمور التي تستطيع القيام بها الـ Templates تقف الـ Generics عاجزة عنها, ربما لأن مصمم #C أراد تسهيل الأمر و معه حق نسبياً.

An Introduction to C# Generics

فمثلاً, في ++C يمكنك كتابة دالة على الشكل التالي ::

template <class T>
T addTwoVariables(const T& first, const T& second)
{
	return first + second;
}

يمكنك فعل هذا بـ Java و #C و لكن بطريقة تلغي فائدة الـ Metaprogramming بشكل كبير :)

تحياتي ...

هذا الكود مع أنه سيعمل الا انك لا تعرف ماذا سيحدث اذا مررت type مثل Person أو MyClass و هنا الفرق, ففي اللغات الأعلى يكون المترجم حريص على أن يكون الكود صحيحاً ليس فقط Syntactically بل أيضاً Symantically قدر المستطاع