Max Home IndustryНедавнее сообщение в блоге обещает, что C ++ / CLI будет доступен в следующей версии .NET Core. но возникает вопрос, почему он недоступен в этой версии .NET Core. Любит ли C ++ .NET?
Долгое время существовало глубокое подозрение, что команда разработчиков C ++ действительно не любит .NET. У меня нет доказательств, и я уверен, что они будут это отрицать, но почему им должен нравиться .NET, который предоставляет C #, язык, который, возможно, намного лучше объектно-ориентированного C, и объектную технологию, которая делает COM сложным и трудным? использовать?
Тем не менее, команда C ++ пыталась поддерживать .NET, но когда вы просматриваете его историю, это выглядит как беспорядок. Первой попыткой в 2002 г. был Managed C ++, в котором был введен новый синтаксис, позволяющий ему работать со средой выполнения .NET и компилироваться в CIL, а не в машинный код. В 2004 году он был заменен на C ++ / CLI, который попытался упростить синтаксис и установить стандартное расширение для C ++. Он был стандартизирован ECMA и является единственным способом создания программ .NET C ++.
Однако в последнее время C ++ / CLI отличался отсутствием в каких-либо будущих документах по планированию, и в открытых источниках .NET его почти не видели. Частично причиной этого стало внедрение WinRT. Вместо .NET и C ++ / CLI группа C ++ с большим энтузиазмом восприняла расширение C ++ / CX для языка C ++, которое заимствовало часть синтаксиса из C ++ / CLI, но нацелено на неуправляемый код, предназначенный для работы под WinRT. То есть C ++ / CLI был способом C ++ для создания приложений UWP и избегания любого контакта с .NET или управляемым кодом и возврата к COM-подобным объектам времени выполнения.
Несомненно, если бы UWP и WinRT оказались успешными, а не ошеломляющей ненужной технологией для телефона, в которой мир не мог бы убедить, что он нужен, то, я думаю, мы бы все меньше и меньше слышали о C ++ / CLI и даже о .NET . В настоящее время мир стал другим, и группа C ++ теперь готова поддерживать C ++ / CLI, но не раньше следующей версии (3.1) .NET Core.
На данный момент, если вы хотите использовать .NET Core 3.0, вы не можете использовать C ++ / CLI. Как указано в документе .NET Is One With .NET 5, .NET Core 3.1 призван стать последней из «основных» версий платформы с открытым исходным кодом и будет переименован в .NET 5.0, что свидетельствует о том, что это всего лишь версия. фреймворка, идущего в будущее. Таким образом, включение C ++ / CLI в .NET Core 3.1 почти настолько поздно, насколько это могло быть оставлено. Другими словами, если C ++ / CLI не поддерживает .NET Core 3.1, он не будет работать ни в одной из текущих версий платформы.
Однако лучше поздно, чем никогда, и для того, чтобы .NET стала ведущей технологией, ей потребуется C ++ / CLI и активная поддержка со стороны команды C ++.
В то время как другие языки .NET, такие как C #, могут быть нацелены на любую платформу, на которой работает .NET Core, C ++ / CLI нацелен только на Windows, что странно, учитывая, что если он нацелен на CIL, он создаст код, который должен работать на чем угодно. Однако C ++ / CLI создает некоторый машинный код, который делает его специфичным для платформы.
Все, что мы действительно знаем, это то, что C ++ / CLI будет доступен в следующей версии .NET Core. Мы не знаем, останется ли он в режиме обслуживания или будет дополнен новыми функциями и станет кроссплатформенным, каким бы ограниченным он ни был. Я полагаю, это означает, что будущее C ++ / CLI и безоговорочная поддержка .NET со стороны Microsoft все еще под вопросом.