C++

Rapaz, acho que você está amis do que pronto pra cair pra cima do C++!

O que mais vai pegar pra você agora é a Orientação à Objetos, mas se você já tem esses conceitos do Java, vai ser mais fácil para você.

Acho que a linguagem mais difícil de se aprender é a primeira. A segunda é só um pouco difícil. Com o passar do tempo, cada nova linguagem se torna mais fácil.

IMHO, aprender C++ já sabendo C é meio traiçoeiro, porquê a pessoa é tentada a continuar usando o estilo do C em vez dos do C++. Por exemplo:

• Usar char* em vez de string
• Alocar memória usando malloc
• Usar i/o do C em vez da iostream
• Declaram todas as variáveis no topo da função, em vez de declará-las apenas quando forem necessárias

Etc.

Mas, como você já é um programador Java, se sentirá em casa com C++. Apenas pegue um livro que ensine realmente C++ e mantenha distância de livros de C++ que começam a ensinar C e depois C++. Um bom livro que entra direto no C++ é o livro do Deitel.

Use e abuse da STL. E se fores usar o Visual C++ sem se preocupar com portabilidade, use CString no lugar da string da STL e dê uma boa lida na ATL. Praticamente tudo da ATL tem gerenciamento automático de memória e as funções da Microsoft agora têm checagem de memory leaks (todas as terminadas em _s, como strcpy_s, memcpy_s, …).

Nossa, chega a me confortar ouvir isso.
O único problema comigo em C são ponteiros, porém gosto bastante desse lado da programação próxima ao hardware. Eu gostei bastante de OO, então juntando os dois, achei C++. Nas férias da faculdade vou começar a pegar sério em C++.

Declarar char*, char[] e coisarada pra mim é um horror, porque sempre me perco. Em alocar memória também para um determinado array… enfim… ainda preciso praticar muito essa linguagem C. Tenho um projeto, que espero passar para C++ ou C nas férias. Acho que C++ é mais provável, porque C está osso pra mim.

Sobre o compilador, não sei qual vou usar ainda, mas provavelmente algum da GNU, pois uso Linux (G++).

Abraço e obrigado pelas respostas

Faço minhas as palavras do LastClick.

Especialmente no que diz respeito a usar o estilo do C++. Programar C++ sem a STL é como querer programar Java usando sem usar a API. Uma perda de tempo, esforço e uma burrice completa. Além disso, abusar de ponteiros, usar defines no lugar de const, macros no lugar de inline, códigos de retorno no lugar de exceptions, são outros exemplos dessa falta de estilo. E isso só complica a vida. O C++ não inseriu esses mecanismos melhores à toa.

Esses tempos atrás, coloquei um roadmap de livros sobre C++ aqui no GUJ, creio que ele possa te ajudar:
http://www.guj.com.br/posts/list/2238.java

No meu blog (que está na minha assinatura), tem um tutorial sobre como instalar do MinGW (compilador GNU para Windows) e o Code::Blocks (IDE baseada em wxwidgets, com versões para diversos SOs). Eu sugiro que você confira especialmente o Code::Blocks.

Eu tenho uma cisma com CStrings (MFC) que vem de longe. Se puder, saiba o que é uma CString (se precisar de manter um código que usa CStrings), mas não use em código novo; prefira a STL, que, entre outras vantagens, permite que seu código funcione tanto em Windows quanto em Linux/Unix.

É que já tive de resolver uns problemas de vazamento de memória insidiosos que advinham do uso do método CString::GetBuffer; isso me vacinou um pouco contra as CStrings.

Procure usar a std::string da STL; ela é como se fosse uma mistura de String e StringBuilder (ou seja, tem a versatilidade da String e os recursos de concatenação da StringBuilder).

O problema é que ela não tem aquelas comodidades da CString de formatação (como o String.format do Java 5.0).

Mas isso se resolve com facilidade usando <strstream> ou então criando uma função que aceite uma std::string e processe usando a velha e boa sprintf (estou usando _vsnprintf, que é uma versão “segura” da sprintf, abaixo). Exemplo de um código que funciona muito bem comigo:

