C++.NET умирает?
Нашли ответ, пройдя по источнику и попробовав несколько разных комбинаций.
Проблемы, упомянутые в этом вопросе, были исправлены в выпуске Hateoas 0.25.1, поэтому одной из частей решения было обновить Hateoas до 0.25.1.
Другая часть основана на ссылке SO, приведенной в вопросе, но она не работала как есть, в моем случае, поскольку она применима только для Spring Boot. Поскольку мы не используем Spring Boot, но у нас есть традиционное веб-приложение, работающее с контейнером J2EE, решение состоит в том, чтобы включить ForwardedHeaderFilter как часть web.xml веб-приложения следующим образом:
<filter>
<filter-name>forwardedHeaderFilter</filter-name>
<filter-class>org.springframework.web.filter.ForwardedHeaderFilter</filter-class>
<init-param>
<param-name>relativeRedirects</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>forwardedHeaderFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
7 ответов
Если вы нацелены на платформу .NET при разработке приложений, то да, C ++ / CLI - гражданин второго сорта по сравнению с C #. C # был специально разработан как язык для платформы .NET, в то время как расширение C ++ / CLI позволяет разработчикам связывать нативный и управляемый код.
Однако не путайте C ++ с C ++ / CLI (C ++ .NET это то же самое ...). C ++ жив и здоров в таких областях, как ядро, игры, высокопроизводительные и серверные приложения (например, SQL-сервер), которые вряд ли изменятся. С другой стороны, большинство .NET "GUI вещи" не будет использовать C ++.
Управляемый C ++ никогда не был таким, каким думала MS. C # может делать (почти) то же самое, с гораздо более интуитивным и удобным синтаксисом.
Кроме того, C ++ / CLI не останется без поддержки в течение длительного времени, так как это простой способ создания взаимодействия между Сборки .NET и нативные сборки C ++. Это почти все, для чего он используется (я уверен, что 0,001% разработчиков C ++ / CLI там не согласны: P).
C ++ / CLI - это способ, которым Microsoft привлекает разработчиков на C ++ к .NET. Это было похоже на промежуточный уровень между нативным C ++ и C #, но я уверен, что разработчики предпочитают выбирать нативный C ++ или C #.
Microsoft не позволит C ++ / CLI умереть, по крайней мере, в ближайшем будущем, однако без поддержки сообщества C ++ / CLI не сможет расти.
В этом поколении не расти значит близко к мертвым.
Я думаю, ДА, это умирает, на самом деле он уже умер;), потому что не так много людей, которые используют его, они используют ли C ++ или C #. см. this
Боюсь, это так.
Причиной этого является не C # (который не несет в себе ничего особенного, и, хотя это новый язык, он не вводит новые языковые функции, а просто копирует функции других - обобщений).
Это главным образом потому, что первая попытка MS включить C ++ для платформы .NET - Managed C ++ - была катастрофой.
После этого они наняли Херба Саттера , гуру C ++, который проделал фантастическую работу по разработке замены Managed C ++ под названием C ++ / CLI.
Почему и насколько дизайн C ++ / CLI превосходит дизайн Managed C ++, вы можете узнать, прочитав Обоснование дизайна для C ++ / CLI , написанного Хербом.
Кстати, Херб сделал vc-компилятор одним из лучший, соответствующий стандартам компилятор для Windows, после многих лет работы он был худшим в отношении соответствия стандартам.
Нет. Он родился мертвым. К нему всегда относились как к классу второго класса без дорожной карты жизнеспособности.
Я не думаю, что это обязательно исчезнет, но причина его использования почти всегда сводится к тому, нужны ли вам преимущества в производительности, которые идут с ним. Если C # может делать то же самое на 90% эффективности C ++, разве это не достаточно хорошо?