Queria saber na opnião de vocês desenvolvedores C++ && Java e já adiantar a minha sobre essas linguagens. Não sou expert em nenhuma delas então não tomem nada como verdade até a prova ao contrário rsrs
Já passou momentos no Java que você gostaria de estar usando C++ ? Tipo - Preciso mexer com bytes agora, posso precisar de um unsigned short int aqui e… opa! Google…
Ah estou usando esse int aqui como flag ou contador então vou mandar ele como parãmetro e a outra função altera se der tudo certo… opa. Google…
Vou fazer uns filtro de imagem aqui com I.A pra identificar qual o melhor filtro pra este tipo de imagem, só colocar esses métodos aqui num vetor e randomizar a escolha dos filtros e… deu certo (era c++ rsrs).
Essa liberdade do C++ é muito boa, o Java é excelente tbem você recorre menos ao Google do que o C++ já que vem com bastante métodos prontos e documentados, mas as vezes poderia ser mais flexível.
Tanta liberdade em C++ pode dar problema também, mas é mais para desenvolvedores inexperientes no uso de ponteiros e afins.
E vocês qual situações já queria um pouco de mais liberdade do C++ em Java e quando mais do gerenciamento do Java em C++ ?
Cara, faz mais de um ano que meu ‘day job’ é programar em C++. Acho um porre ter de ficar me preocupando com as seguintes coisas do C++:
Ponteiros apontando sei lá pra onde
Exceções que, se não tratadas, derrubam tudo e não têm stack trace
Vazamentos de memória absurdos
Velocidades de compilação do tempo das cavernas (um sistema em que trabalho leva mais de uma hora para compilar - e isso que ele não é muito complexo)
E isso que usamos uma porção de bibliotecas que minimizam esses problemas (e que casualmente deixam seu programa muito semelhante a um programa em Java ou C#). Eu mesmo raramente tenho problemas com isso, mas o problema é quando você tem de manter um programa dos outros, que costuma ser infestado de tais problemas nojentos.
Eu sei que, se precisar de alguma coisa de baixo nível no Java, é só criar uma DLL JNI em C++ ou C mesmo, e depois chamá-la do Java. Se é para usar nível baixo, uso então aquelas instruções SSE3/SSE4 (que são possíveis de serem usadas só com extensões do compilador C/C++, para que haja pelo menos alguma diferença em relação ao Java (que já usa essas instruções “sem você saber”, dependendo da versão da JVM).
Eu me queixo do Java é que ele não incluiu (nem tão cedo vai incluir) certas coisas que serão incluídas no C++ na próxima versão (C++0X), como
Funções lambda (o correspondente dos “closures” propostos no Java, ou dos “anonymous delegates” do C#)
tudo o que você citou é possível fazer com qualquer linguagem. Tanto filtros de imagens digitais, como compiladores, etc…
A vantagem de uma máquina virtual é o coletor de lixo, que te abstrai de gerenciar memória
ex:
java
[code]
Object o = new Object();[/code]
c++
[code]
Object o = new Object();
delete o; // não tenho coletor de lixo, então necessito gerenciar os objetos e variaveis que aloquei na memória
o = NULL;[/code]
O único quesito contra coletores de lixo, é na questão performance. Este ponto pode ser muito evidente em determinados tipos de software, ou de não fazer notar nenhuma diferença em outros.
Pra controlar bem ponteiros, as classes e métodos tem de ser o mais modular possível, assim fica fácil o gerenciamento deles é só lembrar teve um new tem um delete, agora métodos muito grandes que mexem em endereços ai fica meio foda mesmo. As famosas classes chuck norris não é nenhum pouco agradavel em C++.
Tratamento de exceções tem não tem? Lembro de ja ter pesquisado sobre o assunto mas acabei usando o controle por retorno mesmo. Em Java nos acostumamos a depender de exceções, em C/C++ o controle de erros é mais no braço mesmo.
Compilação é brabo mesmo, mas existe o make pra essas coisas ai né… onde compila só o que foi mexido.
Eu nunca usei uma JNI, precisa ter o um compilador C instalado ou o JVM cuida disto? Não fica meio frankstein isso não?
por mim C++ teria tudo o que Java tem, mas com a liberdade de escolha de poder ou não usar, ai sim seria um show de linguagem. Gosto ambas das duas, as vezes um tratamento fácil de execeções como no Java seria bem interessante também.
No próximo C++ já esta decidido a inclusão das libs boost www.boost.org, ai sim vai ficar uma belezura rsrs.
[quote=enantiomero]Cara, faz mais de um ano que meu ‘day job’ é programar em C++. Acho um porre ter de ficar me preocupando com as seguintes coisas do C++:
Ponteiros apontando sei lá pra onde
Vazamentos de memória absurdos[/quote]
Você está usando Smart Pointers? Sua equipe segue corretamente o conceito de RAII?
Se está, você não deveria ter desses problemas…
Isso ocorre no Java também, mas gera stack trace. De qualquer forma, se você fizer direitinho, o postmortem debugger também poderá gerar para você um process dump, que te dará a stack trace do erro.
Realmente, é e desvantagens de ter os templates. Entretanto, isso pode ser minimizado caso você gerencie corretamente os .h. Agora, se seu projeto não usa templates, e nem bibliotecas que as usam internamente, seu tempo de compilação não deveria ser tão longo.
Pois é, com o boost::shared_ptr<> (que vai entrar no C++0X como std::tr1::shared_ptr<>, se não me engano) nem preciso me preocupar com isso - quando a contagem de referências cai a zero, o objeto é automaticamente deletado.
As únicas coisas chatas :
você precisa se preocupar se você vai ter uma referência ao próprio objeto (que se resolve fazendo a classe herdar de "boost::enable_shared_from_this<>").
você precisa se preocupar se há referências circulares ou recursivas nos objetos - aí você precisa usar uns boost::weak_ptr em vez de boost::shared_ptr em lugares adequados.
Concordo com você, mas o problema é que, como todo bom sistema grande, há toneladas de código antigo (que normalmente tem aqueles problemas do tipo “o programador que deixou essa bomba não acreditava em std::string e fazia tudo com char*, e não tinha a menor ideia para que servia a palavra-chave “const””), e claro que é impraticável reescrever o código antigo para ficar de acordo com as melhores práticas.
Isso é o meu inferno.
Eu programei 6 anos com C++ e 8 anos com Java. Mesmo na época do Java, ainda mantive o contato com o C++.
Eis algumas conclusões:
a) O C++ é muito vantajoso quando você quer interagir com o sistema operacional ou com hardware. Exemplo disso é que é virtualmente impossível programar um sistema DirectX em Java.
b) O C++ é vantajoso também quando você precisa de uma aplicação muitíssimo enxuta. Entretanto, raramente você precisa de algo assim.
c) O Java, para aplicações normais, é até mesmo mais eficiente do que o C++. Exemplos disso são o fato do operador new e delete terem um custo baixíssimo, assim como a geração de exceções;
d) A personalização do C++ é possível, porém, geralmente é muito cara e complexa. Por exemplo, seria possível sobrescrever os operadores new e delete de forma a fazer o gerenciamente de memória como no Java. Mas isso não é tarefa fácil.
e) Se você precisa de um software crítico (para controlar usinas, aviões, etc), você está proibido de usar o Java.
f) Embora o C++ seja mais otimizável que o Java, é mais fácil e barato produzir aplicações otimizadas com Java. O Java possui ferramentas melhores e gratuitas para isso, como a Visual VM, o profiler do Netbeans ou o projeto TPTP, do Eclipse.
Qual eu prefiro? Bom, para a absurda maior parte dos sistemas hoje em dia, eu prefiro o Java. Geralmente, não se precisa interagir com SO, nem com drivers de hardware. Além do que, muitas libs que necessitariam JNI já foram portadas (como OpenGL e até GPIB).
Entretanto, para estudar os jogos AAA, é C++ na cabeça.
Até onde eu sei, o std::tr1::shared_ptr já existe, desde a TR1. Por ser um tecnical report, obviamente sua implementação é opcional, mas os compiladores GNU já o incluem.
No próximo C++ a proposta é que ele passe para o std:: diretamente. Ainda irá manter o handle para o std::tr1 por questões de compatibilidade (como fizeram com os cabeçalhos do Czão).
Realmente, se tem sistema legado no meio, aí só posso lamentar.
E, Maiko, essa história de “se tem um new é só lembrar de um delete” é uma simplificação grosseira de um problema muitíssimo maior. Você precisa garantir que para cada new existe um, e somente um, delete. E que esse delete só pode ser dado caso esse objeto não seja referenciado por mais nada.
O que significa dizer que sua programação toda terá que convergir para um ponto, onde o objeto será totalmente desreferenciado e deletado. E isso, sem técnicas mais avançadas, é uma tarefa extremamente complexa. Aliás, é a grande dor de cabeça do C, ou do C++ mal utilizado (como é o caso do sistema legado do colega ali).
Quando eu disse proibido, quis dizer proibido mesmo:
Infelizmente, o garbage collector ainda não pode dar garantias sobre o momento da execução. Parece que vão resolver boa parte desse problema nas próximas versões de java mas, até lá, só se pode fazer sistemas críticos como esse em linguagem compiladas onde se tenha muito controle.
Mesmo a licença do Java Real-Time (onde você pode desligar o Garbage Collector para alguns tipos de dados) diz exatamente a mesma coisa. Provavelmente foi um copy & paste, ou então a Sun é contra a energia nuclear (talvez seja a favor da energia solar )
[quote=MaikoID]e) Se você precisa de um software crítico (para controlar usinas, aviões, etc), você está proibido de usar o Java.
[/quote]
Eu proibiria o C++ também - imagine seu avião cair por um ponteiro perdido. Uma linguagem mais burocrática como o Ada (que também derrubou foguetes) talvez fosse melhor nesse ponto.
Quando ouço isso aqui, geralmente penso na velha comparação C++ puro sem qualquer lib, versus Java com todas as libs. Tipicamente, é comparação que os programadores java fazem…
O C++ hoje é composto do C++, da STL e da Boost. A STL é a biblioteca padrão, já com classes como string, vector, list, etc. Todo C++ vem com ela em sua distribuição oficial.
Embora a boost não seja de distribuição oficial, ela é mantida pela mesma comunidade que produz o C++. É extremamente bem documentada, e tem classes para fazer praticamente qualquer coisa. É praticamente tão extensa quanto a própria biblioteca do Java. Muito do que será adicionado nas próximas versões do C++ vem da boost.
[quote=enantiomero][quote=MaikoID]e) Se você precisa de um software crítico (para controlar usinas, aviões, etc), você está proibido de usar o Java.
[/quote]
Eu proibiria o C++ também - imagine seu avião cair por um ponteiro perdido. Uma linguagem mais burocrática como o Ada (que também derrubou foguetes) talvez fosse melhor nesse ponto.[/quote]
A diferença é que isso pode ser testado, e pode ser corrigido.
O garbage collector não pode ser corrigido.
No caso do Java RTS, talvez isso ainda esteja escrito pq se trata de uma versão para avaliação.
Não quis fazer essa comparação do C++ puro não, tem um bocado de boas funções que vem com o C++ a boost ajuda muito mas pra comparar vamos ter de esperar que ela venha junto com o C++.
Essa sobre o Java não poder controlar usina nuclear e aviões eu realmente não sabia rsrs.
[quote=ViniGodoy]Quando eu disse proibido, quis dizer proibido mesmo:
Infelizmente, o garbage collector ainda não pode dar garantias sobre o momento da execução. Parece que vão resolver boa parte desse problema nas próximas versões de java mas, até lá, só se pode fazer sistemas críticos como esse em linguagem compiladas onde se tenha muito controle.[/quote]
Isso mesmo. As vezes deixar um processador pensar por você não é a escolha mais adequada a determinada situação. Uma característica que achei interessante da linguagem d. Você tem o coletor de lixo, mas pode optar por usar ponteiros e gerenciar a memória manualmente. Isso dá uma flexibilidade enorme, em partes de código críticas. O c# também permite, com unsafe.
E o Java com jni
Já trocamos Java por c++ em aplicações que demandassem performance ou que não pudessem exigir muito consumo de memória RAM (o Java apesar do garbage colector, consome memória RAM demais).
Sobre testes nucleares, lembrei de um caso com o Matlab. Iríamos comprar uma licença pra um trabalho em Furnas e pedi pro cara fazer cotação. Só que o comprador não sabia e cotou com TODAS as bibliotecas, daí o custo tinha ficado altíssimo e a diretoria não aprovou. Quando eu vi, fui retirar todos os módulos que não precisaríamos.
Não sei se todo mundo conhece o software ou sabe disso, mas ele tem dezenas de módulos e bibliotecas pras mais variadas áreas, inclusive bibliotecas de balística e simulação nuclear. E tem uma cláusula na licença que pra poder adquirir os módulos de simulação nuclear, balísticas e outros que não entendi a utilidade, você precisaria de ter uma autorização do governo dos EUA e não poderia estar nas lista de países "não amigos " do governo americano.
[/quote]
O os ponteiros do jni são escritos em c, e depois repassados para os tipos primitivos do java. O JNA que adiciona essa funcionalidade no java. Mas eu fico meio com pé atras, por precisar de uma lib pra fazer isso. No caso de d e c#, são recursos da linguagem.
[code]JNIEXPORT jint Java_package_class_connect( … )
{
handle *h; // handle a struct…
h = openDevice();
)