Вероятно, неплохо бы разделить понятия.
Во-первых, C ++ - это язык, и в нем ничего не указано, на какую платформу следует ориентироваться. В принципе, прямой код C ++ может быть скомпилирован в нативный ассемблер x86, байт-код Java, MSIL или что-либо еще, о чем вы только подумаете. Я считаю, что Adobe недавно создала компилятор C ++, который генерирует Flash-байт-код.
Во-вторых, с типичной нерешительностью Microsoft создала два языка на основе C ++, ориентированных на .NET. Во-первых, они создали «управляемые расширения для C ++». Затем они решили, что это отстой, бросили его и попытались сделать вид, что его никогда не было.
Теперь их лучшая ставка на C ++ в стиле .NET называется C ++ / CLI, но это не C ++ . Он расширяет и изменяет язык несколькими нестандартными способами. (И я полагаю, что стандартный комитет C ++ попросил, чтобы они изменили имя, чтобы избежать путаницы. Но они не сделали)
Visual Studio 2005 и новее поддерживает C ++ / CLI. (в «Добавить проект» они перечислены в Visual C ++ -> CLR)
Однако (вы не думали, что это было так просто, не так ли?), Microsoft снова сделала это. После определения C ++ / CLI, который на самом деле является достаточно продуманной попыткой интеграции C ++ с CLI, они поняли, что практически никто не использует его!
Оказывается, что даже программисты на C ++ обычно предпочитают использовать C #, когда они работают в .NET, а в противном случае - собственный C ++.
Итак, теперь они сосредоточены на том, чтобы сделать взаимодействие между native 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 ++ будет быстрее. Это может быть, потому что это дает вам немного больше контроля. Но обычно это просто означает, что компилятор менее способен спасти вас от неэффективности, которую вы создаете в своем коде.