سؤال

لقد قررت أنني أرغب في التعمق أكثر في تطوير التعليمات البرمجية الأصلية باستخدام C++.أحاول أن أقرر ما إذا كان سيتم خدمتي بشكل أفضل باستخدام CodeGear C++ Builder 2009 أو Visual Studio 2008.أستخدم حاليًا Delphi 2007، لذا فأنا مرتاح جدًا لاستخدام C++ Builder's IDE (وهو نفس دلفي)، بالإضافة إلى VCL وRTL.

لم أكن أبدًا معجبًا كبيرًا بـ MFC (منذ أول مرة لعبت بها في أيام VS 6.0)، لكنني لم ألقي نظرة فاحصة عليها منذ ذلك الحين.

أنا مهتم بالاستماع إلى بعض الخبراء الذين لديهم خبرة في كلا الإصدارين IDE، سواء كانا أحدث الإصدارات أم لا.

في الوقت الحالي، أميل نحو C++ Builder لأنني أعتقد أن VCL أكثر قوة وأسهل في العمل معه من MFC --- ولكن كما قلت، لقد مر وقت طويل منذ أن استخدمت MFC.لست مهتمًا ببناء برامج تعتمد على .NET Framework لأنني أقوم بتعليم نفسي جزئيًا التطوير الأصلي.هل لا يزال MFC هو الملك لنظام التشغيل Windows C++؟أم أن WTL أو ATL هو الشيء الكبير؟

هل يرغب أي من معلمي لغة C++ في مشاركة آرائهم؟

يحرر:أتفهم أن MFC ليس مجموعة أدوات واجهة المستخدم الرسومية الوحيدة لـ Visual Studio.ومع ذلك، أنا أبحث عن بعض التوصيات بناءً على مجموعة أدوات واجهة المستخدم الرسومية + IDE.بالنسبة لـ C++ Builder، هناك خيار حقيقي واحد فقط، وهو C++ Builder + VCL.بالنسبة لـ VS 2008، فإن الأمر VS + MFC/ATL/WTL/QT.... مربك بالنسبة لي لأنني لا أعرف الكثير عنها.

هل كانت مفيدة؟

المحلول

وقادمة من دلفي، ستجد VCL واضحة للاستخدام مع ++ C باني. هناك عدد قليل من الشذوذ، مثل C ++ لا يخفي حقيقة أن TObjects كلها حقا المؤشرات (الذي يخفي دلفي من أنت)، وبعض الأشياء مثل خصائص مجموعة يتم الوصول إليها بشكل مختلف.

واثنين أو ثلاث سنوات إلى الوراء، وكان يبحث عن أي وسيلة للخروج من ++ C باني، ولكن الآن، مع الإصدارات الأخيرة (وشراء EMBARCADERO من Codegear)، أنا سعيد مع المنتج والاتجاه.

وستجد عدد من أنواع سلسلة وعدم التوافق المحتملة متنوعة مؤلمة جدا مع ++ C باني، ولكن عليك أن تعتاد على ذلك! (الأمراض المنقولة جنسيا :: سلسلة، شار []، wchar_t []، TCHAR، ANSIString و، WideString، UnicodeString وسلسلة على سبيل المثال لا الحصر)

وأنا شخصيا كنت التصويت ل++ C باني - لأن من اتجاهين RAD وVCL، على الرغم من أنه قد لا يكون أفضل طريقة لتعلم التعابير الحديثة C ++.

نصائح أخرى

وVisual Studio ثم MFC ليست هي نفسها. I استخدام Studio طوال الوقت، وأنا تجنب MFC مثل الطاعون. يمكنك استخدام WTL، ATL، Win32 وأو أي عدد من المكتبات لإنشاء تطبيقات دون MFC.

والجواب البسيط هو أن للتنمية النقي C ++ يجب أن يكون VC ++.

