.NET GUI - C# против C++/CLI
Я пишу небольшое приложение, которое требует несколько списков, кнопок, текстовых полей. Он будет связан с Boost, MySQL и т. Д. C++ static libs. Проект требует win32 функций. Я полагаю, что с Winforms все будет в порядке (MFC и CodeJock требуют слишком много времени).
Так что C++ / CLI кажется идеальным для этой работы. Просто используйте стандартный C++ вместе с GUI. Затем я сталкиваюсь с темами, предлагающими вместо этого написать свой графический интерфейс на C#. Затем используйте p/Invoke (медленный) или интерфейс C++ / CLI к вашим стандартным C++ DLL.
Пример: http://social.msdn.microsoft.com/Forums/en-US/clr/thread/6ae877ac-07b4-4d26-8582-de475ee9a5cb
Зачем? Какое преимущество имеет использование C# для графического интерфейса winforms вместо C++ / CLI (они выглядят одинаково, команды одинаковы). Какой недостаток в использовании исполняемого файла C++ / CLI вместо стандартного исполняемого файла C++. Я могу понять, была ли кросс-платформенная совместимость проблемой, но тогда вы просто не могли бы использовать управляемые функции (кроме GUI).
Я не понимаю, почему вы должны использовать C#, а затем зайти так далеко, чтобы отделить его от "движка DLL". Если, конечно, "DLL движка" использовалась и для других приложений.
Спасибо
6 ответов
Я думаю, что большинство рекомендаций по этому вопросу сосредоточены на том факте, что C# - просто лучшая среда для создания приложений.NET, чем C++/CLI. Синтаксис чище, инструменты лучше - как в Visual Studio, так и от сторонних разработчиков. Вы получите больше и лучшую поддержку от разработчиков, которые почти все будут лучше знакомы с C#.
Приложения C++ / CLI достаточно отличаются от стандартного C++ со всеми этими символами ^ и%, которые, по крайней мере, я считаю НЕ С ++.
Большинство советов также приходит с точки зрения того, что вы хотите создать приложение.NET, а C++ / CLI больше используется в качестве связующего слоя. Whenever I have used C++/CLI, it was grudgingly and almost always because some third-party library had many complex C/C++ objects that it passed around. When using C# and P/Invoke, you often have to create classes to mirror the structs and classes that are in the C++ header files of the software you are interfacing with. Keeping those in sync is labor intensive and making mistakes is easy to do. Furthermore, figuring out how to marshal a struct with pointers to structs of arrays of struct will make your brain melt!
My general advice is to use C# (or VB.NET) to create as much code as feasible for your application. Use P/Invoke when your need to call the Win32 API and/or 3rd party SDKs is limited and the interfaces and parameters are simple. Use C++/CLI as a glue layer when this is not possible.
In a team environment, your fellow developers will thank you for limiting your usage of C++/CLI to only where it is absolutely, positively required. C++/CLI expertise is just not that common.
Лично я люблю C++/CLI, но все же лучше написать свой пользовательский интерфейс на C#.
C++ / CLI отлично подходит для работы непосредственно с Win32 или для общения с унаследованным кодом, но он мне слишком многословен, когда дело касается кода пользовательского интерфейса. Код WinForms UI в C# приятный и простой (по большей части, хаха). Написание кода пользовательского интерфейса на C++ почти всегда грязно (просто посмотрите на MFC).
Почему бы просто не создать свой пользовательский интерфейс в одной сборке C# и поместить весь код более низкого уровня в сборку C++ / CLI? Приятной особенностью C++ / CLI является то, что вы можете создать управляемый слой, который легко может вызвать ваш код C#. Этот управляемый уровень может затем легко переадресовывать вызовы на собственный уровень прямого кода C++ или C.
В чем преимущество использования C# для графического интерфейса winforms вместо C++/CLI (они выглядят одинаково, команды одинаковы)?
Они не выглядят одинаково. C#, на мой взгляд, чище и имеет несколько полезных абстракций. Поддержка инструментов значительно лучше для C# или VB.net.
Посмотрите здесь пример сравнения
И не забывайте о таких продуктивных языковых функциях, как лямбда-выражения, LINQ, вывод типов и т. Д., Которые, как правило, обращаются к C# в первую очередь и довольно быстро переходят на VB.net, но редко попадают на C++/CLI.
Да, кажется, что большинство людей, которые автоматически предлагают использовать C# вместо C++, предполагают, что вы уже знаете C# или готовы потратить время на его изучение. Я не понимаю, что такое ненависть к C++/CLI WinForms. По крайней мере, если вы хотите портировать поверх существующего кода C++, он выполнит свою работу. По крайней мере, я прикрепил GUI к своему существующему C++, используя WinForms/CLI. Да, я, вероятно, использую C#, если я начинал с нуля, так как:
+1 Я уже знаю C
2 Я знаю, что намного проще и быстрее кодировать с помощью C
Но, как я уже сказал, если у вас уже есть код C++, вы действительно хотите начать с нуля?
Я задумался об этом, поэтому в Visual Studio 2008 я создал новый проект приложения Windows Forms, используя C++/CLI в качестве языка. Первое, что он сделал, выкинул ошибку. Поэтому я воспринял это как признак того, что этот материал не совсем готов к использованию. Может быть, я не даю этому достаточно шансов!
The file 'c:\source\Test\Test\Form1.h' does not support code parsing or generation because it is not contained within a project that supports code.
Это происходит всякий раз, когда я пытаюсь открыть созданный мастером файл Form1.h.
Я пишу небольшое приложение, которое требует несколько списков, кнопок, текстовых полей. Он будет связан с Boost, MySQL и т. Д. C++ static libs. Проект требует Win32 функции...
Я, вероятно, рискую быть опровергнутым, но, если большая часть вашего кода уже написана на C++ и использует функциональность C++, было бы проще написать ваш GUI на Native C++.
Вам не нужно использовать MFC для создания GUI. Посмотрите на Qt4, у них очень хороший учебник, так что вы можете начать писать GUI на C++ всего за несколько часов.