O C ++. Net é usado extensivamente?

Eu sou um codificador C ++ por tradição. Nos últimos 12 meses, eu tenho feito muita codificação em C # e fiquei agradavelmente surpreendido com a abordagem pragmática do C # (uma vez que parei de tentar codificá-lo como se fosse "C ++ com coleta de lixo").

Recentemente, tivemos alguns graduados e, ao ajudar um deles, percebi que ela estava usando .Net dentro de C ++. Depois de perguntar o porquê, ela disse que havia sido "instruída a usar C ++ por seu gerente". Problema de comunicação óbvio à parte, presumo que ela estava usando .Net porque é a única estrutura à qual ela foi exposta.

Em seguida, deparei com um projeto antigo de um desenvolvedor sênior que também usava C ++ para conduzir um front end do Forms. Agora, isso teria sido escrito na época em que o .Net apareceu pela primeira vez, então suponho que foi um exercício de aprendizado da parte dele para brincar com o .Net. Era apenas um pequeno aplicativo utilitário.

Depois de fazer algumas pequenas modificações neste aplicativo, pareceu-me que o uso de C ++ para dirigir .Net oferece o pior dos dois mundos. Sem coleta de lixo ou segurança de memória, mas sem oportunidades reais de otimização / velocidade, pois você está lidando com uma estrutura gerenciada.

Portanto, minha pergunta é se as pessoas usam o C ++ .Net para qualquer código de produção autônomo (ou seja, não hidráulico) e, em caso afirmativo, quais são as suas razões para isso? Admito livremente que nunca mergulhei profundamente nas extensões C ++ .Net, por isso posso estar fazendo um desserviço.

C ++. NET (ou, precisamente, C ++ / CLI) faz tem coleta de lixo, como tudo que é executado em cima de .NET. Para conseguir isso, mantendo-se compatível com o C ++, ele usa ^sintaxe e gcnewpara ponteiros de coleta de lixo ('seguro').

C ++ / CLI é considerado uma abominação para muitos, é significativamente mais desagradável de se trabalhar do que C # ou C ++, e também mais complicado do que qualquer um (simplesmente porque traz a complexidade do próprio C ++ para a tabela e adiciona o que é necessário para trabalhar com .NET para o mix). Aprender C # geralmente compensa mesmo dentro do escopo de um único projeto de tamanho médio. No entanto, há uma coisa que pode ser feita nem o C # nem o C ++ nativo: compilar o C ++ existente no .NET e conversar com outros componentes do .NET.

Consequentemente, não faz muito sentido usar C ++ / CLI para um projeto a partir do zero - qualquer coisa relacionada ao .NET que possa ser feita com isso também pode ser feita em C #, com sintaxe muito mais agradável e a segurança adicional de não expor a matéria-prima ponteiros por padrão. Sua raison-d'etre mais proeminente é a transferência de bases de código existentes para o .NET. Uma empresa que decide começar a usar o .NET, mas não quer (ou não pode devido a restrições de recursos e tempo) reescrever todos os softwares que produziu até agora, pode usar o C ++ / CLI para continuar usando a base de código existente com apenas alterações mínimas, e, em seguida, reescreva os componentes do sistema em C #, um por um. Pelo menos essa é a teoria; Eu nunca vi isso sendo feito na prática, então não posso dizer o quão bem funciona.

Observe também que o próprio C # pode interagir com bibliotecas nativas; portanto, mesmo que você precise usar as bases de código C ++ existentes, não é necessário recompilá-las no .NET: geralmente, a interface com elas através de COM ou P / Invoke é a melhor solução. .