لتوسيع: كبيئة تطوير نقية C ++ كنت ببساطة لا يمكن للفوز VC ++، المصحح هو أفضل، وIDE هو الافضل (جميع IMHO، وبطبيعة الحال). لقد استعملت لتطوير المكتبات التي I ثم استخدامها من ++ C باني بسبب من هذه الأسباب.

ولكن بمجرد البدء في تطوير UI، أو أي شيء أن تتمكن من حل باستخدام VCL أو مكونات C ++ B هو الخيار الأفضل. مقارنة VCL، MFC أو ATL الرهيبة على سبيل المقارنة، وذلك أن يترك لك لاستخدام .NET، التي من المحتمل ان يكون الخيار الأفضل، ولكن ليس

ولست متأكدا من أنني أنصح بناء منتج جديد باستخدام C ++ B أو دلفي على أساس السنوات القليلة الماضية من "الاتجاه 'من البائعين. ولكن الذي يبدو أنه تغيير للأفضل، ولكن حتى لقد مر وقتا أطول قليلا من الصعب أن أقول كيف تترجم الوعود إلى واقع ملموس.

إذا كنت تفعل C ++ تطوير نقية على ويندوز فإنه من الصعب الفوز على VS. المترجم هو، تماما سريع معايير المطابقة وتنتج جيدا الأمثل التعليمات البرمجية. المصحح هو الأفضل على أي منصة. وIDE على ما يرام.

وكما انها بوضوح toolchain مترجم الأكثر تأييدا واسع النطاق على ويندوز. تحميل أي المصدر المفتوح مشروع / مكتبة و، إذا تم اعتماد Windows، فمن المحتمل أنه قد تم بناؤها واختبارها باستخدام VS. يضمن شعبيتها أيضا أنه من الأكثر فائدة أن يكون على السيرة الذاتية.

وماذا باني تعطيك؟ مكتبة GUI معقولة. حسنا، هذا جيد، ولكن هناك العديد من الأدوات الأخرى واجهة المستخدم الرسومية لائقة هناك (كويدغيتس، GTK، كيو تي الخ). كثيرة هي المصدر المفتوح وعبر منصة.

ولكن، في هذه الأيام أجد أنه من الأفضل لإعادة هيكلة تطبيقات جهدي لتوفير API ومن ثم بناء واجهة المستخدم الرسومية على أعلى من ذلك في لغة مختلفة. قوة C ++ الصورة هي <م> لا في تطوير واجهة المستخدم الرسومية. على الأقل ليس اليوم ...

وسأختار - ويوصي - VS على بناء

وأنا لم تستخدم C + + منشئ لسنوات ولكن في موضوع التصحيح C ++، فيجوال ستوديو 2008 هو المخرج أمام بيئات التطوير الأخرى وVS السابق خاصة إذا كنت تستخدم حاويات STL لأنه يجعل من السهل جدا أن تفقد محتوياتها .

ولكن، وعلى الجانب GUI، C ++ الآن إلى حد كبير لغة من الدرجة الثانية لمايكروسوفت. الطريق للمستقبل هي WPF و C ++ غير معتمد على أنه XAML- اللغة دية : <م> وسوف يستمر الاستثمار في C ++ / CLI لتمكين المطورين لفضح الأصول المحلية C ++ لتمكن العالم والعكس بالعكس. ونحن نعتقد أن التنمية الصافي النقي ويتم أفضل استخدام. NET ركز لغة مثل C # أو VB. والاستثمار في C ++ / CLI تكون أساسا في المناطق إمكانية التشغيل المتداخل الأم المدارة.

وهكذا، لإنشاء <م> حديث المظهر C ++ GUI، الخيار الأفضل قد يكون في الواقع VCL - اذا استمرت VCL لاتخاذ مثل هذا ممكن؛ -)

وC ++ Builder هو أعلى بكثير من MS-VS عندما يتعلق الأمر اجهة المستخدم لتطوير أساس وقاعدة البيانات الموجهة للتطبيق. تمتص MFC !! ومع ذلك VS لديها قدرات أفضل التصحيح.

