logo
Contato | Sobre...        
rebarba rebarba

Rodrigo Strauss :: Blog

follow us in feedly

Não sou o único na contra mão do MsMarketing

Pérola que eu li em um newsgroup um dia desses: "Não sei como, nos dias de hoje, ainda existem pessoas que escrevem uma nova aplicação Windows usando Win32 ou MFC ao invés de usar Windows Forms". Como eu sei que existe uma imensa massa de programadores que definitivamente não sabem o que falam, eu resolvi não discutir. Já ouvi tantas pessoas que acreditam que qualquer coisa pode ser feita em .NET, que hoje em dia eu prefiro não discutir e continuar com o meu Visual C++.

O primeiro problema disso é a definição de conceito e o entendimento da arquitetura das coisas. Falar que não usar Windows Forms não faz sentido é completamente sem sentido, já que o Windows Forms não passa de um wrapper sobre a Win32 API. Além disso, a MFC não passa de outro wrapper para a Win32 API, só que com mais de 10 anos de mercado e MUITO mais maduro do que o Windows Forms (que ainda tem vários bugs). Eu sempre achei o Windows Forms aquém das minhas expectativas para desenvolvimento de aplicativos Win32, mas acredito que a escolha da ferramenta sempre deve ser feita com calma e pesando todos os fatores, como experiência, tempo para desenvolvimento e alcance do aplicativo. É inviável fazer um aplicativo para download em .NET, já que só a runtime dá uns 25 MBs. (Não me venha com esse papo de que isso está melhorando, que mais pessoas tem o Framework instalado, etc. A grande maioria da base instalada não tem Framework e nem sabe o que é isso).

Semana passada encontrei mais algumas pessoas que compartilham da minha opinião. A primeira é a equipe que desenvolveu o newsreader Sauce. Ele foi totalmente desenvolvido em .NET, como muitos dos leitores RSS que existem hoje. Depois de não conseguir fazer o aplicativo ficar mais rápido e consumir menos memória, eles decidiram abandonar o .NET e refazer em "old unmanaged code". A nova versão ainda está em beta, mas é bem mais rápida do que a versão .NET e consome metade da memória. Fiz algumas medições entre a versão .NET e nativa (feita em C++ Builder, Delphi ou Kylix), e como dados concretos valem mais do que c palavras, vamos a eles:

Tempo de inicialização
.NETNativo
366
252
121
165
Consumo de memória (Private Bytes)
.NETNativo
45.492 KB24.144 KB

O argumento que todos os .NETers sacam assim que são "atacados" é que a aplicação usada não foi bem escrita, que não segue os best practices de alocação de memória, não usa corretamente IDisposable, bla, bla, bla. Se é tão difícil assim fazer uma aplicação com boa performance e consumo de memória razoável em .NET, é melhor continuar usando C++. Pelo menos em C++ a regra de alocação/desalocação de memória é clara, e não depende de saber quem precisa ou não de Dispose(). Além disso, tem o argumento barato de que as máquinas vão ficar mais rápidas, que a memória vai ficar barata, que o Bush vai recobrar a sanidade algum dia e que em um futuro não muito distante todos os micros terão Framework instalado. Eu desenvolvo aplicativos hoje, para clientes de hoje, que têm máquinas de hoje. Eu acho que o Windows Forms vai ficar muito melhor no futuro (Avalon), mas não posso viver lidando com coisas em fase experimental e SOs que ainda estão em alpha. Quem já tem experiência no mercado sabe que a migração para o Longhorn - ou a instalação da runtime do Avalon em todas as máquinas - deve demorar alguns anos.

Outra pessoa que compartilha da minha opinião chama-se Mark Russinovich. Para quem vive em outro mundo e não o conhece, ele além de escrever os programas do site SysInternals é o escritor do livro Windows Internals, a bíblia sagrada da arquitetura Windows. Ele escreveu um post sobre isso, e como esperado, foi impiedosamente atacado pelo cardume de Piranhas.NET. Devido ao grande número de comentários negativos, ele explicou novamente o que já tinha explicado e as Piranhas.NET não tinham lido. Compartilho da mesma opinião: .NET é bom para componentes e maravilhoso para Web (ASP.NET é muito bom). Mas Windows Forms aumenta muito o consumo de CPU e memória sem trazer grandes vantagens (traz até alguns problemas). E wrapper por wrapper eu prefiro meu WTL. :-)


