evandro.santos wrote:Mesmo uma equipe que saiba muito o que está fazendo (que por sinal seria muito mais cara do que a equipe de Java) C++ tem o problema de não possuir uma grande variedades de frameworks e APIs disponíveis (a um preço que não comprometa o projeto), imagine o tempo de implementar: classes para fazer Cache, Pool de conexões, controle de transação, um protocolo de comunicação (sockets é dureza), etc. Implementar isso tudo exige muito conhecimento e um bom tempo.

evandro.santos wrote:

Rubem Azenha wrote:

evandro.santos wrote:
Acredite que a maioria dos programadores C++ fariam um código de gerencia de memória pior do que está disponível no GC do Java.

Imagine a seguinte aplicação: 7000 usuário simultâneos, média de 25 transações por segundo (picos de 60 transações por segundo), banco de dados... Construir isso não seria simples (C++), deveria ter um servidor para reutilizar conexões, Cache, conexão entre o desktop e o server, controle de transações, etc.

Fica a seguinte pergunta: Em duas equipes, uma C++ e outra em Java, quem faria o software com a melhor performance?

Se a equipe de C++ souber o que esta fazendo, o software deles tera mais performance. Se a equipe de Java souber o que esta fazendo, o software deles tera mais performance.
A menos que você esteja fazendo algo que cada milisegundo de uma única operação é relevante (controle de um reator numa usina nuclear) ou uma aplicação 100% desktop, eu não acho que teria tanta diferença assim.

Mesmo uma equipe que saiba muito o que está fazendo (que por sinal seria muito mais cara do que a equipe de Java) C++ tem o problema de não possuir uma grande variedades de frameworks e APIs disponíveis (a um preço que não comprometa o projeto), imagine o tempo de implementar: classes para fazer Cache, Pool de conexões, controle de transação, um protocolo de comunicação (sockets é dureza), etc. Implementar isso tudo exige muito conhecimento e um bom tempo.

entanglement wrote:

evandro.santos wrote:
Mesmo uma equipe que saiba muito o que está fazendo (que por sinal seria muito mais cara do que a equipe de Java) C++ tem o problema de não possuir uma grande variedades de frameworks e APIs disponíveis (a um preço que não comprometa o projeto), imagine o tempo de implementar: classes para fazer Cache, Pool de conexões, controle de transação, um protocolo de comunicação (sockets é dureza), etc. Implementar isso tudo exige muito conhecimento e um bom tempo.

Hum... o problema principal em aplicações C++ não é a variedade de frameworks (ok, eu sei que um monte deles tem de ser adquirido em vez de ser open-source). O problema principal, a meu ver, é que é difícil detectar certos erros primários que costumam causar apenas stack traces em Java, mas provocam falhas fatais em C++. Isso atrasa sobremaneira o desenvolvimento.

ViniGodoy wrote:

evandro.santos wrote:Mesmo uma equipe que saiba muito o que está fazendo (que por sinal seria muito mais cara do que a equipe de Java) C++ tem o problema de não possuir uma grande variedades de frameworks e APIs disponíveis (a um preço que não comprometa o projeto), imagine o tempo de implementar: classes para fazer Cache, Pool de conexões, controle de transação, um protocolo de comunicação (sockets é dureza), etc. Implementar isso tudo exige muito conhecimento e um bom tempo.

Se brincar o C++ tem mais APIs do que o Java! Você pode começar por essa aqui:
http://www.boost.org/doc/libs


Só na boost tem API para absolutamente tudo o que você citou. E é free.


Eu concordo com o Entaglement. Um nullpointer em java gera um stacktrace com a exata linha de onde deu o problema. No C++, gera um General Protection Fault...
O mais difícil no C++ na minha opinião é mesmo a gerência de recursos, inclusive memória. Um leak de poucos bytes pode levar dias de desenvolvimento para ser encontrado. Sem falar que o C++ é praticamente um campo minado, cheio de pequenos detalhes de implementação que podem causar enormes dores de cabeça se negligenciados...

sergiotaborda wrote:A grande vantagem de todas as linguagens com VM , não apenas o java, é que existe sempre a opção de recompilar. Isto é simplesmente impossivel em linguagens como C++. C++ é uma linguagem, java é uma plataforma. São mundos diferentes. Comparar os dois não é honesto.

