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

اقتباس

الnamespace لا يجب أن تحوي دوال أو متغيرات, الnamespace هي مجرد تجميع للclasses هذا هو الفرق الجوهري الذي تختلف فيه كلاً من ال#C و الjava عن ال++C و الا انتهينا لنفس النقطة, المتغير أو الدالة يجب أن يتبع صنف, غير هذا يعتبر فوضى في لغة المفترض أن Object Oriented

لماذا يجب أن تكون اللغة pure oop لكي تكون جيدة!!!!!!!

هذا كلام دعايات, لا أكثر!

قلت لك في البداية أن Java و #C بدأتا تصبحان multiparadigm مع إضافة الـ Generics و إدخال مفاهيم الـ functional في #C....

OOP جيدة في حل نوع من المسائل و سيئة في البعض الآخر, و مثال الجيدة فيه هو برامج الـ GUI و الـ Simulation... و سيئة في مكتبات الـ Data Structure و الخوارزميات!

هناك لغات ليس فيها أي فكرة من أفكار OOP و تعتبر من أنجح اللغات! و اللغة الـ OOP الأنقى في التاريخ لم يستعملها أحد!

تحياتي ...

صحيح أين الكود لكيفية تمرير الcomparer للsort ؟ و الذي سيحكم عليه الجمهور؟ وضعت لك 3 طرق كمثال و انتظر ردك

اقتباس

سبق و قلت استخدام الOpen Source Libraries له تبعات قانونية و التزامات لا تقدر عليه كل الشركات و لهذا عندما تتوفر المكتبات القوية المدعومة مع اللغة توفر الكثير من الجهد و أيضاً تعطي غطاء قانوني و دعم لا توفره المكتبات الأخرى, كما أن المكتبات مفتوحة المصدر موجودة لكل اللغات, نحن هنا نقارن بين التقنيات Out of the Box

كلها تسمح لك باستخدامها في تطبيقاتك التجارية ببلاش مع حرية التعديل و إخفاء تعديلاتك إلا tiny فلم أطلع على رخصتها.

اقتباس

طبعاً جاد و المقارنة هنا ليست بين من أفضل, بل بين مكتبة موجودة و غير موجودة, و تلبي الاحتياجات و لا تلبي الاحتياجات. و لست أنا من يقارن بل الشركات و المؤسسات هي التي تقارن و تنتهي لعدم استخدام ال++C في 99% من أعمالها و تلجأ للغات أخرى, حتى الجامعات و الأكاديميات تدرس الJava بالتناظر مع ++C كما في MIT أو Stanford.

لغة Java تدرس في الجامعات لأنهم مهووسون حول OOP في الـ undergraduate و بالـ functional في الـ graduate.

أنت تخبرني بأن لغة ++C ميتة ؟

هي اللغة الرئيسية في صناعة البرمجيات يا عزيزي! أخبرني كم عدد التطبيقات الموجودة في جهازك المكتوبة بـ Net. و عدد تلك المكتوبة بـ ++C ؟

اقتباس

اذا لم تر فهذا ليس مشكلة المكتبة, و مرة اخرى أنا لا أقارن بين مكتبات مفتوحة المصدر في ++C و مكتبات الframework أنا أقول هل يوجد ما يأتي Out of the Box في أي بيئة عمل لل++C ما يلبي هذه الاحتياجات أم لا؟؟ اذا لم يكن هناك اذاً هناك نقص, لأن المكتبات مفتوحة المصدر أو حتى التجارية موجودة في أي تقنية.

لا تعليق!

اقتباس

قارن بنفسك

هل عددت الخوارزميات المطبقة ؟ معظم الأسماء التي تعتقد أنها خوارزميات هي interfaces و ليست خوارزميات مطبقة! هذا مثال من الصفحة التي وضعتها فقط... عدد الخوارزميات الموجودة في cryptoPP أكثر بكثير من عدد الـ classes و الـ interfaces الموجودة في الصفحة التي وضعتها كلها! و تأكد أنها بجودة أفضل :)

اقتباس

نعم يوجد و هذه ورقة بحث