Em 23/05/2005 19:31, por Rodrigo Strauss


  
 
 
Comentários
Rodrigo Strauss | website | em 23/05/2005 | #
O livro do Petzold ( http://www.amazon.com/exec/obidos/tg/detail/-/157231995X) pode ser "antigo", mas tem tudo que você precisa. Ele é hardcore do meio pra frente (eu não tive paciência para ler a parte de toolbar), mas a base que ele te dá sobre a arquitetura da GDI é muito boa. Se você não tiver paciência, leia até o capítulo 11 (página 566). Isso já será suficiente para entender como as coisas funcionam no Windows, e será muito útil MESMO QUE VOCÊ USE Windows Forms.

Depois do Petzold, leia algo sobre MFC. Pode ser qualquer livro ( http://www.amazon.com/exec/obidos/search-handle-url/field-ke...), eu não li nenhum, mas entendendo como funciona o Win32 e a GDI, MFC não será um problema.

E depois disso leia o Advanced Windows do Jeffrey Richter ( http://www.amazon.com/exec/obidos/ASIN/1572315482). Pronto. Isso já é suficiente para você ser um bom programador Win32. Só 3 livros :-)

Não é verdade que existem mais livros sobre .NET. A API Win32 existe desde de 1993, e uma procura por livros na Amazon retornará vários livros. Procure "MFC" na Amazon, depois procure "Windows Forms" e veja a diferença. Além disso, no www.codeproject.com tem mais coisa útil em MFC do que em .NET.

Como eu disse, as duas arquiteturas são importantes. Não troque o .NET pelo Win32, aprenda os dois e use o que for melhor para cada caso.
Rodrigo Strauss | website | em 24/05/2005 | #
O C++ Builder não foi descontinuado. E realmente, ele é tão RAD quanto C#. O Visual C++ tem o editor de dialogs. Todo mundo que o vê pela primeira vez fala "nossa, isso parece VB", e foi o que eu pensei quando vi.

Não é tão difícil programar "unmanaged", principalmente com MFC. Ah, e VB6 é unmanaged e qualquer macaco treinado programa aquilo.

Eu não comecei com C++, comecei com GW-BASIC. Depois veio o Clipper, VB3/4/5/6, ASP, C e depois C++ com Win32.

Sim, quem sabe C e C++ programa em qualquer plataforma, seja Windows, UNIX, MACH, Palm, celulares, máquinas industriais, etc. A grande maioria de equipamentos programáveis que existe são programáveis em linguagem C.
Fabio Galuppo | em 25/05/2005 | #
Indiscutivelmente q C++ supera, e sempre vai superar qq codigo gerenciado.

Porém o .NET Framework tem várias coisas interessantes...

É melhor suportar o Windows Forms do que o VB :)

Uma das preocupações do pessoal da ISO C++ é tbm com relaçaõ a UI... Quem sabe no futuro teremos algo interessante neste sentido...
Rodrigo Strauss | website | em 25/05/2005 | #
Não sei se o C++ superará sempre o código gerenciado. Um dia o JIT pode tão bom quanto compilador do Visual C++, otimizando a aplicação de acordo com o computador do usuário e de acordo com o uso, algo como um PGO constante. Mas eu acredito que isso não acontecerá nos próximos 10 anos. E até lá eu tenho um monte de projetos para entregar.

Eu tenho acompanhado as discussões sobre o C++0x e sobre as preocupações do Stroustrup nesse sentido. Mas acho difícil padronizar UI no C++. Eu acharia ótimo, mas não vejo como isso seria possível.

(aos leitores: PGO = http://msdn.microsoft.com/library/default.asp?url=/library/e...)
Guima | website | em 25/05/2005 | #
Eu não concordo inteiramente com nenhum dos lados :)

Explicando, na verdade meu "ambiente nativo" é C++\Win32 e afins, é onde tenho mais conhecimento e onde gosto mais de programar.

Repetindo o que nos parece ser de consenso...
A gente nem discute mais essa de que a aplicação .NET não foi bem escrita (a mesma história do java...) os ambientes gerenciados estão níveis de abstração acima do C++, e no caso de acesso a API do SO implementam camadas em cima das APIs, então nunca terão o nível de performace\memória do C++.
Mais o objetivo dos ambientes gerenciados não é performance. O consumo a mais de mémória e processamento tende a ser desprezível com o avanço dos PCs. Mas...sempre haverá o caso onde se precisa o máximo de performance, daí entra o C++.
Eu acho sim que a produtividade no .net é bem maior que no C++, mesmo para mim bem mais acostumado com C++, e mesmo para "rotinas" no C++ onde uso STL e afins.

Além disso questão de segurança tem sido um grande problema no pé da Microsoft a muito tempo, em grande parte porquê ela constrói o SO e os aplicativos com grandes possibilidades de customização, APIs, liberdades que são bem exploradas para fazer aplicativos, MAIS também exploradas pro lado ruim e o pessoal se esquece dos benefícios !! ?? da flexibilidade da plataforma. Daí já começamos a cair noutra discussão :) ...

Para finalizar , eu penso que a Microsoft tem de fazer uma certa pressão no sentido da adoção da nova plataforma, pois tem de vencer uma certa inércia dos desenvolvedores (vide absurdo da petição dos "MVPS" de VB) e do mercado, além do que a chegada da nova plataforma de SO se aproxima, e muitas APIS serão acessíveis somente em anbiente gerenciado.
Rodrigo Strauss | website | em 25/05/2005 | #
Eu não tenho como garantir que essa aplicação foi mal escrita. Eu já trabalhei com .NET e já tive os mesmos problemas, mesmo com aplicações relativamente simples. Pode ser esse o motivo, mas não é impossível que seja só problema da runtime. Se for assim, eu nunca vi uma aplicação .NET bem escrita, porque todas consomem muita memória e demoram para inicializar. O Mark mesmo disse que o console de gerenciamento do SQL 2005 consome 80 MBs de RAM logo que abre, sem nenhuma query.

O objetivo das runtimes gerenciadas não é performance, mas mesmo assim a performace delas deve ser ao menos aceitável, senão não há razão de existir. Quanto ao avanços do PC, eu não posso esperar isso acontecer. Nem a Intel nem a AMD está conseguindo passar a barreira dos 4 GHz, e um processador multicore/hyperthread não vai ajudar nada aplicativos singlethreaded. Para .NET, um multicore vai significar um garbage collector em outro processador, o que não vai ajudar muito.

Eu não acho a produtividade com .NET maior do que C++. Eu faço componentes para servidor e não conheço nada que me daria mais produtividade do que STL. Nenhuma coleção do Framework chega aos pés da STL em eficiência e produtividade. Sem STL eu demoraria o dobro do tempo para fazer o que eu faço.

Sim, o problema da segurança é uma boa justificativa para runtims gerenciadas. Mas, como você mesmo disse, já é outra discussão. :-)
Guima | website | e-mail | em 27/05/2005 | #
Analogamente ao que estamos começando a vivenciar essa discussão pode disparar várias threads em cores separados :) ...