O JVM da Sun é uma das VM mais evoluidas, senão a VM mais evoluida. Isto porque existe empenho acadêmico em torná-la sempre melhor.
O problema da JVM é que existem duas JVM , a server e a client. Tradiconalmente a server sempre foi mais rápida e é mais rápida que C++, enquanto a cliente é mais lenta. (http://kano.net/javabench/data). Isto vai mudar na JVM 7 em que muitas das otimizações da jvm server irão passar para a jvm client.

Muitas evoluções acontece de forma muito inteligente , como por exemplo remover os monitores de concorrencia ou eliminar a verificação de limites de arrays que faz parte da especificação. Isto sem mexer na linguagem ou fazer o programador usar outro tipo de objeto ou artefato.

Dizer que java é mais rápido que C++ não tem significado. É preciso dizer qual JVM contra qual processador. Já que nem todas as JVM são igualmente rápidas e nem todo o C++ corre com a mesma velocidade. A JVM pode compilar codigo e recompilar sempre que achar necessário. Ela acumula estatisticas e outras informações ( a maior parte as mesmas que são transmitidas via o protocolo de profiling) que permitem tomar decisões sobre o quê compilar, quando e como. E depois de compilado ainda ha a opção de apagar e começar de novo. Isto não existe em C++ simplesmente porque não ha uma VM para C. Aliás esse é o objetivo do C: controlar a máquina real. Mas existem muitas máquinas reais, portanto as otimizações são limitadas.

Um outro problema é que, mesmo quando o C++ é mais rápido - por exemplo em calculos de matrizes, ele é menos exato. Não ha garantia que um calculo feito em C++ em máquinas diferentes terá o mesmo resultado. Isto é normalmente esquecido. Quando se diz que C não é portável não significa apenas que não roda em máquinas diferentes, significa que tem resultados diferentes em máquinas diferentes. Em java isto também acontece, mas a JVM dá garantias. Java implementa o padrão IEEE para numeros de ponto flutuante e dá garantias de ulp. Estes erros, em cadeias grandes de calculos, podem provocar diferenças obseráveis nos resultados.
Enfim, velocidade é inutil se o resultado não é reprodutivel.

Mesmo que o Java não tenha melhor velocidade hoje, com certeza terá melhor amanhã. O fato é real. A velocidade das JVM desde 1.0 até hoje vem aumentando. Em certo ponto ela irá ultrapassar a velocidade do C, C++ e outras linguagens estaticamente compiladas. Hoje estamos chegando perto disso. Muito perto...

P.S. embora não existe uma VM , per se, em C++ existem VM que correm a partir de codigo C++ tentando trazer para o ambiente estático algum dinamismo. http://llvm.org/. Isto significa que o uso de VM passa a ser obrigatório daqui para a frente ( dos anos 90 para frente, na realidade, mas só agora temos provas disso). E a performance, e outras qualidade de runtime passam a depender de algoritmos evoluidas das VM e não de "espertezas" dos programadores. Não é por acaso que todo o mundo quer ter sua linguagem sobre a JVM e até sobre a VM do .NET. Afinal fazer VM é dificil e altamente académico.

Jesuino Master wrote:Nem li todas as respostas, mas essa briga é velha.

Não li inteiro mas sei que:

* Java ser super pesado é um mito
* O poder de Java depende do seu poder como programador e como designer do sistema[uso correto da OO interfere na performance, alguém duvida?]
* Comparar Java com algo que só roda no windows é perda de tempo
....

ViniGodoy wrote:
O problema do Java no real time é que ele não permite que você faça uma aplicação determinística, por mais esmero que você tenha. Afinal, o garbage collector não estará sobre seu controle, e a aplicação vai literalmente pausar quando ele roda. Portanto, é importante analisar a duração média dessas pausas no seu sistema, e ver se elas ferem o intervalo de tempo estipulado, ou se elas são toleráveis como "perdas controladas", no caso do soft real time.

Kenobi wrote:Vini, nunca fiz não posso afirmar com certeza, mas diziam dentro da BEA que com a JRockit Real Time, você conseguia especificar para o GC coletar de tanto em tanto tempo de forma linear.

ViniGodoy wrote:

Kenobi wrote:Vini, nunca fiz não posso afirmar com certeza, mas diziam dentro da BEA que com a JRockit Real Time, você conseguia especificar para o GC coletar de tanto em tanto tempo de forma linear.

Ah, ok. Mas nesse caso é uma característica de uma VM específica. No Java 7, haverá um GC com mais garantias também.
De qualquer forma, mesmo no caso do Rockit, ou do Java 7, é ainda muito difícil especificar com perfeita exatidão o que será coletado e como.

Tchello wrote:

ViniGodoy wrote:

Kenobi wrote:Vini, nunca fiz não posso afirmar com certeza, mas diziam dentro da BEA que com a JRockit Real Time, você conseguia especificar para o GC coletar de tanto em tanto tempo de forma linear.

Ah, ok. Mas nesse caso é uma característica de uma VM específica. No Java 7, haverá um GC com mais garantias também.
De qualquer forma, mesmo no caso do Rockit, ou do Java 7, é ainda muito difícil especificar com perfeita exatidão o que será coletado e como.

Que tipo de garantias será dada no GC do java 7?
Fiquei curioso agora! Pesquisando...

Tchello wrote:Que tipo de garantias será dada no GC do java 7?
Fiquei curioso agora! Pesquisando...