Intel® Integrated Performance Primitives (Intel® IPP) for Windows* - Creating C# Wrappers

مكتبة مكتوبة بـ ++C و بالطبع ستستخدمها لغات أخرى كثيرة لقوتها لأنها مكتوبة بـ ++C عن طريق خبراء Intel!

اقتباس

صحيح أين الكود لكيفية تمرير الcomparer للsort ؟ و الذي سيحكم عليه الجمهور؟ وضعت لك 3 طرق كمثال و انتظر ردك

لا مشكلة أحتاج قليل من الوقت, لقضاء بعض الحاجيات ثم العودة من جديد. مع كأس من الشاي :)

اقتباس

أنت تخبرني بأن لغة ++C ميتة ؟

هي اللغة الرئيسية في صناعة البرمجيات يا عزيزي! أخبرني كم عدد التطبيقات الموجودة في جهازك المكتوبة بـ Net. و عدد تلك المكتوبة

أنا لا قول ميتة و لكن هل هي بنفس نسبة الاستخدام من 5 سنوات أو من 10 سنوات, و هل ستظل بنفس نسبة الاستخدام في ال5 سنوات القادمة؟؟

أغلب من يستخدم ال++C يستخدمها مضطراً لبرمجة برامج تحتاج لPerformance عالى مثل الألعاب أو أنظمة التشغيل, أو تعديل برامج قديمة تمت كتابتها من سنوات طويلة. لكن أي مشروع حديث لن تجد نسبة ال++C أكثر من 1%

اقتباس

Intel® Integrated Performance Primitives (Intel® IPP) for Windows* - Creating C# Wrappers

مكتبة مكتوبة بـ ++C و بالطبع ستستخدمها لغات أخرى كثيرة لقوتها لأنها مكتوبة بـ ++C عن طريق خبراء Intel!

أعلم هذا فهي لم يُعد كتابتها بال#C و لكن هذا لم يمنع استخدامها في ال#C :lol: و هنا تأتي القوة مع المرونة.

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

هذه طريقي في كتابة الذي قمت بكتابته في ++C....

الطريقة الأولى عن طريق تعريف المعامل less في الـ class نفسه..

الطريقة الثانية, عن طريق lambda في cpp0x,

الطريقة الثالثة, عن طريق comparator,

تعليق بسيط على الطريقة الثالثة,

لولا وجود friend كان أمامنا خياران,

الأول أن تكون data لا يسمح الوصول إليها private, أو أن تكون public...

إن جعلتها private لا يمكنك استخدام comparator خارجي, و إن جعلتها public عرضت الـ representation الخاص بالـ class الذي تقوم بتصميمه,

الحل في ++C أن تجعل الـ comparator صديقاً لـ myclass :)

و بهذا لا تعرض الـ representation و تحافظ على سلامة الواجهة,

و يستطيع الـ compartor الوصول للمطلوب.

الأمر الآخر, في حالة استخدام البرمجة الكائنية, فإن Compare التي كتبتها يتم استدعائها من خلال طبقتين عن طريق IComparer و من ثم الوصول للدالة الفعلية في الـ comparator الذي قمت بإنشائه... بينما الـ functor الذي قمت بكتابته ستم إدراجه في نفس كود الـ sort أي سيتم عمل inlining لدالة المقارنة كما لو أنك قمت بإعادة كتابة sort لكي يقوم بالمقارنة مباشرة .

لاحظ أن الطريقة الثانية ليست معتمدة بعد, هذه الطريقة مع cpp0x إن شاء الله :) و بالمناسبة أعجبتني #C في أنها تدعم الـ lambda ...

لا تفهم من كلامي أني أريد مقارنة "لغتين", أردت فقط إلقاء الضوء على فائدة friend من خلال أمثلة. استخدمه عند الحاجة الملحة فقط, و عندما تستخدمه بشكل صحيح فإنه يقوي الـ encapsulation و لا يضعفه.

تحياتي ...

MoHammaD_93 كتب:

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

أحيانا لن تكون الـ OOP هي الأنسب لحل المشكلة

