logo
Contato | Sobre...        
rebarba rebarba

Rodrigo Strauss :: Blog


Aos coitados que ainda precisam usar Visual C++ 6.0 (inclusive eu)

Seguindo a série de otimização de performance e meu post sobre o otimizador do Visual C++ 7.1, eu resolvi tentar compilar o parser usando o Visual C++ 6.0 Service Pack 5, para fazer uma comparação com o VC7.1. Sim, TENTAR é o termo exato. Apesar de alguns dizerem o que Visual C++ 6 suporta Boost, isso não é bem verdade, não é a primeira vez que eu tenho problemas tentando fazer o Boost compilar no Visual C++ 6.0. Olha só o que eu consegui com minha tentativa:

--------------------Configuration: spidl_vc6 - Win32 Debug--------------------
Compiling...
StdAfx.cpp
stlport\stl\_alloc.h(354) : fatal error C1001: INTERNAL COMPILER ERROR
        (compiler file 'msc1.cpp', line 1794) 
         Please choose the Technical Support command on the Visual C++ 
         Help menu, or open the Technical Support help file for more information
Error executing cl.exe.

spidl_vc6.exe - 1 error(s), 0 warning(s)

Pode parecer um erro da STLPort, mas eu uso a STLPort em vários projetos VC6 e não tenho problemas. O problema real é que o Boost (que eu uso no parser) é muita areia para o caminhãozinho do VC6.

A empresa onde eu trabalho ainda usa Visual C++ 6.0, assim como muitas outras. Não é o nosso caso, mas eu já reparei que muitas empresas ainda usam esse compilador velho, desatualizado e fora do padrão por causa da confusão que a Microsoft fez colocando .NET em tudo que existia - tanto que o próximo Visual Studio será "Visual Studio 2005", sem o .NERD no final. Muita gente acha que o Visual Studio.NET é uma suite de ferramentas para desenvolver somente aplicações .NET. Se faz necessário explicar claramente e em letras garrafais:

O Visual C++ 6.0 é MUITO velho, foi lançado em 1998, antes mesmo do padrão C++ ISO ter sido finalizado.

O Visual Studio.NET 2003 contém o Visual C++ 7.1, que é o último compilador C++ lançado pela Microsoft. Ele tem uma ótima conformidade com o padrão ISO e tem um otimizador muito bom. Usando o Visual C++ 7.1 seus programas não virarão .NET, serão 100% nativos. O Visual C++ 7.1 (que, novamente, vem junto com o "Visual Studio.NET 2003") importa seus projetos Visual C++ 6.0 sem maiores problemas. Na versão 7.1, tanto a MFC quanto a ATL foram bastante melhoradas, e vale a pena fazer o upgrade. O Windows XP SP2 e o Windows Server 2003 são compilados usando o Visual C++ 7.1, o mesmo que você recebe no Visual Studio.NET 2003.

O Visual C++ 7.1 (lembre-se, ele é parte do "Visual Studio.NET 2003") tem um flag (/clr) para compilar Managed C++ (o binding C++ para .NET), mas ele é opcional (afinal, é um flag). Usando o Visual C++ 7.1 você continuará gerenciando sua própria memória, aumentará sua produtividade (se você acha que C++ não é produtivo é porque você nunca usou), já que terá um compilador padrão ISO, e poderá usar Boost, Loki, ATL7, MFC7, etc. Ah, e além disso, você continuará fazendo programas muito mais rápidos do que seus amiguinhos do garbage collector... :-)


Em 01/09/2005 19:39, por Rodrigo Strauss


  
 
 
Comentários
Rafael Del Rey | em 06/10/2005 | #
Estamos há muito tempo tentando migrar para o VC7. Entretanto, criamos aplicativos que precisam ser muito pequenos (componentes Activex), e linkamos tudo com o Msvcrt.dll (Opção MultiThreaded DLL), que estah presente na maioria dos sistemas operacionais. No VC7, o equivalente desta opção deixa uma dependencia com o Msvcrt7.dll, que não vem instalado por padrão nos Windows (especialmente 9x e <= W2000). Em muitos casos nossos, o VC6 gera código menor que o do VC7 (talvez ateh porque o VC6 não gere código tão otimizado pra velocidade).

Abracos,

Rafael

PS.: Excelente seu blog.

Rodrigo Strauss | website | em 06/10/2005 | #
Existem várias formas para tentar resolver o seu problema. A primeira é fazer o link estático com a runtime do C. Outra é, se você está usando ATL, usar a opções de link sem a runtime do C (veja http://msdn.microsoft.com/library/default.asp?url=/library/e...)

Você também pode configurar o compilador para otimizar o tamanho da DLL "Optimize for size"
Wanderley Caloni | website | em 12/09/2006 | #
Existem algumas situações onde realmente o upgrade não é compensatório ou possível: falta de espaço em disco, falta de hardware, falta de memória, falta de sistema operacional (as versões .NET do Visual Studio rodam apenas em plataforma NT).
Hugo | em 10/10/2006 | #
e falta de dinheiro :-)
Fabricio Vicente de Gois | em 13/11/2006 | #
Olá pessoal!
Estou buscando profissionais Visual C++ para projeto de porte em Porto Alegre.
Caso se interessem ou tenham indicações, fico a disposição.


Um abraço!


Fabricio Gois
Rodrigo Strauss | website | em 13/11/2006 | #
Fabricio, sugiro que você coloque a vaga na www.apinfo.com
Rafael Pereira | website | em 01/03/2008 | #
Trabalhar com uma versao mais nova do visual C++ eh um problema serio, principalmente p/ quem precisa gerar executaveis muito pequenos e q rodem pelo menos no windows 2k.

Como o Rafael Del Rey comentou, cada versao do visual C++ se linka com uma crt diferente (msvcrtxx.dll, onde xx costuma ser a versao do visual C++) e os windows mais novos nao vem por padrao com essa crt. Compilar estatico quase dobra o tamanho do executavel e tbm tem problemas qdo sua aplicacao tem varias dlls (uma dll nao pode deletar memoria alocada por outra).

Mas existe uma maneira de linkar com a msvcrt.dll antiga mesmo usando as versoes mais novas do visual C++, o post nesse weblog explica bem como fazer isso http://kobyk.wordpress.com/2007/07/20/dynamically-linking-wi... (um dia eu ainda escrevo um tutorial em pt_BR sobre a minha experiencia com o assunto).

Mas como vc pode ver pelo post, eh um bocado de hackerish, nda natural.

[]s
rebarba rebarba
  ::::