"Nem a Intel nem a AMD está conseguindo passar a barreira dos 4 GHz, e um processador multicore/hyperthread não vai ajudar nada aplicativos singlethreaded"
A AMD já tem o X2 a um índice de 4800+, whatever, vc tem razão, mesmo que suba para 5000+ ou um pouco mais o ritmo de aumento do clock está ficando muito baixo. Os multicore vão ajudar a tornar a resposta do sistema muito mais suave, mais há atividades de carácter seqüencial que dificilmente tiram proveito do paralelismo.
Mais nem tudo está no processamento bruto: a memória vai ficando mais rápida e mais abundante, e isso está acontecendo num ritmo muito rápido, sinceramente hoje em dia eu me preocupo muito menos com o consumo de memória do que a pouco tempo atrás, no sentido de aceitar bem melhor aplicações de ambiente gerenciado.

"É inviável fazer um aplicativo para download em .NET, já que só a runtime dá uns 25 MBs"
Eu particularmente, com 1GB de memória ou mesmo antes com 521KB, o fato de o aplicativo gastar 20MB a mais de memória não seria um fator crucial para escolha da versão managed ou não. Em relação a supor framework instalado, concordo plenamente que isso não é verdade, uma parcela bem pequena dos desenvolvedores! se enquadram nesse caso.
Talvez um dos meus problemas seja ver de forma muito negativa programadores C/C++ escrevendo código a um nível mais baixo do que considero correto com a justificativa de performance e consumo de memória, e gerando projetos que vão para o lixo em parte devido a esse approach. Não estou dizendo que é o seu caso e creio que não seja, mais vejo esse extremo de forma muito negativa e muito constante no meu dia-dia. Estou escrevendo um texto sobre isso em breve vou colocar no meu site...posso ser malhado por isso mais é a vida :)