فلماذا تريد تقييد المبرمج بالـ OOP في حين يكون هناك أسلوب أنسب لحل المشكلة؟

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

الأخ محمد قالها بالعربية one size doesn't fit all!

تحياتي أخ محمد...

اقتباس

الطريقة الأولى عن طريق تعريف المعامل less في الـ class نفسه..

يمكن عمل Operator Overload أيضاً في ال#C و لكني لا أحبذ هذه الطريقة

اقتباس

الطريقة الثانية, عن طريق lambda في cpp0x

أعتقد أن C++0x لم تصدر بعد, صححني ان كنت مخطئاً

اقتباس

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

الأسلوب التي تتخذه ++C و الذي ورثته عن C و هو عدم التقيد بوضع الدوال في أصناف هو ليس أسلوب بل هو ال(لا أسلوب) فلا هو functional programming و لا هو Pure OOP.

أعتقد أن الأسلوب التي بُنيت عليه ال#C هو أسلوب أفضل فهي تقتبس مفاهيم عدة و في نفس الوقت تُحافظ على نقطتين و هي أنها لغة OO و أيضاً Static Type و هذا لم يمنع تقديم مفاهيم مثل الLinq و الLambda expressions و الtype inference و في نفس الوقت وجود الunsafe mode و الذي يربط الحاضر بالماضي اذا كنت لاتزال في حاجة لاستخدام مؤشرات حقيقية.

و في النسخة القادمة من #C سيتم تقديم بعض مفاهيم الDynamic Dispatch لاضافة روح الdynamic languages الى اللغة. و لكن مع الحفاظ على أن اللغة في الصورة الأكبر static language

اقتباس

أعتقد أن C++0x لم تصدر بعد, صححني ان كنت مخطئاً

صحيح,

يمكنك كتابة lambda باستخدام boost, نسخة cpp0x مأخوذة من طريقة boost.... بالطبع boost مبنية فوق ++C الحالية :)

سيتم اعتمادها ضمن اللغة نفسها لتسهيل الأمور على المبرمجين, و للعلم فقط lambda موجودة في boost قبل أن تظهر في #C..

اقتباس

الأسلوب التي تتخذه ++C و الذي ورثته عن C و هو عدم التقيد بوضع الدوال في أصناف هو ليس أسلوب بل هو ال(لا أسلوب) فلا هو functional programming و لا هو Pure OOP.

أعتقد أن الأسلوب التي بُنيت عليه ال#C هو أسلوب أفضل فهي تقتبس مفاهيم عدة و في نفس الوقت تُحافظ على نقطتين و هي أنها لغة OO و أيضاً Static Type و هذا لم يمنع تقديم مفاهيم مثل الLinq و الLambda expressions و الtype inference و في نفس الوقت وجود الunsafe mode و الذي يربط الحاضر بالماضي اذا كنت لاتزال في حاجة لاستخدام مؤشرات حقيقية.

و في النسخة القادمة من #C سيتم تقديم بعض مفاهيم الDynamic Dispatch لاضافة روح الdynamic languages الى اللغة. و لكن مع الحفاظ على أن اللغة في الصورة الأكبر static language

لماذا pure OOP تعني جيد لديك ؟

هل python لغة pure ؟ أتمنى أن أسمع من مبرمجي python رأيهم حول تعدد الأساليب الذي توفره python و إن كان ذلك يعتبر "لا أسلوب" ؟

هل حرية اختيار التصميم تعتبر شيئاً سيئاً ؟

أعطيتك أكثر من مثال على أن pure OOP ليست الطريقة المثلى لحل الكثير من المشاكل! لماذا تستخدم الـ Generics جنباً إلى جنب في #C مع مفهوم البرمجة الكائنية في مكتبة الـ data structure ؟

أنت تقول بأن حل أجزاء المشكلة بأساليب متعددة هو الطريقة الخاطئة, و أن pure functional أو pure OOP هي الطريقة الصحيحة لحل جميع أجزاء مشكلة ما ؟

