لماذا لا يوجد اهتمام بلغة C++ CLI، سؤال موجه للأعضاء وخصوصا مبرمجي السي

اللغة فشلت بإمتياز .

هي كانت محاولة لجذب مبرمجي سي بلس إلى الدوت نت ..

من يريد الدوت نت ، يختار سي شارب ، بدلاً من أن يقف في المنتصف بين لغة سي بلس و بيئة الدوت نت .

الشمري كتب:

اللغة فشلت بإمتياز .

هي كانت محاولة لجذب مبرمجي سي بلس إلى الدوت نت ..

من يريد الدوت نت ، يختار سي شارب ، بدلاً من أن يقف في المنتصف بين لغة سي بلس و بيئة الدوت نت .

ردك غريب جداً اخي ، لا اعلم اذا كنت تعلم ما هي اهميه ال C++ CLI ؟؟

اللغه لم تفشل وهي تشكل العامود الفقري لل NET. .

والسبب بسيط للغايه هي للغه ال NET. الوحيده التي تستطيع ربط ال managed code بال unmanaged code .

تصور انك بنيت مكتبه بال c ، لنفرض مكتبه عملاقه وبعد فتره اردت ان تعمل لها تطبيق في بيئه ال .Net ، كيف يمكنك ذلك ؟؟ الطريق الوحيده هي استخدام ال C++.NET او اعاده كتابنت الكتبه من جديد بال #C .

ان اضن المشكله مع هذه اللغه ان الكثير لا يعرف اهميتها واستخداماتها .

اذا اردت ان تبني pure .Net Application فلا انصحك بأستخدام ال C++.NET ولكن كما قلنا سابقاً اذا اردت ان تبني برنامج يدمج ال unmanaged code مع ال managed code فليس هنلك طريقع افضل من ال C++.NET

Ali Al-Zyoud كتب:

اذا اردت ان تبني pure .Net Application فلا انصحك بأستخدام ال C++.NET ولكن كما قلنا سابقاً اذا اردت ان تبني برنامج يدمج ال unmanaged code مع ال managed code فليس هنلك طريقع افضل من ال C++.NET

حتى بالنسبة لـ pure .Net Application فهناك من يشدد النصح باستخدام C++.NET بدلا من أي لغة أخرى، لأن اللغة توفر عدة أوضاع "قيّمة" لترجمة الأكواد منها:

الوضع الآمن