وأنا ثاني الذهاب ل++ C باني، بالنظر إلى أن كنت تعرف دلفي. وقد MFC لم تتغير كثيرا منذ أيام VS6، لذلك كود كتابة باستخدام MFC لا تزال تبدو مثل القرف. ومع ذلك، تغيرت VS والآن تماما IDE جيد.

وأيضا، أن نضع في اعتبارنا أن C ++ Builder هو غير مستقر كخط المنتج. كانت هناك مرات في الماضي حيث لم يكن الحفاظ عليه / ومستقبلها غير واضح وما إلى ذلك كنت أخذ فرصة إذا كنت ترغب في بناء شيء يدوم.

وفقط لأنها من الجحيم، يمكننا رمي في الكسوف إلى المزيج وكذلك منتديات أنا فقط وجدت العمل في كسوف أن يكون أفضل من العمل في الاستوديو المرئي.

وإلا إذا كنت تستخدم VS2008 مع WinForms عناصر واجهة المستخدم الرسومية الدعم من خلال النوافذ القوالب (عادة من الموارد) التي هي قبعة قديمة وربما كنت لا تريد استخدامه. وبالتالي فإن دعم واجهة المستخدم الرسومية في VS2008 ليست خاصة.

وأما بالنسبة للأدوات واجهة المستخدم الرسومية، وربما نرى ما هو جيد GUI / الحاجيات أدوات

حسنا، يمكنك استخدام الكسوف + مينغو + QT4 + QT الكسوف التكامل وتحصل على كل الاشياء: المصحح، البصري مصمم واجهة المستخدم الرسومية، الخ

والعقل أن QT4 غير مرخص المزدوج: المصدر المفتوح والترخيص التجاري

وكما يمكنك الجمع بين QT4 مع Visual Studio (حتى مع اكسبرس) واستخدام كل goodnes VS يمنحك.

وبالنسبة لي QT4 هو الطريق للذهاب وVS على البناء.

لقد أحببت C++ Builder منذ عامين.كانت رائعة.لقد كانت طريقة أفضل مع VCL من VS مع MFC السيئ.ثم تغيرت الأمور مع كل عام.

لقد كان البناء ينزل.1.لم يتم تحديث Builder بأي وظيفة حقيقية.2.تخلى بورلاند عن فكرة إعادة كتابة VCL في C ++ للاستخدام مع Kylix و Builder 3.أدت فوضى CodeGear والمستقبل غير المؤكد لـ Builder إلى إبعاد العديد من الأشخاص عن المنتج.

لقد كان VS يتحسن.1.تم تحسين IDE كثيرا 2.أصبح المترجم من الأقل توافقا مع المعايير على نظام windows الأساسي هو الأكثر توافقا مع المعايير (دون احتساب دول مجلس التعاون الخليجي على MinGW بالطبع) 3.ظهر .NET وكان هناك Managed C++ ثم C++/CLI لتمكين استخدام إطار العمل هذا من داخل C++

حصلنا على لاعبين جدد وأقوياء 1.كسوف 2.كيو تي الخالق

ومجموعات أدوات واجهة المستخدم الرسومية الجديدة

  1. wxWidgets
  2. Qt4 لديه الآن أيضًا ترخيص مفتوح المصدر

كي تختصر؛باني مات بسبب بورلاند

  1. كان يعتقد أن دلفي رائعة جدًا لدرجة أنهم لا يحتاجون حقًا إلى أي شيء آخر لكسب المال
  2. لقد وقع في ضجيج Java واستثمر الكثير من الموارد فيه
  3. لم أفهم القوة العظيمة لـ C++ وبدلاً من ذلك لجأت إلى لغة باسكال، والتي كانت دائمًا لغة أكاديمية مع عدم وجود منتجات حقيقية تم إنشاؤها باستخدامها