أنت لا تعلق على تصميم اللغة نفسه, و تخبرني ماهو العيب, كأنك تخبرني بأنك لم تستخدم اللغة أصلاً, و أنك ترى الكود بطريقة مختلفة (أسوأ؟) من الذي اعتدت عليه.

ما تقوم به في #C يمكنك فعل المثل "بالضبط" في ++C, يمكنك كتابة نفس التصميم بـ ++C من جديد دون تغيير في الأسلوب سواء كانت طريقتك pure oop أو غيرها.

العكس غير صحيح, ليس كل تصميم مكتوب بـ ++C, يمكن نقله لـ #C. بناء على التضحيات التي تقوم بها #C من أجل جعلها مناسبة أكثر لتطبيقات الانترنت و سطح المكتب, و OOP رائعة في تصميم مكتبة GUI, و لكنها سيئة في تصاميم أخرى.

انظر إلى Linq مثلاً, لغة جميلة جداً functional كبديل لكتابة SQL مباشرة مع كامل مميزات أي DSL, تصميم موفق جداً عند الحديث عن تطبيقات قواعد البيانات. يمكنك بناؤها في ++C دون تعديل اللغة. و لكن هل يمكنك إضافة DSL أخرى إلى #C داخل اللغة نفسها ؟

بالنسبة للـ static typing, أصلاً ++C هي التي أدخلت مفهوم الـ Static Typing إلى لغات الـ OOP!

objective C قررت أن تتبع smalltalk, بينما Stroustrup قرر أن تكون لغته static type منذ البداية. و لهذا ترى أن طريقة تعريف الـ class لديك ماهي إلا طريقة ++C مع إزالة الفاصلة المنقوطة آخر الـ class,

و تحدد الـ access specifier لكل دالة أو متغير, بينما في ++C تقوم بجمعهم في مجموعات, غير ذلك, أنت تستخدم ما ابتكره Stroustrup منذ ثلاثين عاماً.

كل مرة تخبرني بميزة في #C, كأنها ليست أصلاً في ++C.

اقتباس

وجود الunsafe mode و الذي يربط الحاضر بالماضي اذا كنت لاتزال في حاجة لاستخدام مؤشرات حقيقية.

مادخل الحاضر بالماضي بالمؤشرات ؟

مادام لديك هيكل معقد للبيانات في الذاكرة فستحتاج للمؤشرات, أصلاً أنت تستخدم المؤشرات دائماً في #C, و لكنها restricted pointers لا أكثر,

هي مؤشرات تم حظر بعض العمليات عليها, المؤشرات في ++C لك كامل الصلاحية عليها. و إن أردت يمكنك بناء garbage collector كالموجود في boost من خلال مكتبة و ليس فرض هذا النوع على المبرمج.

إذا كانت لديك المؤشرات الموجودة في ++C, فيمكنك بناء مؤشر كالموجود في #C و استخدامه, بينما العكس غير صحيح.

انظر إلى shared_ptr, ما يقوم به الـ shared_ptr هو ما تقوم به مؤشرات #C لا أقل و لا أكثر. و لكن مع ميزة إضافية هي أن الـ destruction يمكن تحديد وقت وقوعه بالضبط,

هذا يعني أنه يمكنك إدارة منافذ الشبكة أو التعامل مع الملفات أو الذاكرة أو أي مصدر للبيانات بنفس الطريقة. في #C أنت تحصل على إدارة مجانية للذاكرة "فقط". بالمناسبة أيضاً, python تعمل بنفس الطريقة

رغم أني لست متأكداً إن كان شرطاً في اللغة أو أن مفسراتها تتبع هذا التصميم دون شرط من اللغة نفسها.

اقتباس

و في النسخة القادمة من #C سيتم تقديم بعض مفاهيم الDynamic Dispatch لاضافة روح الdynamic languages الى اللغة. و لكن مع الحفاظ على أن اللغة في الصورة الأكبر static language

من زمان جداً الـ dynamic type موجود في ++C, مرة أخرى لا تحتاج إلى تعديل اللغة نفسها,

استخدم any من boost :)

تحياتي ...

اقتباس