"Eu não acho a produtividade com .NET maior do que C++."
Em parte essa medida tem influência de fatores/skills pessoais. Mais posso relatar o meu caso, com os conteiners no .NET me preocupo menos com o gerenciamento de memória e detalhes de mais baixo nível, escrevo menos código, portando um código STL para containers com um mapeamento quase direto percebi uma pequena diferença de produtividade. No caso de utilização do STL é onde eu acho que as diferenças ficam menores, mas... no fundo acho que concordamos nesse ponto muito mais do que discordamos. IMHO a falta de "consciência" da existência do STL e outras bibliotecas, e da sua boa utilização para mim é uma das grandes causas de fracasso de projetos em C++, ou de grande perda de produtividade com a linguagem.

Rodrigo Strauss | website | em 27/05/2005 | #
A numeração dos processadores AMD não é correspondente à velocidade em Mhz. O X2 4800+ roda a parcos 2.4Ghz ( http://hardware.gamespot.com/AMD-Athlon-64-2.4GHz-X2-4800+-1...).

O grande problema do consumo de memória é que ele prejudica bastante o desempenho. Mais memória ocupada significa mais page faults, e acesso ao disco ainda é algo muito lento. Fora que quanto mais memória ocupada, mais trabalho para o Memory Manager.
Além disso tem a comparação. O Excel com uma planilha mediana (+- 6 pastas com +-40x40) ocupa menos memória do que um Form Windows.Forms com um DataGrid vazio.

Eu também vejo de forma MUITO NEGATIVA quem usa low-level a toda hora, eu falo isso para os meus alunos (dou aulas de C++) sempre. Eu já escrevi alguns posts falando disso:

http://www.1bit.com.br/content.1bit/weblog/more_cpp_libs
http://www.1bit.com.br/content.1bit/weblog/cpp_sanidade_atl_...
http://www.1bit.com.br/content.1bit/weblog/cpp_sanidade_2
http://www.1bit.com.br/content.1bit/weblog/otmizacao_pessimi...

Sim, essa parte de produtividade conta skills. Eu me preocupo pouco com gerenciamento de memória usando STL e C++ em geral (não estou contando Win32). Quase não uso ponteiros com STL. E quando uso, nada que um boost::shared_ptr não resolva. Essa história de manipular memória é coisa do passado, o próprio Stroustup fala disso no "C++ Programming Language".

Nada que exista no .NET chega perto da flexibilidade e algoritmos do STL. Se colocarmos Boost (www.boost.org) na equação os containers .NET parecem brincadeiras de criança mal feitas.

Sim, incompetência é o principal motivo de fracassos de projetos. Seja em C++ (mal uso, desconhecimento da STL, etc) ou em qualquer coisa. Não podemos (eu sei que você não disse isso) culpar a linguagem pela incompetência dos programadores.
Guima | website | em 27/05/2005 | #
A numeração no AMD não corresponde mesmo a velocidade, porisso chamei de índice, mais no sentido do desempenho dá no mesmo, pois o Intel teria de operar a essa freqüência. Os ainda parcos 2.4Ghz é um dos fatores que colocam a AMD hoje em grande vantagem em relação a Intel (Intel lovers que me perdoem :)), a AMD tem uma arquitetura diferente e ainda tem espaço para aumentar o clock, veja a comparação de consumo hoje entre as versões Dual core da Intel e AMD, o Pentium D consome entre 214 a 315 Watts (carga mínima e máxima), já o AMD consome entre 123 a 185 Watts ! Isso sem falar no desempenho...ops..TerminateThread :)

A questão da memória eu não diria bem que é memória ocupada incorre em page faults, mais sim falta de memória livre. Se os processos puderem ser mantidos com 100% de working set não haverá problema. A diferença de equacionar dessa forma é que fica mais evidente que mesmo com muita memória ocupada o desempenho não vai cair se ainda houver memória livre (ou seja tendo muita memória no final das contas).