وعندما يتعلق الأمر شيئا تنمية النوافذ قمم حقا برنامج Visual Studio. ومن ميزة جدا غنية ولها المصحح ممتازة، ناهيك عن المجتمع واسعة من المستخدمين لمساعدتك في أي مشاكل التي قد تواجهها. إذا كانت أدوات تطوير الشركة لنظام تشغيل خاص بها لم يكن الأفضل لذلك، كنت أخشى وضعهم في عالم البرمجيات. ولكن إذا كنت لا تحتاج إلى ميزات اضافية وحاجة على الاطلاق أداة RAD مع السحب والإسقاط (إلى جانب MFC) C ++ باني ليست بعيدة جدا عن الركب. باستخدام بيئة دلفي قبل هو مجرد ميزة بالنسبة لك.

وشيء واحد حول ++ C باني الماضي CodeGear - أعني نسخة 2009 - هو أن التحديثات الخاصة به يمكن أن تجعل حقا كنت أكره هذا IDE.
وبعد تثبيت التحديث 2ND، اكتشفت أنه إذا / آخر كتلة لا يتلقى تعمل بشكل صحيح. يمكن أن تدخل IF بيان ولكن لا يمكن أن يدخل آخر واحد - وذلك لا يتلقى يتوقف على الوضع - وهذا تعليم اللغة توقفت ببساطة العمل على الإطلاق. كان الوقت الذي أخذني إلى أنها من أصل الرقم حوالي ساعتين أو ثلاث ساعات - وبدأت في تطوير التطبيق Win32 واللازمة في VS، أرى أنها أكثر موثوقية من المنتج CodeGear. ميزة 2ND لم يعجبني أن كنت تستطيع 'ر إيقاف دعم يونيكود ويضطرون إلى استخدام الإصدارات ANSI من الوظائف Win32 وبشكل واضح (على سبيل المثال SendMessageA (...)) وهو مملة جدا. أنا بالكاد الوفاء بالموعد النهائي لإنهاء المهمة باستخدام VS2008.
انها مجرد تجربتي، واختيار لجعل هو لك

وحاول عازر بدلا من ذلك. الكتابة مرة واحدة، تجمع الكثير. يعمل على منصات متعددة. سوف أي شخص يأتي من دلفي وKylix خلفية يشعر غاية في المنزل مع هذه الأداة RAD. أما بالنسبة للمستقبل، بل هو مصدر مفتوح مع مجتمع قوي، وتطوير يكمل بدون تقيد التجاري.

لتطوير الأصلي C ++ أنا لن ترغب في استخدام إما C ++ باني ولا VS. هي الأمثل كل هذه ايديس للاستخدام مع أطرها.

وأود أن تختار بدلا الكسوف، وقانون :: كتل أو Codelite. لا يتم تحسين هذه في IDE عن أي إطار ويمكنك التبديل بين عدة المجمعين على منصات severeal.

2012 وتنتهي تقريبا. كنت ++ المستخدم بورلاند C ثم swithced إلى VC ++ 6.0. في الآونة الأخيرة كان هناك شرط ffrom العميل الذي يريد نهاية واجهة المستخدم الرسومية لمنتجاتهم ولا نريد الاعتماد على إطار .NET. لذلك أنا بحثت EMBARCADERO RAD ستوديو XE2.

وعندما يتعلق الأمر بالتنمية C ++ RAD، لا أعتقد ذلك حتى MSVC ++ يأتي على مقربة منه. كان مثل نسيم. على الرغم من أنني وجدت مشاكل عند تجميع القوالب. على سبيل المثال إذا قمت بتعريف functor ويريدون الجمع بين المنشئ مع functor ندعو لكم غير قادر على القيام بذلك في C ++ B، لديك لإنشاء كائن ومن ثم استدعاء functor بشكل منفصل. هناك قضايا أخرى أيضا لم أتمكن من تجميع بالكامل مكتبة بوكو.

ولقد وجدت الحل من خلال خلق دلس في VC ++ ودعوتهم من B الواجهة C ++. أن يعطي أفضل من الاثنين معا.

وآمل أن EMBARCADERO أدرك مع المعايير قريبا.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top