Приложение Win32 Console и приложение консоли CLR
Я работаю над проектом на С++, который я не намерен разрабатывать или развертывать с использованием .NET-библиотек или инструментов, что означает, что для меня было бы целесообразно создать его с помощью приложения Visual Studio Win32 Console. Тем не менее, я слышал, что возможности отладки при использовании приложения CLR в Visual Studio гораздо более мощные. Поэтому у меня есть несколько вопросов:
-
Правда ли, что наличие приложения CLR и приложения Win32 добавляет возможности для вашего процесса разработки, даже если вы не используете какие-либо .NET-библиотеки или другие ресурсы?
-
Если да, смогу ли я по-прежнему разрабатывать/компилировать проект как проект CLR, чтобы использовать его, даже если бы я разрабатывал чистый проект на С++ с использованием STL и т.д. и не использовал любые функции .NET? Или такой проект потребует фундаментальных различий, которые сделали бы его нетривиальным для возврата назад, то есть я должен придерживаться консольного приложения Win32?
Ответы
Ответ 1
Ответ на нижнюю строку, если вы никогда не намереваетесь использовать CLR или любые объекты .Net в своем приложении, просто используйте обычную библиотеку Win32 С++. Делать что-нибудь еще причинит вам боль в дороге.
Теперь, чтобы ответить на исходный вопрос об отладке, да, отладка с CLR имеет определенные преимущества перед отладкой обычного С++-приложения. Начиная с Visual Studio 2005, как С#, так и VB.Net начали фокусироваться на том, чтобы сделать отображение переменной в locals/autos/watch более ценным. Это было сделано главным образом благодаря внедрению таких атрибутов .Net, как DebuggerDisplay, DebuggerTypeProxy и рамки визуализатора.
Если вы не используете какие-либо типы .Net, вы не получите ни одного из этих преимуществ.
Оценщик выражений С++ не использует ни одно из них. Он имеет собственные методы настройки отображения типов. Но это не так эффектно (или потенциально опасно) как стиль атрибута, потому что он не позволяет запускать код в процессе debugee.
Это не означает, что отладка С++ обеспечивает плохой опыт. Это просто другое, и для многих типов контейнеров STL есть лучшие дисплеи.
Отладка приложения CLR также имеет определенные недостатки. Например, отладка оптимизированного кода почти невозможна, потому что JITer скроет локальные переменные, параметры и часто "this". Отладка аналогично сконструированного С++-приложения также может быть разочаровывающим, но вы всегда можете захватить регистры и неутешительно, чтобы увидеть, что происходит. Сделать то же самое для приложения CLR сложно в лучшем случае.
Ответ 2
Я думаю, что компиляция собственного кода на С++ в CLR открывает целую банку червей. Если у вас нет больших инвестиций в существующий код на С++ и некоторая необходимость запуска кода с управляемыми типами, этого вы хотите избежать.
Например, С++/CLI - это один из способов связать собственный С++-код прямо в сборке CLR, но С++/CLI добавляет нестандартный синтаксис к языку С++, а использование родных типов С++, смешанных с управляемыми типами, кажется очень сложным как минимум.
Итак, в заключение я бы просто сохранил его как родное приложение. Если у вас есть план портирования его на CLR, и вы только начали работать над этим проектом, я бы серьезно подумал о том, чтобы начать писать на родном языке CLR, таком как С#.
Ответ 3
Этот ответ скопирован здесь - http://social.msdn.microsoft.com/Forums/vstudio/en-US/895ecb47-8b34-4a1a-a20b-fda1e5e576eb/whats-the-difference-between-clr-console-application-and-win32-console-application
В чем разница между консольным приложением CLR и консольным приложением win32?
- Первый использует Common Language Runtime (другими словами,.NET framework); последнее не делает.
и я не могу использовать систему пространства имен под моделью консоли консоли win32.
- Системное пространство имен является частью платформы .NET.
Что делать, если я хочу использовать пространство имен?
- Вы должны написать приложение .NET.
И не имеет ли он подсказки ввода, например, в модели С#?
- В существующих версиях Visual Studio на самом деле нет IntelliSense для С++/CLI. Если вы хотите использовать .NET-приложение, С# может быть лучшим выбором языка.