Sobre o assunto da produtividade da linguagem eu acho que falta só um ingrediente na sua equação :) Vou explicar, vamos lá, eu comecei a programar com C\C++ faz quase 10 anos, claro que não fiz só isso o tempo todo. Mais pegando um livro como "C++ Faqs" "Faq" não deve ser coisa tão complexa não ? :) algumas coisas lá não são tão triviais para mim (este Faq está em versão menor na Web). Talvez eu tenha levado o "primeiro ano" inteiro de C++ para entender realmente por completo tudo que envolve ponteiros em C. Talvez mais um ano para entender todo o BÁSICO que envolve classes e orientação a objeto. Tem muita coisa que eu ainda não sei. E por aí vai...com certeza você já entendeu aonde quero chegar. Talvez o cara fluente em C++ que faça a função tal em STL num tempo X tenha estudado/trabalhado 5 anos com C++, e o cara fluente em .NET faz o trabalho no mesmo tempo X mais estudou 1 ano ! Não dá pra comparar a curva de aprendizado. Não é a toa que C++ é A linguagem para missão crítica. Mais nem sempre precisamos de tanto poder.

{}s
Rodrigo Strauss | website | em 27/05/2005 | #
Sim, vc chamou de índice, tem razão. Mas dessa vez eles forçaram um pouco, colocar 4800 em um processador 2.4 só pq ele doublecore. Isso não dá a performance de um 4.8 GHz nem a pau. Mas eu concordo com você que a AMD está dando um banho, e prova disso é a adoção pela Intel da arquitetura x64. Essa do consumo de energia eu não sabia. As discussões que tem rolado nos posts andam ficando tão boas que eu estou pensando em fazer uma estrutura mais de fórum nos comentários, para facilitar a nossa vida.

Concordo com você que para ser produtivo em C++ leva bem mais tempo e mais dedicação. Mas a recompensa compensa :-)

Ultimamente eu tenho estudado MUITO C++, estou lendo o "C++ Programming Language", e comprei o "Exceptional C++" (já li, é maravilhoso), "More Exceptional C++" e o "Modern C++ Design". Cheguei a conclusão que é a única coisa que não passa, não é moda. É uma linguagem sólida, elegante e respeitada em qualquer lugar, seja no mercado ou no meio acadêmico.

Esse estudo está sendo muito compensador, pois minha produtividade aumentou muito. Dominar STL não é fácil, ainda quero aprender mais, mas a velocidade que eu tenho resolvido problemas ultimamente tem me espantado. Fiz um pequeno framework para monitoramento de servidores COM+, com medição de tempo de resposta e roteamento de mensagens para o melhor servidor. Todo baseado em STL, boa performance aliada à um código simples e claro. Reusabilidade 100 e produtividade 100. O problema (se é que posso chamar assim) é que para chegar nesse estágio é necessário estudo 200 :-)

O grande fato é: alguém experiente em .NET nunca vai conseguir fazer algo tão bom quanto alguém experiente em C++ (não entro no mérito de se é necessário 10 anos para ser experiente em C++). Em C++ a única limitação é o programador, e não a linguagem. Você pode ir até onde você quiser, a linguagem permite. Eu comecei a programar C++ quando bati nas limitações do VB. Nas linguagens mais limitadas é simples fazer coisas simples, mas as coisas complicadas precisam de milhares de gambiarras, tunnings e iterops.
Guima | website | em 27/05/2005 | #
"As discussões que tem rolado nos posts andam ficando tão boas que eu estou pensando em fazer uma estrutura mais de fórum nos comentários, para facilitar a nossa vida."

Isso seria muito interessante :)
Eu particularmente gosto muito de visitar fóruns. Aprendo e me divirto com eles. Quase todos os dias fico com um browser aberto no lounge do codeproject. Não é exatamente um fórum técnico pois posts sobre programação não são permitidos, mais como todos lá são programadores aparecem assuntos gerais da área interessantes e engraçados. As vezes dou uma browseada no fórum de VC... já os artigos são de lei pelo menos ver tudo que aparece.

Tb acho um pouco de exagero 4800+. Olhando essa página na anandtech...
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2410
dá pra ver que as diferenças de índice estão apoiadas também no aumento de cache. Mais a fórmula não é tão direta, em muitos tipos de aplicações o processador fica mais lento com mais cache pois quanto maior aumenta a latência e pode até piorar o desempenho.
Nessa outra página confirma o que você comentou o 4800+ tomando coro em aplicações single, mesmo tendo "índice" maior.
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2410&p=3