...
#include <string>
#include <iostream>
using namespace std;
...
class Util {
    static string format (const char * fmt, ...);
};
...
/**
 * Rotina utilitária, que se comporta como se fosse a java.lang.String.format do Java.
 * @param fmt O formato, em estilo printf.
 * @param args Os argumentos, em estilo printf.
 * @return Uma std::string (tamanho máximo: 2048 caracteres) formatada por sprintf.
 */
string Util::format(const char * fmt, ...)
{
    const int BUFSIZE = 2048;
    char buf [BUFSIZE];
    va_list arglist;
    va_start (arglist, fmt);
    ::_vsnprintf (buf, BUFSIZE, fmt, arglist);
    va_end (arglist);
    return buf;
}
...
// Exemplo de uso
cout << Util::format ("Hello, world! %d + %d = %d", 2, 2, 2+2) << endl;
...

Use sempre o pacote doxygen para documentar seus programas (você pode usar quase que as mesmas tags do javadoc
para criar páginas com diagramas UML que são mais sofisticadas que as criadas pelo javadoc. Para mais informações:
http://www.doxygen.org )

Aqui tivemos não só problemas de memória com CString como também percebemos o seguinte:

• Ela é menos segura do que a classe std::string. Menos verificações nos parâmetros são feitas;
• Se você pensa que ela abriu mão de segurança por performance (como fez a STL), se enganou. Ela é mais lenta do que o std::string. Nosso código conseguia processar 2mb/s de texto com CString e, ao modificar para std::string, o mesmo código, rodando na mesma máquina passou a processar mais de 10 mb/s;

Se não me engano, é porque a CString contém um lock também. A std::string não tem nenhum lock.
O problema desse lock é que, diferentemente do Java, o compilador não consegue remover esse lock sozinho, e esse lock não é algo da biblioteca do C++ mas sim do próprio Windows - como vocês devem se lembrar, usar um StringBuffer em vez de um StringBuilder só não é muito mais lento em Java (apesar de ter acesso sincronizado), porque o JIT Compiler (HotSpot) consegue eliminar o lock se conseguir determinar que o objeto é usado por apenas uma thread.

Thingol e ViniGodoy: Só para alinharmos, poderiam me informar a versão do Visual Studio que estão usando e se está com algum service pack?

Aqui trabalhamos com muitos programas em c++ de processamento de arquivos, servidores tcp, udp e web services.

Então, é de meu interesse saber mais sobre esses problemas. Não temos problemas como os relatados por vocês, mas, não quer dizer que não existam.

Aqui usamos Visual Studio 2005 com o SP1 aplicado. Os servidores são Windows 2003 EE x64.

Galera, agradeço mesmo as respostas de todos.
Me clarearam muito a mente… muita gente me falou que para saber C++ é preciso saber C do avesso e pelo que vejo, me falaram muita m*****.

Muito obrigado mesmo!

Aqui na Siemens: meus colegas usam Visual Studio 2005 Service Pack 1. Eu trabalho somente com java (espero entrar em projetos C++ no futuro, mas ainda não pintou nenhum).

Em meus projetos pessoais e da pós: Uso o MinGW 5.1.3, GDB 5.2.1, com a última nightly build do Code::Blocks.

Ah…certo…valeu, Godoy. Não conhecia esse MingW, só o Dev-C++ (que não deixa de ser também o GCC), além do VC2005.

dedejava:
Estudei por esse livro aqui:

Novo é meio caro, mas, tem usado começando em US$ 38,00.

Dê uma lida nas reviews. Eu li e recomendo, mas, acho que alguém já experiente pode achar o livro muito detalhista.

Alguém recomendou também o Accelerated C++: Practical Programming by Andrew Koenig, mas, é bom ver se é para iniciante ou para alguém já experiente.

E uns conselhos bons retirados dos comentários:

Some helpful tips for those who just started learning C++.

1. Keep in mind that C++ is a very hard and tough programming language to master.

C++ is arguably the most complicated programming language available today. It is by no mean THE perfect programming language, and it requires the tremendous amount of responsibilities from the programmer. However, no other language is as powerful, versatile, and flexible as C++. It gives the programmers the assembly-language-like freedom with the data types and the memory management. It offers the programmers the characteristics of both the high-level language and low-level language. It also provides the programmers both the efficient structure-oriented features and the strong object-oriented features at the same time.

2. C++ is not C, although C++ is derived from C language.

Although C++ is derived from C and inherited many features from C, C++ is NOT C. They are totally two different and separate languages just as Java is not C++. C is a structure-oriented language while C++ is object-oriented language. C++ has many new features that C can’t even begin to dream about. Give C++ all due respect.

3. The perfect C++ textbook does not exist, so stop trying to find one.

Muito pertinentes os conselhos…

O DevCpp também usa o MinGW como compilador no Windows. Eu acho ele uma IDE muitíssimo limitada. O debbuger não roda direito, a identação não funciona, fora que há anos ninguém faz um update.

O Code::Blocks é indiscutivemente muitíssimo superior e também free. Há instruções de como instala-lo no meu blog (foi o último artigo que postei). O Code::Blocks, por ser implementado sobre a wxWidgets, também tem versões para Linux e Mac. A versão oficial é antiga, mas as nightly builds são muito estáveis e sai praticamente uma por dia. O uso da nightly é recomendado no próprio site oficial. A comunidade desenvolvedora está muito ativa e, se você postar um bug por lá, terá a resposta em poucos dias (eu mesmo já fiz isso).

E para arrebatar de vez, ele também suporta os devpacks, para configuração automática.

Agora me lembrei que o CString foi reimplementado no Visual Studio 2003 como sendo um template (CString = CStringT<char> ou CStringT<wchar_t> dependendo das opções de compilação, se ANSI ou Unicode); estou lendo o fonte do CString e depois lhe digo se tem ou não o lock. Eu tinha lido o fonte do CString do Visual Studio 6.0 e poderia lhe afirmar que o tal lock existe. Mas essa versão está deveras complicada pro meu gosto.

thingol:

Agora me lembrei que o CString foi reimplementado no Visual Studio 2003 como sendo um template (CString = CStringT<char> ou CStringT<wchar_t> dependendo das opções de compilação, se ANSI ou Unicode); estou lendo o fonte do CString e depois lhe digo se tem ou não o lock. Eu tinha lido o fonte do CString do Visual Studio 6.0 e poderia lhe afirmar que o tal lock existe. Mas essa versão está deveras complicada pro meu gosto.

Thingol, eu só uso o CString do VS2005, que é o da ATL. Segundo as lendas (não achei o link), o CString da MFC, na MFC 8.0 é o mesmo da ATL, que é totalmente diferente na implementação do CString das MFCs anteriores.

Talvez por isso eu não tenha visto esses problemas que vocês mencionaram.

Pessoal… só pra esclarecer uma coisa…

Hoje em dia, tem trabalho para programador em C++? Digo… tenho muitas dúvidas sobre C++, pensei em começar a usá-lo, mas fiquei cabreiro… porque, sei que a maioria dos programas grandes (Corel, Adobe e etc…) são feitos por C++. E só se vê C++ em visual studio e tals…

É só ele que presta pra fazer sistema “visual” pra windows?

Os outros que vi… pra criar uma tela… tinha que digitar quase umas 30 linhas… a praticidade foi pro saco… :roll:

[]s

titanius:

Pessoal… só pra esclarecer uma coisa…

Hoje em dia, tem trabalho para programador em C++? Digo… tenho muitas dúvidas sobre C++, pensei em começar a usá-lo, mas fiquei cabreiro… porque, sei que a maioria dos programas grandes (Corel, Adobe e etc…) são feitos por C++. E só se vê C++ em visual studio e tals…

É só ele que presta pra fazer sistema “visual” pra windows?

Os outros que vi… pra criar uma tela… tinha que digitar quase umas 30 linhas… a praticidade foi pro saco… :roll:

[]s

basicamente é assim: se envolve computação gráfica é c++. Contudo, o mercado do Brasil é na imensa maioria para aplicações de banco de dados, onde o Java é mais forte.

Certo, mas aplicações feitas em C++, tendem a ser mais robusta, ou não?

[]s

Não necessariamente. Um programa é tão bom quanto o cara que o programou. Não é a linguagem que vai tornar um programa melhor ou pior - ela é apenas uma ferramenta. Um programa ruim pode ser feito em qualquer linguagem: Java com todos os frameworks do mundo, Ruby on Rails, Python, Smalltalk, Assembly Z80, etc.

Já vi provisionadores de comandos para telecoms feitos em TCL pela Ericsson!

Já vi tarifadores de pré-pago feitos em Java com Sybase…

E C++ tem essa fama de ser mais robusta porquê, no senso comum, é linguagem de “Cabra Macho da peste”. Mas, particularmente, acho que é porquê ela é difícil de aprender, e isso acaba afastando os programadores aventureiros e exigindo mais estudo e preparação para começar um programa. Diferente de, por exemplo, Visual Basic, onde qualquer um com um cursinho já saía vendendo softwares para os comerciantes do bairro.

Na indústria, sobretudo de tecnologia, há muito espaço para o C++. Esse mês mesmo, procuramos mais de 4 profissionais que conheçam C++. No meu setor, há mais de 30 colegas empregados para trabalhar nessa linguagem.

Também concordo com o tudo o que o LastClick falou a respeito do resto.

Meu chefe diz que “não existe programador júnior em C++”. Ou é sênior, ou então não presta. Se é para fazer *** use alguma outra linguagem, que provoca menos danos.

Certo, mas aplicações feitas em C++, tendem a ser mais robusta, ou não?

[]s

Para banco de dados não, mas em computação gráfica sim.

C++ é legal para fazer coisas pequenas que devem executar muito rápido ou que devem fazer algumas coisas milagrosas ou que não se consegue fazer só com Java, mas não para fazer coisas muito grandes.

Por exemplo: fazer uma DLL JNI que interfaceia com o OpenGL, ou então (menos ambiciosamente) chamar aquelas APIs do Windows ou do Unix que fazem manipulação de metadados de arquivos (como data de criação, data de último acesso, tornar o arquivo executável ou read-only, mudar as permissões) e que não estão disponíveis na classe java.io.File.

Eu digo que “se tiver alguma lógica de negócio, ou mais de 2 telas, não deve usar C++”.

O que é uma aplicação robusta?
É aquela que não dá pau?
Se for isso, é melhor confiar mais em Java ou Erlang que em C++, que é notoriamente sujeita a problemas como invasão de memória, vazamento de memória e erros esquisitos que são oriundos de outras APIs que são chamadas em C++ e que precisam de um determinado ambiente que talvez seu programa C++ não consiga replicar.

Certo, mas aplicações feitas em C++, tendem a ser mais robusta, ou não?

Robustes não depende da linguagem e sim de inumeros fatores, um deles inclusive é a implementação da mesma.

Se eu pegar um compilador bugado…

Tava conversando com um colega que foi pros EUA. Programador Java lá, senão me engano, ganha em torno de 25 dólares a hora.
Programador C (não lembro se ele tinha falado C++) ganha 60.
60!! Po, eu trabalhava 10 horas por dia

É por isso que eles tentam migrar sistemas antigos de C para Java - a manutenção é muito cara, e a confiabilidade e flexibilidade deixam a desejar. (O Microsoft Money era feito em C++, não sei se ele ainda é feito em C++ ou se a Microsoft já o passou para C#).

C e C++ não devem ser usados, por exemplo, para fazer uma folha de pagamento, mas não há como deixar de escrever um “device driver” em C e Assembler, por exemplo.

Pois é.
Eu tenho muita vontade de trabalhar com sistemas embarcados, mais precisamente na área de robótica e celulares. Por falar nisso, já que estamos só entre “amigos”, já ouviram falar do Android né?

Esse Android aí é uma das razões pelas quais eu quero saber muito de Java e C++. Se vocês verem como foi feita a arquitetura em camadas, tem C++ e Java juntos. Uns colegas aqui apresentaram um trabalho de um robô feito com pessoas de impressora em C e Java. C comnadava a porta paralela da impressora e Java era a IDE que controlava o robô por meio de comandos. Muito interessante.

C++ tem muito espaço ainda em diversas areas de peso, tipo telecom e financeira.
Estas areas, além de terem enormes legados em C/C++, processam volumes gigantes de dados, em base de dados, arquivos ou transações em rede. É um mundo muito diferente do que contruir uma aplicação web, por maior que seja.

Eu tenho um boa esperiência em C++ em processos de grandes volumes (billing e cobilling).
E tenho um grande expêriencia em Java fazendo a mesma coisa (na época me acharam louco de fazer um sistema de processamento bath em Java).

O que posso dizer ?
É mais rápido devenvolver em Java, mas é muito mais facil devenvolver algo muito lento em Java. Java tem uma Api enorme e bem documentada. O uso de threads chega a ser trivial comparado com C++.

A JVM esta rápida, cada vez mais rápida. Mas não é qualquer programador Java que consegue tirar o desempenho da JVM para utilizar Java neste cenário.

Neste projeto tinha duas equipes de desenvolvedores Java, os Java Web e os desenvolvedores Java cabra macho

Outra vantagem do uso de Java, foi que a arquitetura foi bem desenhada com o bom uso de threads e a escalabilade deste sistema em Java é muito boa.

Escrever esta mesma arquitetura em C++ seria possível é claro, possívelmente até melhor com uso de de recursos do SO para o controle das threads. Mas quanto tempo isso iria demorar ?

dedejava:

Tava conversando com um colega que foi pros EUA. Programador Java lá, senão me engano, ganha em torno de 25 dólares a hora.
Programador C (não lembro se ele tinha falado C++) ganha 60.
60!! Po, eu trabalhava 10 horas por dia

thingol:

É por isso que eles tentam migrar sistemas antigos de C para Java - a manutenção é muito cara, e a confiabilidade e flexibilidade deixam a desejar. (O Microsoft Money era feito em C++, não sei se ele ainda é feito em C++ ou se a Microsoft já o passou para C#).

C e C++ não devem ser usados, por exemplo, para fazer uma folha de pagamento, mas não há como deixar de escrever um “device driver” em C e Assembler, por exemplo.

Cara, olhando o post do dedejava não dá pra chegar à conclusão do thingol. O que eu posso concluir é apenas que não estão sendo formados muitos programadores em C ou C++ quanto o mercado precisa, só isso.

Thingol, repetir a mesma coisa várias vezes não a torna verdade. É fácil dizer que C++ não serve pra coisas grandes ou que a manutenção é difícil, mas não me convence, porque:

1. Problema de manutenção é problema de arquitetura! C++, Cobol, Ada, Java, Python ou Ruby não são os culpados pelos problemas de manutenção, isso é mais problema do código espaguete, das abstrações ruins, entre outros.

2. Gerenciamento manual de memória é algo trabalhoso, mas não impossível. Programadores experientes em C++ sabem das armadilhas mais comuns e também conhecem o valgrind para detectar problemas. Eu, por exemplo, já trabalhei em uma empresa que só entregava o software se não houvesse nenhum memory leak, e entregávamos, em 100% dos casos.

3. Nem todo mundo prefere a abordagem C++ e Java ligado por JNI. Em certas empresas onde trabalhei que necessitava de acesso a hardware, a parte de C++ se estendia às regras de negócio também.

4. A única coisa que é responsável pelo sucesso de uma linguagem é a quantidade e a possibilidade de se fazer boas bibliotecas e frameworks. Java tem o trunfo de se fazer frameworks contando com reflexão e proxies dinâmicos, coisa que C++ não tem. Com Ruby, as possibilidades de abstração de uma biblioteca são maiores ainda que o Java. Pra mim, é isso que determinaram o sucesso dessas linguagens.

@Leonardo3001

O que determina o sucesso de uma linguagem, é quantas grandes empresas apostam ($$) nela.
Pode ser a linguagem mais tosca do mundo (VB?) mas se tem grandes empresas com interesse comercial nela, ela decola.

Hummm, talvez Ruby esteja quebrando este paradigma, primeiro a comunidade a criou e começou a usa-la, e depois, agora, grandes empresa estão olhando para ela (Sun, Oracle só para citar)

Nisso eu tenho que concordar com você. Pegamos Java (que o código é “bonito”). Se um cara que não sabe programar direito e nem identar corretamente fizer um código grande, fica extremamente ruim de analisar o código.

C++ tem muito espaço ainda em diversas areas de peso, tipo telecom e financeira.
Estas areas, além de terem enormes legados em C/C++, processam volumes gigantes de dados, em base de dados, arquivos ou transações em rede. É um mundo muito diferente do que contruir uma aplicação web, por maior que seja.

Acredito que em embarcados com restrições muito fortes também (pouca memória e coisa e tal).

batch? Mas por que acharam você louco?? É porque o processamento em lote tem i/o bounds?? Não entendo direito dessas coisas :>

Sobre o que você falou em C++ eu não posso opinar porque não sei, mas sobre a facilidade de se fazer algo lento em Java… a… isso eu concordo muito!

Leonardo,

Escrever esta mesma arquitetura em C++ seria possível é claro, possívelmente até melhor com uso de de recursos do SO para o controle das threads. Mas quanto tempo isso iria demorar ?

Acho que foi por isso com o thingol falou aquelas coisas.
No mormaço, deu pra entender que Java é uma linguagem que aplica extremamente o Reuso. Dizem que existe muita coisa pronta em C++, só que todas são de código fechado e pago :;

Eu não fiz a folha de pagamento, mas a contabilidade, livros fiscais, estoques, crédito e cobrança, contas a pagar, comercial…

Porque C++? Tenho muuuuuitos clientes com estações pentium 233 :shock: . Nesse caso a gente tem de programar “no osso”.

Leonardo,

Acho que não é bem assim. A linguagem fornece muitos mecanismos que contribuem para a robustês dos frameworks.
Um programador pouco experiente em C++ está muitíssimo sujeito a erros. A linguagem propicia isso. Mesmo um programador experiente tem que ser muito cauteloso.

Alguns exemplos de coisas "error prone", que podem acontecer no C++ mas não no Java:

1. No C++ os objetos são construídos de maneira implicita, a menos que se diga explicitamente o contrário;
2. No C++, pode não haver erros imediatamente caso o tamanho de arrays seja estourado (e isso pega até os mais experientes).
3. Não tem garbage collection. Isso significa que você pode deletar um objeto que outros estão usando (e o erro vai pipocar num outro lugar, não no código maldoso que deu o delete). Ou então, que você pode perder a referência e gerar um memory leak. É bom lembrar que ninguém projeta essas coisas…
4. Algumas macros podem gerar um código capicioso. Um exemplo clássico é a macro:
   #define MAX(x,y) (x)>(y)?(x): (y)

Que simplesmente se comporta mal ao chamar:
int a = max(x++, y);
pois soma x 2 vezes.

Eu poderia adicionar mais uns 30 itens a essa lista…

Claro, um bom projeto não tem dessas coisas. Mas, qual é o custo de se obter um bom projeto em C++? É muito mais alto do que em Java.

Hoje, eu concordo com o Thingol. Mas ampliaria a lista dele para incluir também software embarcado, aplicações gráficas no geral, simuladores físicos, aplicações de tempo real (você confiaria uma aplicação que abre as comportas de uma usina nuclear ao java? Nem eu. Nem a Sun - tem uma clausula que isenta o Java de aplicações desse tipo, afinal, vc nunca sabe quando o garbage collector vai rodar…). Sistema comercial? Deixa isso para linguagens com garbage collection, como Java e C#.

Ah sim, no caso das bibliotecas e APIs. C++ pode não ter reflection (tem a compilação com RTTI, mas não chega perto da forma que o Java implementa reflexão), mas tem programação genérica. É algo que o Java não tem.

Apoiado.
Essa é uma das razões que escolhem C++ para sistemas embarcados, não é? Pode-se ver e “controlar” o código… no Java tem muita pouca coisa que se precisa implementar… é tudo na base do reuso… e esse reuso pode pegar muita memória.

dedejava:

Apoiado.
Essa é uma das razões que escolhem C++ para sistemas embarcados, não é? Pode-se ver e “controlar” o código… no Java tem muita pouca coisa que se precisa implementar… é tudo na base do reuso… e esse reuso pode pegar muita memória.

No C++, você pode até mesmo alterar o compotamento do new e delete. Isso é controle suficiente para você? :lol:

É verdade, ja trabalhei num sistema onde o new foi sobrecarregado para carregar em uma tabela informações sobre todos os objetos em memória de forma a fazer, entre outras coisas, testes de alocação de recursos.

Mas era bizarro. Pior só aquela linguagem que permite reescrever o if (Haskell?)

Sim, em sistemas embarcados muitas vezes é impossível pensar em Java.
Estou falando de sistemas embarcados com poucos recursos de hardware, não Pocket e iPhones da vida.

Porque nunca tinham visto sistemas deste tipo em Java, apenas em C++.
E acredite, as JVMs anteriores à 1.4 marcaram em muitas cabeças que Java é muito, mas muito lento, e em muitas cabeças este mito permanece ainda hoje.

Vamos ser realista, Java não mais munto leito desde a versão 1.4. Hoje ele é só um pouquinho lento.

Hehehe.
Se a Sun conseguiu melhorar bastante isso eu não duvide que ela melhore muito mais.
E ainda existe muitas aplicações feitas em C++ paraIPhones. Até mesmo o GPhone usa.

Ah!
Uma coisa que eu queria perguntar:

Existe algum GUC++? ou GUCPP?

Algumas coisas que “por default” o java é mais rápido que o C++:

1. Criação e destruição de objetos (aqui a diferença é gritante);
2. Invocação de métodos (a VM consegue fazer inline automático);
3. Uso de classes sincronizadas em aplicação single-threaded (a VM consegue, muitas vezes, eliminar os locks);
4. Uso de reflexão (aqui considerando só os recursos que um compilador com RTTI ligado forneceria ao C++);

Digo, “por default” pois no C++ é possível usar recursos da linguagem para otimizar praticamente todos esses itens (mas isso é trabalhoso, difícil de fazer, sujeito a erros e custa caro, muito caro).

dedejava:

Ah!
Uma coisa que eu queria perguntar:

Existe algum GUC++? ou GUCPP?

Os programadores C++ são muito desunidos, comparados aos programadores Java - normalmente eles se agrupam por tecnologias (MSVC++ = Microsoft, gcc, sistemas embarcados etc.

Para dar uma idéia, antigamente existia uma revista chamada “C Users Journal”, que depois foi promovida para “C/C++ Users Journal” (http://www.cuj.com). Há alguns anos atrás ela resolveu ter uma seção Java; e há uns dois ou mais anos essa revista não existe mais, nem em versão Web.

Nossa, mas por que tanta desunião?
O único conjunto de pessoas que eu vejo sempre respondendo perguntas é a comunidade no orkut. Quanto custa manter um fórum como o GUJ, só que de C++?

Tem muita gente boa respondendo sobre C++ também no fórum da PDJ:
http://www.programadoresdejogos.com

Mas tem muita gente orientada a Czão por lá também.

Java é uma religião com várias seitas - Swing, SWT, JavaEE (com as suas subseitas Spring, WebSphere, BEA, JBoss, Struts etc).
Acho que muita gente quer criar seu framework da mesma forma que a cada dia aparece uma nova igreja pentecostal: todos têm a sua mensagem e a querem divulgar de sua maneira.
.NET é uma religião com bem menos seitas - basicamente ASP.NET e C#.
C e C++ não é exatamente uma religião - acho que é mais uma filosofia que uma religião, e cada um fica na sua.
Acho que o Linux é uma religião, que também é dividida em algumas seitas - há os adoradores do Slackware e os do Ubuntu, por exemplo.

Havia um tempo em que eu ficava respondendo no fórum da Microsoft sobre ATL e STL - isso faz alguns anos atrás, e não com o meu nickname atual.

O fato é que o “core” do C++ é menor e tem um número muito grandes de tecnologias em volta dele.

Por exemplo, um programador C++, Windows, que usa MFC vai ter um perfil e dúvidas muito diferentes de um programador C++ que faz aplicações no Linux. Esse exemplo vale para outras tecnologias, pois o C++ não tem classes nativas para acesso a banco de dados, por exemplo.

Acho que por isso as comunidades acabam se formando em torno dos usuários de diferentes tecnologias.

Entendo. Mas e agora me diz… em software embarcado cai mais C ou C++?
E hoje em dia vale aprender C++?

dedejava:

Entendo. Mas e agora me diz… em software embarcado cai mais C ou C++?
E hoje em dia vale aprender C++?

Embarcado em que?

Se for em componentes eletrônicos, o C ainda predomina.
Se for no dispositivo todo, o C++ domina.

Por exemplo, o software dos DSPs das centrais telefônicas são escritos em C. Mas o software da central em si, já está sendo escrito em C++.

Sempre é bom saber mais de uma linguagem.
Isso porque força você a pensar de outras maneiras - ser bitolado faz com que você não consiga encontrar soluções para seus problemas.

O programador Java comum (ou seja, aquele que há alguns anos atrás seria um “coboleiro” - hoje em dia é aquele cuja realização na vida é escrever uma action do Struts sem fazer muita besteira) pode se beneficiar, por exemplo, ao aprender C# e uma linguagem de script, como o Javascript*; o programador Java “hardcore” deve saber pelo menos uma linguagem de baixo nível (como C), uma de nível médio (C++) e uma de nível alto e de outro paradigma (funcional, como a Haskell).

• Javascript, tal como está sendo definido hoje em dia, é uma linguagem altamente complexa e que tem conceitos mais complexos que o Java. Tanto é que a implementação de referência está sendo escrita em uma linguagem funcional chamada Standard ML.

thingol:

Sempre é bom saber mais de uma linguagem.
Isso porque força você a pensar de outras maneiras - ser bitolado faz com que você não consiga encontrar soluções para seus problemas.

O programador Java comum (ou seja, aquele que há alguns anos atrás seria um “coboleiro” - hoje em dia é aquele cuja realização na vida é escrever uma action do Struts sem fazer muita besteira) pode se beneficiar, por exemplo, ao aprender C# e uma linguagem de script, como o Javascript*; o programador Java “hardcore” deve saber pelo menos uma linguagem de baixo nível (como C), uma de nível médio (C++) e uma de nível alto e de outro paradigma (funcional, como a Haskell).

• Javascript, tal como está sendo definido hoje em dia, é uma linguagem altamente complexa e que tem conceitos mais complexos que o Java. Tanto é que a implementação de referência está sendo escrita em uma linguagem funcional chamada Standard ML.

Aos interessados em linguagens funcionais recomendo a Erlang. Tem um futuro promissor pela frente, em especial para os computadores multi-core.

T+

Só pra dar uma “ressaltadinha” (não tenho vindo muito ao fórum).

Erlang é de programação paralela né?
Existe muita diferença se eu não aprender Erlang, mas usar OpenMPI, Jini, Jaspaarc, MPI e derivados (de desempenho)?

dedejava:

Só pra dar uma “ressaltadinha” (não tenho vindo muito ao fórum).

Erlang é de programação paralela né?
Existe muita diferença se eu não aprender Erlang, mas usar OpenMPI, Jini, Jaspaarc, MPI e derivados (de desempenho)?

MPI e afins é para programação distribuida. Erlang permite paralelismo intra-processo.