Возможно, это хорошая идея, чтобы отдельные понятия были разделены.
Во-первых, C++ - это язык, и он не указывает ничего о том, на какой платформе должен быть нацелен. В принципе, прямой код на C++ может быть скомпилирован на собственный ассемблер x86, байт-код Java, MSIL или что-нибудь еще, о чем вы думаете. Я считаю, что Adobe недавно создала компилятор C++, который генерирует байт-код Flash.
Во-вторых, с типичной нерешительностью Microsoft создала два языка C++, предназначенные для .NET. Во-первых, они создали «управляемые расширения для C++». Затем они решили, что он сосать, бросил его и попытался притвориться, что он никогда не существовал.
Теперь их лучший выбор для .NET-стиля C++ называется C++/CLI, но это не C++. Он расширяет и изменяет язык несколькими нестандартными способами. (И я считаю, что стандартный комитет C++ попросил их изменить имя, чтобы избежать путаницы, но они этого не сделали)
Visual Studio 2005 и новее поддерживает C++/CLI. (в разделе «Добавить проект» они перечислены в Visual C++ -> CLR)
Однако (вы не думали, что все так просто, не так ли?), Microsoft сделала это снова. После указания C++/CLI, который на самом деле является разумно продуманной попыткой интеграции C++ с CLI, они поняли, что практически никто его не использует! Оказывается, что даже программисты на С ++ обычно предпочитают использовать C#, когда они работают в .NET, и, собственно, родной C++.
Итак, теперь они сосредоточены на создании взаимодействия между родным C++ и .NET более простым и мощным. Однако C++/CLI вряд ли исчезнет. Он работает, и в некоторых случаях это полезно. Это просто не C++ - убийца, на который они изначально надеялись.
Visual Studio (с тех пор навсегда) также поддерживает собственные приложения на C++, скомпилированные для машинного кода x86, незанятые .NET. Они перечислены в диалоговом окне «Добавить проект» в Visual C++ -> Win32.
Итак, если вы хотите изучить C++, у вас есть два варианта: Изучите C++/CLI, который ограничивает вас только языком MS, который да, генерирует MSIL вместо собственного машинного кода и требует .NET для запуска, и вообще не стоит беспокоиться, потому что если вы собираетесь зависеть от .NET в любом случае, почему бы не написать в C#?
Или изучите надлежащий C++, который полностью отделен от .NET и не может напрямую ссылаться на сборки .NET.
Ключевым моментом является то, что они являются отдельными языками. Либо вы компилируете как C++/CLI, что означает, что компилятор позволит вам ссылаться на сборки .NET, и будет генерировать код MSIL, или вы компилируете как C++, и в этом случае мир .NET не существует.
И, наконец, обратите внимание на осторожность. Несмотря на мою формулировку выше («правильный C++» и «незанятый .NET»), C++ не «лучше». Во многих случаях это происходит не быстрее. C++ имеет потенциал , чтобы быть быстрее, но это зависит от программиста.
Компилятор C# превратит почти все в разумно эффективный код. C++ с другой стороны, полны подводных камней, которые сделают ваш код более медленным чем эквивалент C#.
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx и сообщения в блогах, ссылки на них заслуживают внимания для тех, кто интересуется производительностью аналогичного кода, написанного на двух языках.
Существует только одна область, где приложения C++ будут последовательно быстрее, и это во время запуска. .NET-приложение, возможно, придется загрузить платформу .NET и JIT-код MSIL, где начинается собственное приложение ... только начинается.
Но, кроме этого, вероятно, ошибочно предположить, что C++ будет быстрее. Это может быть быть, потому что это дает вам немного больше контроля. Но обычно это означает, что компилятор менее способен избавить вас от неэффективности, которую вы создаете в своем коде.
В «сетчатой оболочке» :) –