Ah, ainda sobre o fórum, com a mudança no msdnbrasil para o formato de fórum padrão da MS acho que aquele lado com cara de "comunidade" do fórum se perdeu e ficamos na roça :(

{}s
Thiago | website | e-mail | em 06/06/2005 | #
Está boa a discussão mesmo.. :)

Sobre as interfaces...
Estou fazendo minha própria API de interface gráfica de tão cansado da antiga MFC e por achar que é possível criar classes muitos mais limpas e melhor projetadas.

Acredito que posso levar meio ano, para ter algo estável e não muito sofisticado, no entando neste trabalho de meio ano somente uma pequena parte vai ter relação com o sistema operacional e isso me deixa tranquilo no sentido de não estar jogando trabalho fora.

Estou compilando no pocket e no windows, futuramente com o auxílio de um amigo o César Mello ( http://mello.sentinelas.org/mello/) pretendo portar para linux e seria interessante alguma outra plataforma.

Este amigo também está desenvolvento(e no momento remodelando) um framework para desenvolver aplicativos multiplataforma.

No momento, meu objetivo com isso não é desenvolver aplicativos comerciais. Na prática, no dia-a-dia, ainda uso MFC para desenvolver interfaces. Apesar de antiquada é o que existe para visual c++, e o resultado final não fica tão ruim.

Já utilizei o C++ builder. É muito mais limpo, muito mais claro e fácil de utilizar. Mas tem um erro muito grave na minha opnião que é depender de detalhes específicos do compilador da borland. Por exemplo os closures que são os "delegates" do .NET que a borland já tinha a um bom tempo.
A biblioteca de interface grafica em c++ deve ser escrita em c++ padrão na minha opnião.

Não acho produtivo usar a win32 direto.

E sobre o windows forms fiz algums testes no c# e rodei no pocket. Até que não ficou ruim!
Até suei para conseguir a performance dos desenhos igual ao aplicativo feito em c#. Pois na verdade ele só está chamando as classes do windows que são otimizadas e criadas em c/c++ :). Mas o programa em c++ abre instantâneamente e o em .net demora. Assim como o consumo de memória é bem abaixo. Se tivesse mais tempo eu colova um números aqui.. quem sabe um dia :)

Se com o c++/cli for possível criar interfaces acho que é boa opção considerar a simplicidade de criar a interface em .net. E fazer o programa normalmente em c++ nativo.
Rodrigo Strauss | website | em 06/06/2005 | #
Acho que você já deve ter tentado o WTL... Eu gosto bastante, mas eu perdi meu preconceito contra MFC. Quero a interface gráfica feita rapidamente, prefiro gastar meu tempo com backend e coisas mais interessantes. :-)

Por que você não coloca seu framework no SourceForge? Seria interessante ter feedback.

Sim, será possível usar o C++/CLI para fazer qualquer coisa em .NET, inclusive Windows Forms (já possível com o Managed C++ atual) e Avalon.
Thiago | em 06/06/2005 | #
Não vou usar a WTL pois quero uma solução portável. (Mas não tenho nada contra WTL)

Eu não perdi o preconceito contra MFC. Pelo contrário cada dia que aprendo mais sobre c++, mais aumenta o meu preconceito! :)

Inclusive eu acho que a MFC estraga programadores novos, pois se basearem no estilo como ela é feita.

A interface é a casca do programa. O recheio deve ser feito em c++ padrão. Então na minha opnião é que mesmo que se use MFC para a interface pelo menos não usar o CArray o CMap etc, mas usar STL. (O CString é um caso a parte )
Mesmo sendo a casca, dá uma prazer enorme você pegar um código de interface compilar e rodar direto em outra plataforma.

O VC 2003 tem um wizard de projeto para pocket e C#.
Não sei se o VC 2005 tem algo semelhante para C++/CLI. O 2003 não tinha. Para aplicativos windows eu já vi que tem.

Já viram que programas de microsoft são feitos usando MFC?
As vezes eu dou uma passadinha do SPY sobre algums programas. Tinha visto que o word/excel não usava classes da MFC.
Também quero ver se um dia o office vai ser feito com windows forms.

Mesmo que as máquinas sejam mais rápidas um aplicativo feito em windows forms vai ter que competir com um similar feito em c++ nativo.. ai é que complica para aplicativos sérios.

O projeto do meu amigo está no SourceForge se chama LightForms.
O meu ainda está na experimentação.

