.NET GUI - C # против C ++ / CLI

Question

Я пишу небольшое приложение, которое требует несколько списков, кнопок, текстовых полей. Это будет связано с Boost, MySQL и т. Д. C ++ static libs. Проект требует win32 функций. Я полагаю, что с Winforms все будет в порядке (MFC и CodeJock требуют слишком много времени).

Так что C ++ / CLI кажется идеальным для этой работы. Просто используйте стандартный C ++ вместе с GUI. Затем я сталкиваюсь с темами, предлагающими вместо этого написать свой графический интерфейс на C #. Затем используйте p / Invoke (медленный) или интерфейс C ++ / CLI для ваших стандартных библиотек C ++.

Пример: http://social.msdn.microsoft.com/Forums/en-US/clr/thread/6ae877ac-07b4-4d26-8582-de475ee9a5cb

Почему? В чем преимущество использования C # для графического интерфейса winforms вместо C ++ / CLI (они выглядят одинаково, команды одинаковы). Какой недостаток в использовании исполняемого файла C ++ / CLI вместо стандартного исполняемого файла C ++. Я могу понять, была ли кросс-платформенная совместимость проблемой, но тогда вы просто не могли бы использовать управляемые функции (кроме графического интерфейса).

Я не понимаю, почему вы должны использовать C #, а затем зайти так далеко, чтобы отделить его от «движка DLL». Если, конечно, «DLL движка» использовалась и для других приложений.

Спасибо

Answer 1

Я думаю, что большинство рекомендаций по этому вопросу сосредоточены на том факте, что C # - просто лучшая среда для создания приложений .NET, чем C ++ / CLI. Синтаксис чище, инструменты лучше - как в Visual Studio, так и от сторонних разработчиков. Вы получите больше и лучшую поддержку от разработчиков, которые почти все будут лучше знакомы с C #.

Приложения C ++ / CLI достаточно отличаются от стандартного C ++ всеми этими символами ^ и%, которые, по крайней мере, я считаю НЕ С ++.

Большинство советов также приходит с точки зрения того, что вы хотите создать приложение .NET, а C ++ / CLI больше используется в качестве связующего слоя. Всякий раз, когда я использовал C ++ / CLI, это было неохотно и почти всегда, потому что в какой-то сторонней библиотеке было много сложных объектов C / C ++, которые она передавала. При использовании C # и P / Invoke вам часто приходится создавать классы для отражения структур и классов, которые находятся в заголовочных файлах C ++ программного обеспечения, с которым вы взаимодействуете. Синхронизация людей является трудоемким делом, а делать ошибки легко. Кроме того, выяснение того, как распределить структуру с указателями на структуры массивов структуры, заставит ваш мозг таять!

Мой общий совет - использовать C # (или VB.NET) для создания максимально возможного количества кода для вашего приложения. Используйте P / Invoke, когда ваша потребность в вызове Win32 API и / или сторонних SDK ограничена, а интерфейсы и параметры просты. Используйте C ++ / CLI в качестве связующего слоя, когда это невозможно.

В командной среде ваши коллеги-разработчики будут благодарить вас за ограничение использования C ++ / CLI только там, где это абсолютно положительно требуется. Опыт работы с C ++ / CLI не столь распространен.

Answer 2

Лично я люблю C ++ / CLI, но все равно лучше написать свой пользовательский интерфейс на C #.

C ++ / CLI отлично для непосредственной работы с Win32 или общения с унаследованным кодом, но мне это слишком многословно, если мне нравится код пользовательского интерфейса. Код WinForms UI в C # приятный и простой (по большей части, хаха). Написание кода пользовательского интерфейса на C ++ почти всегда грязно (просто посмотрите на MFC).

Почему бы просто не создать свой пользовательский интерфейс в одной сборке C # и поместить весь код более низкого уровня в сборку C ++ / CLI? Приятной особенностью C ++ / CLI является то, что вы можете создать управляемый слой, который легко может вызвать ваш код C #. Затем этот управляемый уровень может легко переадресовывать вызовы на собственный уровень простого кода C ++ или C.

Answer 3

В чем преимущество использования C # для вашего winforms GUI вместо C ++ / CLI (они выглядят одинаково, команды одинаковые)?

Они не выглядят одинаково. C #, на мой взгляд, чище и имеет несколько полезных абстракций. Поддержка инструментов значительно лучше для C # или VB.net.

Смотрите пример сравнения

И не забывайте о таких продуктивных языковых функциях, как лямбда-выражения, LINQ, вывод типов и т. Д., Которые, как правило, сначала обращаются к C # и довольно быстро переходят на VB.net, но редко попадают в C ++ / CLI. *

Answer 4

Да, кажется, большинство людей, которые автоматически предлагают использовать C # вместо C ++, предполагают, что вы уже знаете C # или готовы потратить время на его изучение. Я не понимаю, что такое ненависть к C ++ / CLI WinForms. По крайней мере, если вы хотите портировать поверх существующего кода C ++, он выполняет свою работу. По крайней мере, я прикрепил графический интерфейс к своему существующему C ++, используя WinForms / CLI. Да, я, вероятно, использую C #, если начинаю с нуля, так как:

1 я уже знаю C

2 Я знаю, что гораздо проще и быстрее кодировать с помощью C

Но, как я уже сказал, если у вас уже есть код C ++, вы действительно хотите начать с нуля?

Answer 5

Я пишу небольшое приложение, которое требует несколько списков, кнопок, текстовых полей. Это будет связано с Boost, MySQL и т. Д. C ++ static libs. Проект требует win32 функции ...

Я, вероятно, рискую быть опровергнутым, но, если большая часть вашего кода уже написана на C ++ и использовать функциональность C ++, не будет проще написать свой графический интерфейс на Native C ++.

Вам не нужно использовать MFC для создания GUI. Посмотрите на Qt4 , у них очень хороший учебник так что вы можете начать писать GUI на C ++ всего за несколько часов.

Answer 6

Я задумался об этом, поэтому в 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.