سيتم اعتمادها ضمن اللغة نفسها لتسهيل الأمور على المبرمجين, و للعلم فقط lambda موجودة في boost قبل أن تظهر في #C..

الlambda في ال#C مجرد تسهيل كتابة لكن منذ صدور #C فهي تدعم الdelegates و هي مشابهة الى حد كبير للfunction pointers في ++C/C

اقتباس

لماذا pure OOP تعني جيد لديك ؟

هل python لغة pure ؟ أتمنى أن أسمع من مبرمجي python رأيهم حول تعدد الأساليب الذي توفره python و إن كان ذلك يعتبر "لا أسلوب" ؟

هل حرية اختيار التصميم تعتبر شيئاً سيئاً

الOOP يقدم طريقة لتنظيم الكود و تنظيم الأفكار أيضاً و هو الى حد كبير الاسلوب الأكثر انتشاراً لهذه الأسباب و أكثر.

بالنسبة لPython فهي في النهاية لغة scripting سرعة كتابة البرنامج تأتي على حساب سرعة تنفيذه, و انتشارها لأنها مناسبة لتقنيات الويب كما أنها لا تستخدم في تطبيقات سطح المكتب أو الخدمات التي تتطلب سرعة و قوة أكبر. و هي ليست محل مقارنة مع ++C/C أو #C أو Java و لكن من مميزات ال#C أنها تدعم استضافة Iron Python داخل برامجها بحيث يمكنك تبادل الobjects بين الكودين و هذا يصلح جداً لعمل الplugins و الaddins للبرامج الضخمة أو أيضاً لتقديم مميزات الDSL

اقتباس

أعطيتك أكثر من مثال على أن pure OOP ليست الطريقة المثلى لحل الكثير من المشاكل! لماذا تستخدم الـ Generics جنباً إلى جنب في #C مع مفهوم البرمجة الكائنية في مكتبة الـ data structure ؟

أنت تقول بأن حل أجزاء المشكلة بأساليب متعددة هو الطريقة الخاطئة, و أن pure functional أو pure OOP هي الطريقة الصحيحة لحل جميع أجزاء مشكلة ما ؟

لماذا تعتبر الGenerics مبدأ خارج الOO هذا غير صحيح, فالGenerics تتبع مبدأ الParametric Polymorphism و هو أحد مبادئ الOOP

اقتباس

انظر إلى Linq مثلاً, لغة جميلة جداً functional كبديل لكتابة SQL مباشرة مع كامل مميزات أي DSL, تصميم موفق جداً عند الحديث عن تطبيقات قواعد البيانات. يمكنك بناؤها في ++C دون تعديل اللغة. و لكن هل يمكنك إضافة DSL أخرى إلى #C داخل اللغة نفسها ؟

الLinq في النهاية مجرد مجموعة من الinterfaces و هي IQueryProvider و IQueriable و يقوم المترجم بتحويل الLinq expression الى Expression tree أثناء عملية الترجمة و يتم تنفيذ هذه الExpressions بناءً على الimplementation المقدم من الinterfaces السابقة, ما تراه في الكود مجرد Syntax Sugar و لكن هو في النهاية تصميم يتبع مبدأ الFluent Interfaces

اقتباس

بالنسبة للـ static typing, أصلاً ++C هي التي أدخلت مفهوم الـ Static Typing إلى لغات الـ OOP!

objective C قررت أن تتبع smalltalk, بينما Stroustrup قرر أن تكون لغته static type منذ البداية. و لهذا ترى أن طريقة تعريف الـ class لديك ماهي إلا طريقة ++C مع إزالة الفاصلة المنقوطة آخر الـ class,

و تحدد الـ access specifier لكل دالة أو متغير, بينما في ++C تقوم بجمعهم في مجموعات, غير ذلك, أنت تستخدم ما ابتكره Stroustrup منذ ثلاثين عاماً.

كل مرة تخبرني بميزة في #C, كأنها ليست أصلاً في ++C.

و أنا أشكر ++C و Stroustrup على هذا جداً فالstatic typing من أهم مميزات ال++C التي أثبتت نجاحها.

اقتباس

