Rodrigo Strauss :: Blog

Bye Bye C++/CLI

Como "xingar muito no Twitter" não faz muito meu estilo, vou usar bem mais do que 140 caracteres para explicar porque C++/CLI entrou na minha lista negra de tecnologias.

A promessa parecia maravilhosa: uma tecnologia que permite integrar código C++ nativo com código gerenciado .NET de forma quase automática. Confesso que quando o C++/CLI foi lançado eu fiquei realmente impressionado, imagino o trabalho que deve ter dado para fazer isso. Mas como na prática a teoria é outra, depois de usar C++/CLI e ter muitos problemas, resolvi jogar a toalha. Motivos para minha decisão:

• Ao usar C++/CLI reneguei minha máxima de só usar tecnologias Microsoft que eles usam internamente. Assumo que C++/CLI não é extensivamente usando dentro da Microsoft, pelo simples fato de nunca ter lido nada sobre isso.
• O Intellisense do Visual Studio 2010 não tem suporte a C++/CLI. O SP1 também não. Agora a Microsoft está prometendo para próxima versão. Tarde demais.
• For fuck sake, NÃO EXISTE Application::Run em C++, isso é C++/CLI. No help do framework você pode filtrar pelas linguagens. E tem um tal de C++ em todos os tópicos do .NET Framework, mesmo que o compilador de C++ só gere código nativo. A Microsoft criou uma IMENSA confusão entre C++ e C++/CLI, e isso é notório na lista C & C++ Brasil (exemplo 1, exemplo 2 e exemplo 3).
• Quando você ativa o suporte a C++/CLI, o compilador começa a reclamar com algumas coisas do Boost ([1], [2]). Muitas vezes o código compila mas o programa não roda. A única solução é encher tudo de #pragma managed e #pragma unmanaged. Mas a Microsoft recomenda que você não faça isso, mas sim, reestruture seu código (e note que o bug do link foi fechado como "wont fix"). Alguém pode até dizer que "Boost é incompatível com C++/CLI". Mas Boost é C++ padrão, e o C++/CLI propõe integrar código C++ padrão com .NET. #FAIL
• Não vejo prioridade para correções nos bugs do compilador relacionados a C++/CLI
• Quando você chama código C# a partir de um código C++/CLI, muitas vezes o debugger do Visual Studio não percebe que você mudou para código gerenciado (mesmo com o debug "managed" ativado), e você não consegue fazer debug.

Migrei todo meu código C++/CLI para C++ comum. Tudo que é C++ fica em uma DLL, onde eu exporto tudo como funções C. Nessas funções C eu faço a ponte entre .NET e C++ de forma manual (coisa que o C++/CLI deveria fazer automaticamente). É necessário fazer código ponte na parte C# também, principalmente para fazer o marshal/unmarshal e para guardar a referência dos delegates passados como ponteiro de função. Pronto, agora tudo funciona como deveria, eu sempre consigo fazer debug, e eu sei que não vou perder uma semana inteira (isso já aconteceu) mudando flags de compilação até meu projeto funcionar.

Já que eu já comecei a sessão reclamação, vou aproveitar para mandar mais um bullet point (ponto de bala?):

• A IDE do Visual Studio 2010 é a pior ide que eu já vi a Microsoft colocar no mercado. Pelo simples fato de ser extremamente instável e bugada. Cai toda hora. O Intellisense para C++ continua sendo uma piada, só que agora uma piada que consome 100% de processador quase sempre através do mais novo penduricalho do Visual C++, um tal de vcpkgsrv.exe. Quando você digita isso no Google, a primeira sugestão é "vcpkgsrv.exe crash". Bom para Whole Tomato, que continua muito bem vendendo o Visual Assist.
• Para ser justo, o compilador C++ do Visual Studio 2010 é o MELHOR COMPILADOR C++ QUE EU JÁ VI. Até hoje não vi nenhum "internal compiler error". E tem um ótimo suporte à C++0x. O único problema é a ambiguidade de coisas como ter std::shared_ptr e boost::shared_ptr, mas isso não é culpa da Microsoft.

Prometo que o próximo post terá código (em Assembly se possível), porque, afinal, a humanidade já possui uma ferramenta oficial para reclamar de tudo e todos, o Twitter.

Em 04/03/2011 20:04, por Rodrigo Strauss

Comentários