PS: Ainda bem que tem o teste para informar o nome :)


Cesar Mello | website | em 06/06/2005 | #
Muito boas as discussões aqui.

Eu sou o amigo do Thiago, nós trabalhamos juntos. A página do meu projeto é http://lightforms.sf.net , mas o código disponível lá é da versão "estagnada" do projeto, que não é melhorada desde julho do ano passado... Enfim, como agora também considero o Windows CE uma plataforma prioritária, resolvi começar o projeto praticamente do zero... Em breve vou atualizar o site e o CVS com o código novo.

Acho que através de programação em C++ limpa, simples e organizada, sem amarras com o passado, é possível fazer softwares de qualidade excepcional, com esforço menor do que temos presenciado... Vamos ver.
Rodrigo Strauss | website | em 07/06/2005 | #
Não sei exatamente qual a definição de vocês para portável, mas o WTL também funciona em Windows CE. Se o portável precisa ser como o lightforms, que suporta Linux, o WTL realmente não resolve.

Além disso, vocês já viram o wxWidgets ( http://www.wxwindows.org/)? Ele é multiplataforma e é bem falado. Além dele, há a possibilidade de usar o XUL do Mozilla, que nada mais é do que frontend em XML+JavaScript. E o backend é feito em C++ (XPCOM, cópia do COM da Microsoft). O Firefox é feito desse jeito.

Sim, eu também acredito bastante no potencial do C++ moderno para fazer software de qualidade e com produtividade. Como eu já disse aqui em algum lugar, STL + "best practices" permitem uma produtividade muito grande.
Thiago | em 14/06/2005 | #
Discussão sobre interface gráfica para c++
http://groups-beta.google.com/group/comp.lang.c++.moderated/...
Wagner Amorim | e-mail | em 09/08/2005 | #
Olá Rodrigo, aproveitando a discussão sobre WTL que até então eu desconhecia, gostaria de lhe pedir pelo amor de Deus para que você ou qualquer outra pessoa que saiba, para que me dê uma Luz de como eu faço para ler um arquivo WTL no asp, como por exemplo o site http://www.infoinvest.com.br/modulos/arquivo_ITR.asp?arquivo...

MUITO OBRIGADO, Já estou enlouquecendo com essa solução.

Abraços!
Rodrigo Strauss | website | em 09/08/2005 | #
Acho que você confundiu as coisas. O WTL que eu estou falando é esse:

http://sourceforge.net/projects/wtl/

Isso é um biblioteca para programação em C++ e não tem nada a ver com esse link que você passou
Wagner Amorim | e-mail | em 09/08/2005 | #
Olá Rodrigo!
Então cara, esse WTL que tô falando é esse desenvolvido em C++ mesmo... Mas de alguma forma existe como eu interagir esse código wtl e ler no ASP...

Mas blz, Muito Obrigado!
Rodrigo Morais R. Avila | e-mail | em 16/03/2006 | #
Olá Rodrigo, lendo o FAQ do Stroustrup em http://public.research.att.com/~bs/bs_faq.html#gui ele cita um GUI, o SmartWin++ que, em princípio, achei interessante ( http://smartwin.sourceforge.net/). Você conhece esse GUI? Tem alguma opinião sobre ele?
Obrigado.
Rodrigo Strauss | website | em 16/03/2006 | #
Já li sobre ele, e parece conceitualmente muito bom. Mas não posso dar uma opinião já que nunca usei.
Maleb França | em 13/09/2007 | #
Olha Rodrigo realmente MFC é superior a Windows Forms, mas a que custo? MFC é difícil, obscura e da a sensação q o programador não programa C++, programa MFC.

O VC6 é um exemplo da falta de flexibilidade apesar da alta capacidade (talvez inigualável). Acho q vc foi radical demais na defesa da MFC. Desenvolver aplicativos não é só escolher a mais rápida ou a mais isso ou aquilo... Se fosse assim todo mundo só usava Assembly.

A questão é: MFC é fácil? Não. Sintaxe é simples? Poderia melhorar muito mesmo... Pessoalmente prefiro me enveredar na Win32 do q por MFC em muitos casos (não em todos). Pelo menos eu sei de cada linha presente alí.

Quero dizer que Windows Forms é sim o futuro pra C++, sim não pq seja melhor, mas pq é mais fácil e possivelmente mais produtiva. O mundo é assim. C++ sempre foi melhor do q Java em 99% dos casos (opinião pessoal), mas quem está vencendo agora? (apesar q aposto em C++ no futuro).

O problema no fundo está que para C++ não há uma ferramenta ideal para o desenvolvimento, que combine ao mesmo tempo o poder pleno da C++ em ternos de performance com a praticidade produtiva de Delphi e VB.

Ah... se o C++Builder fosse a solução definitiva...
Rodrigo Strauss | website | em 14/09/2007 | #
Note que eu não disse que a "MFC é superior ao Windows Forms". E não acho que eu tenha defendido a MFC tão exageradamente como você falou, mas se foi essa sua impressão, sem problemas. Eu realmente prefiro usar MFC do que usar WinForms.

Eu conheci MFC quando ainda programava em VB, e achei fácil naquela época. MFC não usa o chamado "C++ moderno", mas essa é justamente a parte complicada do C++.

Sobre Assembly e coisas assim, eu já falei sobre "usar a ferramenta certa para o problemas certa" milhares de vezes nesse site - nesse post inclusive, http://www.1bit.com.br/weblog/ms_marketing#320.

Eu não tenho problemas com a MFC, prefiro usar Win32 puro só quando necessário.

Você falou sobre "quem está vencendo agora", não sei sobre qual definição de vencedor que você está falando. O Java ser mais usado do que C++ (ele é?) não o torna vencendor, só prova que existem mais projetos adequados para serem feitos em Java (componentes, sites, acesso a banco de dados) do que projetos adequados para C++. Não se esqueça que a única linguagens de programação presente em TODOS os dispositivos com microprocessador é a linguagem C, seguida de perto pelo C++.

Não acredito que WinForms seja o futuro, e a Microsoft também não acredita. Veja o WPF.

Concordo que poderia existir ferramentas melhores para C++. Mas softwares continuam sendo feitos com C++ (Windows, Linux, Photoshop, Office, SQL, Oracle, DB2, MySQL, Corel, etc, etc) mesmo sem isso. É demais falar que "não existe ferramenta ideal".
Maleb França | e-mail | em 30/07/2008 | #
Bom essa questão de vencedor é relativa, de fato. O único ponto que quis ressaltar é que existem outros pontos na escolha da ferramenta além da perfomance.

Eu não disse q Windows Forms era o ÚNICO futuro da programação em C++ pra Windows. Assim como, C# não aposentou C++ na programação pra Windows. Há lugar pra todos, mas há tendências baseadas em certos aspectos, que vão além da performance.

Java atualmente é a mais usada segundo o ranking Tiobe. http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
(Eu não concordo em diferenciar C++ de C, não por motivos técnicos).
Java tem, segundo o ranking Tiobe, o dobro de programadores de C++, mesmo tendo menos performance, mesmo tendo menos tempo de mercado do q a C++, dentre inúmeras outras desvantagens. Mas pq Java atrai o dobro de programadores de C++? O que faz um projeto ser "adequado" seria a performance somente?

"só prova que existem mais projetos adequados para serem feitos em Java"
>>>> Afirmação interessante. E qual seria a causa? Seria só por Componentes, Sites(???) e acesso a Banco de Dados?

Não existe ferramenta ideal em C++. Cada ambiente possui suas particularidades e desvantagens. Tb dá pra fazer quase tudo na plataforma Windows com um compilador Win32 compatível e em linha de comando, isso torna o DevC++/MinGW a melhor solução?

Mas nesse aspecto os compiladores C++ avançaram muito nos últimos anos. Estão mais amigáveis ao programador do q nunca.

"Não se esqueça que a única linguagens de programação presente em TODOS os dispositivos com microprocessador é a linguagem C, seguida de perto pelo C++."
>>>>> E daí??? Isso torna C ou C++ melhor em que? Quer dizer q agora só se vai usar C++ por causa do processador???
Algo a dizer?
Nome:


Site:


E-mail:


Escreva o número vinte e seis:


 Não mostre meu e-mail no site, não serve pra nada mesmo...

Comentário





Os comentários devem ser sobre assuntos relativos ao post, eu provavelmente apagarei comentários totalmente offtopic. Se quiser me enviar uma mensagem, use o formulário de contato. E não esqueça: isso é um site pessoal e eu me reservo o direito de apagar qualquer comentário ofensivo ou inapropriado.
rebarba rebarba
  ::::