مادخل الحاضر بالماضي بالمؤشرات ؟

مادام لديك هيكل معقد للبيانات في الذاكرة فستحتاج للمؤشرات, أصلاً أنت تستخدم المؤشرات دائماً في #C, و لكنها restricted pointers لا أكثر,

هي مؤشرات تم حظر بعض العمليات عليها, المؤشرات في ++C لك كامل الصلاحية عليها. و إن أردت يمكنك بناء garbage collector كالموجود في boost من خلال مكتبة و ليس فرض هذا النوع على المبرمج.

إذا كانت لديك المؤشرات الموجودة في ++C, فيمكنك بناء مؤشر كالموجود في #C و استخدامه, بينما العكس غير صحيح.

يا أخي أنا أقصد الحاضر بالماضي بمعنى لو أن لديك مكتبة كتبتها بال++C أو C أو System API مهمة و لن تستطيع اعادة كتابتها بال#C فهذا لن يمنعك من استخدامها في #Cحتى و لو كانت هذه الAPI تستخدم C++ Pointers فيمكنك تعريف مؤشرات مثل التي توجد في ++C\C بالضبط و استخدامها و تبادلها من أكواد ال++C\C

اقتباس

الOOP يقدم طريقة لتنظيم الكود و تنظيم الأفكار أيضاً و هو الى حد كبير الاسلوب الأكثر انتشاراً لهذه الأسباب و أكثر.

صحيح و و هو أكثر الأساليب البرمجة استخداماً لفعاليته, و لكن pure OOP لا تعني "أن اللغة جيدة". مثال على ذلك smalltalk و مستخدموها المعدودون على الأصابع.

أنت في #C لا تبرمج بطريقة OOP, أنت تستخدم OOP ضمن أحد الأساليب التي تستخدمها, فمثلاً Linq تعتبر functional. الـ Generics أيضاً ليست OOP.

مالذي يجمع بين :

List<int> x = new List<int>();

و :

List<double> x = new List<double>();

المثال الأول و الثاني لا تربطهم أي علاقة على الإطلاق, سوى أن قطعة الكود الأصلية تم إعادة تصنيعها مرة للنوع double و مرة للنوع int. لايوجد أي علاقة من علاقات oop بين الإثنان,

تسمى الـ generics بالـ ad hoc polymorphism و بـ parametric polymorphism لأنها تشبه عمل الـ polymorphism في oop لا أكثر.

هذا لا يعني أن الـ polymorphism في oop سيء و الـ generics جيدة, لكل أداة استخدامها :)

و لكن هناك مشاكل برمجية يمكن حلها بالـ generics بطريقة أفضل من الـ polymorphism و العكس أيضاً صحيح, هناك مشاكل الأفضل حلها بالـ polymorphism.

اقتباس

الLinq في النهاية مجرد مجموعة من الinterfaces و هي IQueryProvider و IQueriable و يقوم المترجم بتحويل الLinq expression الى Expression tree أثناء عملية الترجمة و يتم تنفيذ هذه الExpressions بناءً على الimplementation المقدم من الinterfaces السابقة, ما تراه في الكود مجرد Syntax Sugar و لكن هو في النهاية تصميم يتبع مبدأ الFluent Interfaces

Linq أداة رائعة حقيقية, و رأيي مبني على الأمثلة التي رأيتها حتى الآن. تقديم DSL تتبع الأسلوب الـ functional يحل الكثير من المشاكل بطريقة أفضل مما لو استخدمت OOP لوحدها ,

أنت تقوم بخلط الأساليب لحل المشكلة,

اقتباس

يا أخي أنا أقصد الحاضر بالماضي بمعنى لو أن لديك مكتبة كتبتها بال++C أو C أو System API مهمة و لن تستطيع اعادة كتابتها بال#C فهذا لن يمنعك من استخدامها في #Cحتى و لو كانت هذه الAPI تستخدم C++ Pointers فيمكنك تعريف مؤشرات مثل التي توجد في ++C\C بالضبط و استخدامها و تبادلها من أكواد ال++C\C