(Safe MSIL Common Language Runtime Support (/clr:safe الكود الذي سوف يترجم بتعيين هذا الوضع يُسمى كود قابل للتحقق أو Verifiable، وسر التوسيم هذا هو أنه يمكن لـCLR التثبت من أن الكود المترجم بهذا الخيار لن يكتب في ذاكرة لا يملكها أو يملكها غيره، بالتالي لن تكون هناك انتهاكات وصولaccess violations وما شابه "مثلا استخدام المؤشرات pointers لا يسمح به في هذا الوضع". وبالمناسبة من مزايا هذا الوضع أنه لا يعتمد على بنية المعالج، أي أن البرنامج المترجم بهذا الوضع "الآمن" يعمل على CLR المخصص لبنية 64 أو 32 بيت معا.

الوضع النقي

(Pure MSIL Common Language Runtime Support (/clr:Pure

والكود الناتج بتعيين هذا الوضع يكون كود MSIL خالص لا تشوبه شاءبة! هذا الوضع يقابله الوضع unsafe في السي شارب! يسمح باستخدام المؤشرات في هذا الوضع.

طبعا يوجد كذلك الوضع المشهور وهو المخلوط أو Mixed mode الذي يسمح بترجمة خليط من الاكواد المدارة والغير مدارة معا جنبا إلى جنب وبكل سلاسة!

ناهيك أن هناك من يتحدث عن أن مترجم أكواد C++.NET تنتج أكواد MSIL هي الاسرع أداء من بين اللغات الأخرى ... أي more optimized MSIL

تابعوا هنا:

http://www.pcreview....e-t2437676.html

و

http://www.google.co...4171613aad2b88c

A.S Hack كتب:

حتى بالنسبة لـ pure .Net Application فهناك من يشدد النصح باستخدام C++.NET بدلا من أي لغة أخرى، لأن اللغة توفر عدة أوضاع "قيّمة" لترجمة الأكواد منها:

الوضع الآمن

(Safe MSIL Common Language Runtime Support (/clr:safe الكود الذي سوف يترجم بتعيين هذا الوضع يُسمى كود قابل للتحقق أو Verifiable، وسر التوسيم هذا هو أنه يمكن لـCLR التثبت من أن الكود المترجم بهذا الخيار لن يكتب في ذاكرة لا يملكها أو يملكها غيره، بالتالي لن تكون هناك انتهاكات وصولaccess violations وما شابه "مثلا استخدام المؤشرات pointers لا يسمح به في هذا الوضع". وبالمناسبة من مزايا هذا الوضع أنه لا يعتمد على بنية المعالج، أي أن البرنامج المترجم بهذا الوضع "الآمن" يعمل على CLR المخصص لبنية 64 أو 32 بيت معا.

الوضع النقي

(Pure MSIL Common Language Runtime Support (/clr:Pure

والكود الناتج بتعيين هذا الوضع يكون كود MSIL خالص لا تشوبه شاءبة! هذا الوضع يقابله الوضع unsafe في السي شارب! يسمح باستخدام المؤشرات في هذا الوضع.

طبعا يوجد كذلك الوضع المشهور وهو المخلوط أو Mixed mode الذي يسمح بترجمة خليط من الاكواد المدارة والغير مدارة معا جنبا إلى جنب وبكل سلاسة!

ناهيك أن هناك من يتحدث عن أن مترجم أكواد C++.NET تنتج أكواد MSIL هي الاسرع أداء من بين اللغات الأخرى ... أي more optimized MSIL

تابعوا هنا:

http://www.pcreview....e-t2437676.html

و

http://www.google.co...4171613aad2b88c

اكواد ال pure .Net من الافضل ان تكون safe وهذا الشيء موفر بالسي والسي شارب .

كما قلت من قبل اعتقد ان ميزه ال C++.NET او C++/CLI هي ليسه في كتابه كود ال .NET فهي لن تعطيك فروق عن ال #C او VB.NET قوة اللغه هي بعمل combination between ال native code وال managed code.

هذه الميزه غير متوفره بال سي شارب او ال VB .

عندما نكتب pure .Net Code فنه من الافضل ان نستعمل لغه صنعت لهذا الغرض مثل ال #C ، انا لا اقول ان #C افضل . اذا كنت تحب استخدام ال ++C استخدمها ، ففي النهايه كلها ستتحول الى MSIL سواء كتبت بال VB او #C او ++C .

واذا كنت تكتب pure .Net فنك دائماً تكتب:

Safe MSIL و Pure MSIL، لن تحتاج الى ان تغير هذا الا اذا كان هنالك UNSAFE CODE او ان الكود ليس PURE .nET

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

Ali Al-Zyoud كتب:

ردك غريب جداً اخي ، لا اعلم اذا كنت تعلم ما هي اهميه ال C++ CLI ؟؟

اللغه لم تفشل وهي تشكل العامود الفقري لل NET. .

والسبب بسيط للغايه هي للغه ال NET. الوحيده التي تستطيع ربط ال managed code بال unmanaged code .

ليس صحيح، بالإمكان الربط بين managed و unmanaged عبر المكتبات DLL

و يمكن الربط بين MFC و .Net مباشرة

دمج الmfc مع دوت نت

بن العيد كتب:

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

ليس صحيح، بالإمكان الربط بين managed و unmanaged عبر المكتبات DLL

و يمكن الربط بين MFC و .Net مباشرة

دمج الmfc مع دوت نت

؟؟ اخي انت تكتب عن شيء اخر

ماهي طبيعه ال output هنا ؟؟ هل هي .NET هل تم ترجمتها ال MSIL ؟؟ حتى مثالك يتكلم عن شيء اخر وهو استخدام مكتبات ال .Net بال MFC .

هنا نتكلم عن العمل تحت منصه ال NET. وليس بناء برامج بال MFC .

ارجو ان تكون اتضحت الفكره.

واخيراً، لماذا تقول ان هذا ليس صحيح صوف اسالك سؤال انت باي لغه كتبت برنامج ؟؟!!

لقد كتبته بال C++ CLI ، انت لم تستخدم ال C++ ANSI ، حتى مثالك يدل انك حتى تستخدم ال managed في ال unmanaged

سوف تستخدم C++ CLI واشكرك لطرحك هذه الفكره ايضاً :)

Ali Al-Zyoud كتب:

اكواد ال pure .Net من الافضل ان تكون safe وهذا الشيء موفر بالسي والسي شارب .

كما قلت من قبل اعتقد ان ميزه ال C++.NET او C++/CLI هي ليسه في كتابه كود ال .NET فهي لن تعطيك فروق عن ال #C او VB.NET قوة اللغه هي بعمل combination between ال native code وال managed code.

هذه الميزه غير متوفره بال سي شارب او ال VB .

عندما نكتب pure .Net Code فنه من الافضل ان نستعمل لغه صنعت لهذا الغرض مثل ال #C ، انا لا اقول ان #C افضل . اذا كنت تحب استخدام ال ++C استخدمها ، ففي النهايه كلها ستتحول الى MSIL سواء كتبت بال VB او #C او ++C .

نعم أخي كلها سيكون مصيرها لـ MSIL ولكن تكمن المفاضلة في أي منهم ( أعني مترجمات لغات الدوت نت) أنتج كود MSIL الأكفأ والأسرع! التجربة خير برهان.

أيضا هنا وجب التنبيه لنقطة كثيرا ما يخلط عندها... وهو القول بأن لغة C++ CLI قادرة على استيعاب الأكواد المدارة managed code والأكواد غير المدارة unmanaged code معا، وتارة أخرى نسمع أن القدرة تكمن في خلط الأكواد الطبيعية Native code والأكواد المدارة managed code! فهل في القولين فرق! اللهم نعم!

لدقة الموضوع، أذكر هنا ما هي الاحتمالات التي يمكن أن يتعامل معها مترجم C++ CLI:

ترجمة كود سي++ معياري طبيعي Native code إلى لغة MSIL أي ( كود مدار managed )

ترجمة كود مُدار إلى لغة MSIL وهو قطعا كود ( كود مدار managed )

ترجمة كود سي++ معياري طبيعي Native code إلى كود الآلة machine code ( كود غير مدار unmanaged )

لتقريب الصورة بشكل أوضح، لنأخذ هذه الدالة مثالا:

...
int func(){
int x=4;
int y[2]={1,2};
int s=x+y[1];
return s;
}
...

حسنا!، كلنا على إتفاق أننا لو أخذنا الكود السابق هكذا مجردا ونظرنا إليه لحكمنا أنه كود طبيعي أو native code، ولكن المفارقة هنا هي أنه لا يستطيع أحد منا الجزم أن الكود السابق غير مدار unamanged code !! مثلما لا نستطيع كذلك الجزم أنه كود مُدار managed code! لماذا ؟؟ لأن ذلك يعتمد على نظرة المترجم لهذا الكود! ملاحضة: اعتبر أن وضع الترجمة هو /clr.

فلو استدعينا الدالة السابقة على الشكل:

#pragma managed(push,off)
int func(){
int x=4;
int y[2]={1,2};
int s=x+y[1];
return s;
}
#pragma managed(pop)

عندها نستطيع أن نقول أنها دالة غير مُدارة وأنواع البيانات فيها غير مدارة كذلك، أي (unmanaged code)، بمعني أن أكواد الدالة وأنواع البيانات فيها غير موجه لـ MSIL أبدا أبدا..

أما لو ترجمنا الدالة بدون الموّجه pragma ، فالدالة لا ريب دالة مُدارة أي أن أكوادها managed code مع أنها native code! أكرر هي managed code و native code في الوقت نفسه!! كيف ذلك؟

المقصود بالكود المُدار هو الكود الموجه لـCLR، فالكود الطبيعي native code السابق سيكون مصيره إلى CLR وأنواع البيانات فيه ما هي إلا أسماء أخرى للأنواع في نظام النوع المشترك CTS، فمثلا النوع int سيتم التعامل معه على أنه System::Int32 وهكذا...

ملحوضة/ كون الدالة السابقة تحوي native array فالكود السابق لا يعتبر آمن مع أنه pure managed code، ذلك أن native array معرضة لتعيين عنصر out of range ولا يستطيع CLR أن يحميك من هذا!

بالتالي كون الكود unsafe لا يعني أنه غير مدار!

لذلك لا أظن دقة العبارة هذه

اقتباس

واذا كنت تكتب pure .Net فنك دائماً تكتب:

Safe MSIL و Pure MSIL، لن تحتاج الى ان تغير هذا الا اذا كان هنالك UNSAFE CODE او ان الكود ليس PURE .nET

اخي الكريم ارى انه حصل خطء في فهم ما كتبته واعتقد انه انا السبب.

انا احياناً "واعتقد العديد" يستخدم مصطلح اتل native code لدلاله على ال unmanaged code .

اعلم ان هنلك المعنى الاصح لهذا فهما مختلفين ولكن للاسف نعود ونستخدم ال كلمه native لنعبر عنها بانها unmanaged فأسف لذلك

ثم انني لم اقل ان ال كود ال unsafe ليس managed .

ما اقصده بال pure .Net هو انه الكود الذي لا يستخدم ال unsafe وكذلك لا يحتاج InteropServices لطلب اكواد unmanaged.

لو بحثنا في كتب ال NET. سنجد ان معضمها لن ينصحك بأستخدام ال unsafe الا لحاجه قسوه ، وفي معظم الحالات لا تحتاجه لان ال Framework توفر لك بديل ، ولكن قد يكون هناك حالات خاصه .

النقطه التي اردت ان اوصلها هو ان القوه الرئيسيه في ال C++ CLI هي استخدام ال unmanaged code مع ال managed code هي الوحيده التي توفر ذلك ، اما ما بقي فالجميع يوفره تقريباً .

اما من ناحيه من هو الافضل MSIL كود فانا لا اعلم من الافضل اذا كنت تمتلك مصدر لهذا الشيء اتمنى ان تفيدني .

هذه مقاله تدل على اهميه ال C++.NET او ال C++ CLI

http://msdn.microsoft.com/en-us/library/ms379617%28VS.80%29.aspx

اقتباس

لو بحثنا في كتب ال NET. سنجد ان معضمها لن ينصحك بأستخدام ال unsafe الا لحاجه قسوه

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

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

اقتباس

اما من ناحيه من هو الافضل MSIL كود فانا لا اعلم من الافضل اذا كنت تمتلك مصدر لهذا الشيء اتمنى ان تفيدني .

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

A.S Hack كتب:

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

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

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

النصيحه هذه لسيه للمبرمج غير المتمرس بالعكس ، انه من المنطق لااستفاده من موارد ال .net framework بحيث ان معضمها تغنيك عن استخدام شيء لا يتبع لاسلوبها .

انا اقل احياناً قد تحتاج استخدام ال unsafe code ولكن في حالات قليله.

من افضل الامثله استخدام ال goto في ال ++C نعلم كلنا انه من الافضل تجنبها ولكن يمكن استخدامها.

Ali Al-Zyoud كتب:

انا اقل احياناً قد تحتاج استخدام ال unsafe code ولكن في حالات قليله.

كونك اخترت C++ CII فأنت تختار استخدام unsafe code في أغلب الحالات، ألم نتفق أن الميزة في هذه اللغة هي القدرة على كتابة unmanaged code ..وبالتالي unsafe code

A.S Hack كتب:

كونك اخترت C++ CII فأنت تختار استخدام unsafe code في أغلب الحالات، ألم نتفق أن الميزة في هذه اللغة هي القدرة على كتابة unmanaged code ..وبالتالي unsafe code

في هذه الحاله نعم استخدام ال C++ CLI سيكون الافضل