الذي بنى #C لديه نظرة واسعة يا عزيزي, لغة لا تتعايش مع البيئة التي حولها يصبح من الصعب التعايش معها,

و ليس للأمر علاقة بالماضي, الأمر له علاقة بالوصول إلى خارج إطار NET. نفسه عند الحاجة,

#C تستطيع التعايش coexist مع بيئات أخرى, بينما في Java على سبيل المثال هذا الشيء صعب, python تدعم التعايش مع البيئات الأخرى,

و ++C تفرضه :)

ليس للأمر علاقة بالماضي, الأمر له علاقة الحاضر, لأنه لا يوجد شيء يبني بلغة واحدة أوتقنية واحدة, لذلك لا بد من طريقة للتعايش.

اقتباس

تستخدم C++ Pointers فيمكنك تعريف مؤشرات مثل التي توجد في ++C\C بالضبط و استخدامها و تبادلها من أكواد ال++C\C

لا, المؤشرات في #C حتى الـ unsafe منها ليست مساوية لمؤشرات ++C من حيث القوة,

لهذا أنشأت microsoft لغة cpp.net لعمل جسر بين الـ net. و العالم الخارجي,

لكي ننهي هذا النقاش,

أنا لست معارضاً لاستخدام #C على الإطلاق, إن كانت تؤدي المهمة فهذا جميل,

على العكس أنا تعلمت Java و المناطق التي كرهتها في Java وجدتها جميلة جداً في #C,

لو ترجع لمشاركاتي حول Java ستجد أني من أشد المعارضين لها بسبب إلغاء الـ operators overloading فيها,

كرهتها بسبب تقييد المبرمج بأسلوب البرمجة الكائنية حتى عندما لا يكون هذا الأسلوب هو الأفضل, حتى الـ generics فيها سيئة, في #C تم تفادي الخطأ من جديد,

تم إعطاء المبرمج حرية أكثر بكثير في #C, و جعلها أصعب و لكن هذا لا يجعلها أسوأ ,

أقصد بأنها أصعب, ليس في عملية البرمجة وإنما خلال تعلم مفاهيمها,

و ++C كذلك الأمر, تحتاج لوقت طويل حتى تصبح محترفاً في ++C, و لكن الأساليب البرمجية التي ستكتسبها ستجعل حل المشاكل أسهل,

في Java أنت تتعلمها بسهولة, لأن الأدوات التي توفرها محدودة جداً,

الأخ بندر قال, بأن المقارنة بين #C أو Java و بين ++C غير عادلة, و أنا أتفق معه 100%, و كان هذا رأيي من الموضوع الأول الذي تناقشنا فيه,

لأن تلك اللغات ليست موجهة لنفس الأغراض و إن تشابه الـ syntax :)

تحياتي ...

أعتقد أن هذا وقت مناسب لانهاء النقاش فالهدف من النقاش ليس ذم أي من التقنيتين أو حث المبرمجين على ترك اي منهم, بل الهدف المتضمن هو الاجابة على أسئلة و مفاهيم ملتبسة و قد تعلمت الكثير من الحوار معك, و أعتقد أن هذا الحوار هو من (أهدأ) الحوارات التي قمت بها :lol:

و أنا خرجت بالفائدة من هذا النقاش أيضاً,

سرني الحوار مع أخ متميز,

تحياتي ...

لستم الوحيدين الذين أستفدتما ...

وسبب هدوء هذا الحوار هو أن الموساد الإسرائيلي لم يعلم عنه , وإلا كانت فيه مؤمرات ودساس :lol:

والسبب الذي يأتي بعده هو قلة عدد المحاوريين وبالتالي المواضيع ما تشعبت , وكان فيه تركيز ... حتى إني كان عندي أكثر من تعليق لكن أثرت عدم ذكره فقط , لكي لا تكون حرب B)

الله يعطيكم العافية ... :clapping:

شكرا على الحوار الرائع الذي حاولت جاهدا أن أفهم شيئا منه و لكن لم أتمكن :clapping: :lol: :lol:

أعتقد الموضوع بحاجه لقراءه معمقة في وقت فراغ إن شاء الله