Qual você prefere a liberdade do C++ ou a administração da JVM no Java

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

Object o = new Object();

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;

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.

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

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).

e) Se você precisa de um software crítico (para controlar usinas, aviões, etc), você está proibido de usar o Java.

Essa fiquei surpreso, não era Java que iria substituir cobol pela estabilidade e tararannn ?

Como vinigodoy falou, da pra customizar o C++ mas acaba pesando bastante, ele deveria ja vir um pouco mais pronto.

Sobre aplicações enxutas, discordo que seja muito raro a necessidade, qdo vai ter 30mb de ram pra um pequeno hardware, instalar o jvm fica complicado.

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 )

http://java.sun.com/javase/technologies/realtime/rts/90daylicense.txt

MaikoID:

e) Se você precisa de um software crítico (para controlar usinas, aviões, etc), você está proibido de usar o Java.

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.

Se quiser conhecer:
http://www.boost.org

enantiomero:

MaikoID:

e) Se você precisa de um software crítico (para controlar usinas, aviões, etc), você está proibido de usar o Java.

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.

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.

Abraços.

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.

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.

"

marcosalex:

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.

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.

JNIEXPORT jint Java_package_class_connect( ... )
{
handle *h; // handle a struct...
h = openDevice();

jclass cls = (*env)->GetObjectClass(env, obj);
jfieldID fid = (*env)->GetFieldID(env, cls, "handle",
"Ljava/lang/Object;");
(*env)->SetObjectField(env, obj, fid, h);

}

"

Essa linguagem D eu não conhecia parece que é tudo o que eu tinha comentado sobre com C++ deveria ficar e quais recursos deveria “copiar do java”.

Gostei bastante dela, estou estudando daqui a pouco faço um programinha básico =]

Abraço.

marcosalex:

juliocbq:

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.

JNIEXPORT jint Java_package_class_connect( ... )
{
handle *h; // handle a struct...
h = openDevice();

jclass cls = (*env)->GetObjectClass(env, obj);
jfieldID fid = (*env)->GetFieldID(env, cls, "handle",
"Ljava/lang/Object;");
(*env)->SetObjectField(env, obj, fid, h);

}

O 'recurso' do C# é uma chamada da API do Windows. O Delphi.net também tinha isso.

Opa...o unsafe é diferente do pinvoke. Funciona assim:

static unsafe void Copy(byte[] src, int srcIndex,
byte[] dst, int dstIndex, int count)
{
if (src == null || srcIndex < 0 ||
dst == null || dstIndex < 0 || count < 0)
{
throw new ArgumentException();
}
int srcLen = src.Length;
int dstLen = dst.Length;
if (srcLen - srcIndex < count ||
dstLen - dstIndex < count)
{
throw new ArgumentException();
}



fixed (byte* pSrc = src, pDst = dst) // dentro de um bloco unsafe, o coletor de lixo não passa, então preciso gerenciar a memória manualmente, me possibilitando usar ponteiros.
{
byte* ps = pSrc;
byte* pd = pDst;

for (int n =0 ; n < count/4 ; n++)
{
*((int*)pd) = *((int*)ps);
pd += 4;
ps += 4;
}

for (int n =0; n < count%4; n++)
{
*pd = *ps;
pd++;
ps++;
}
}
}

MaikoID:

Essa linguagem D eu não conhecia parece que é tudo o que eu tinha comentado sobre com C++ deveria ficar e quais recursos deveria “copiar do java”.

Gostei bastante dela, estou estudando daqui a pouco faço um programinha básico =]

Abraço.

Sim, é muito boa. Já se tem port de gtk para ela, e um recurso tmb que é muito bom, é gerar código nativo, e possuir coletor de lixo.

Um dos problemas do C++ que mais me atormenta hoje em dia são as diversas armadilhas que o código ainda tem, e que não serão removidas por causa da compatibilidade. Eis algumas delas:

1. Construtores implícitos por default;
2. Destrutores não virtuais de classes virtuais;
3. Impossibilidade de sobrecarregar valores default de parâmetro;

etc… etc… etc…

Livros como o Effective C++ mais parecem um manual de como se afastar de minas. Ok, há muitas dicas realmente genéricas e úteis lá, mas dá para dizer que pelo menos uns 30% do livro são só recomendações de como escapar das bombas.

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).

Que tipo de aplicações?

Na Siemens a troca está sendo justamente ao contrário. O C++ está perdendo lugar para o Java, justamente por causa da performance.
No Java, você tem diversas ferramentas não intrusivas de instrumentação, como o Visual VM, o Netbeans Profiler, o Eclipse TPTP.

No C++, você não tem praticamente nada. É difícil instrumentar, difícil identificar onde otimizar, e difícil gerar um código performático. Alocação e desalocação de memória é feita de maneira muito primitiva, a menos que você mesmo implemente um memory manager, ou compre um.

Agora, a parte de memória, você tem razão. O Java realmente come muita RAM.

Não é possivel comparar linguagens gerenciadas com não-gerenciadas e muito menos linguagens baseadas em VM e não baseadas em VM.

Para qualquer aplicação empresarial Java é mais do que suficiente. C pode ter afetos no campo do hardware, mas ai é para sofrer mesmo.

Se em java , que é gerenciado, os programadores já fazem muita arsneira ( as quais a VM segura no muito bom modelo de exceções)
imagine em não gerenciadas onde o esquecimento ou um mau design levam a desastres.

Java é uma linguagem de alto nivel para aplicações de alto nivel de abstração (ninguem quer se preocupar com o espaço de memoria e coisas “fisicas” assim).C é o inverso. Cada um tem o seu nicho.

hoje em dia a própria linguagem java assume para a VM o papel que o C++ assume para a máquina real, sendo utilizada para criar ferramental (compiladores e extensões) para linguagens ainda mais alto nivel.

Elas não são concorrentes. Existe uma simbiose entre elas. A prova é o JNI ( e agora o JNA)

sergiotaborda:

Não é possivel comparar linguagens gerenciadas com não-gerenciadas e muito menos linguagens baseadas em VM e não baseadas em VM.

Para qualquer aplicação empresarial Java é mais do que suficiente. C pode ter afetos no campo do hardware, mas ai é para sofrer mesmo.

Se em java , que é gerenciado, os programadores já fazem muita arsneira ( as quais a VM segura no muito bom modelo de exceções)
imagine em não gerenciadas onde o esquecimento ou um mau design levam a desastres.

Java é uma linguagem de alto nivel para aplicações de alto nivel de abstração (ninguem quer se preocupar com o espaço de memoria e coisas “fisicas” assim).C é o inverso. Cada um tem o seu nicho.

hoje em dia a própria linguagem java assume para a VM o papel que o C++ assume para a máquina real, sendo utilizada para criar ferramental (compiladores e extensões) para linguagens ainda mais alto nivel.

Elas não são concorrentes. Existe uma simbiose entre elas. A prova é o JNI ( e agora o JNA)

Esse ae é o ponto onde queria chegar. Poder de escolha na codificação. Na minha opinião, o jni é muito complicado de se operar, e jna não é muito confiável. Mas d e c# conseguiram dar esse poder de escolha. Não estou falando de framework, mas da linguagem em si. Vamos esquecer .net, java vm e as outras coisas, e pensar somente na linguagem.

juliocbq:

sergiotaborda:

Não é possivel comparar linguagens gerenciadas com não-gerenciadas e muito menos linguagens baseadas em VM e não baseadas em VM.

Para qualquer aplicação empresarial Java é mais do que suficiente. C pode ter afetos no campo do hardware, mas ai é para sofrer mesmo.

Se em java , que é gerenciado, os programadores já fazem muita arsneira ( as quais a VM segura no muito bom modelo de exceções)
imagine em não gerenciadas onde o esquecimento ou um mau design levam a desastres.

Java é uma linguagem de alto nivel para aplicações de alto nivel de abstração (ninguem quer se preocupar com o espaço de memoria e coisas “fisicas” assim).C é o inverso. Cada um tem o seu nicho.

hoje em dia a própria linguagem java assume para a VM o papel que o C++ assume para a máquina real, sendo utilizada para criar ferramental (compiladores e extensões) para linguagens ainda mais alto nivel.

Elas não são concorrentes. Existe uma simbiose entre elas. A prova é o JNI ( e agora o JNA)

Esse ae é o ponto onde queria chegar. Poder de escolha na codificação. Na minha opinião, o jni é muito complicado de se operar, e jna não é muito confiável. Mas d e c# conseguiram dar esse poder de escolha. Não estou falando de framework, mas da linguagem em si. Vamos esquecer .net, java vm e as outras coisas, e pensar somente na linguagem.

bom, meu ponto era exactamente o oposto. hoje em dia pensar na linguagem é secundário. É preciso pensar na plataforma.
Plataforma inclui não apenas as libs e as linguagens possiveis, mas tb a facilidade de protabilidade e extensão.

O consumo de recursos como a RAM (e até a a bateria) são importantes em certas aplicações. Mas essas aplicações são especificas, portanto é natural que as soluções sejam especificas. A sacada é usar plataforma genéricas para essas mesmas soluções especificas.

Quanto à linguagem ser promiscua acho uma falha de design. Java permite a extensão sem ser promiscuo.
O fato do C# ter o unsafe é um contrasenso para um ambiente gerenciado.

"

marcosalex:

Nos nossos sistemas de análise de laboratório. São processos com cálculos matemáticos complexos e alto paralelismo e no final tem de gerar imagens pesadas em 3D. A diferença de performance foi brutal, reduzimos em dois dígitos de grandeza o cálculo quando passamos pra C++.

Imagino que seja um dos motivos da maioria dos programas desse nível serem feitos em C e C++.

Ah claro, em sistemas assim também. Até porque, geralmente a memória para o calculo é pré-alocada, se não inteiramente, quase inteiramente.

Vocês chegaram a fazer algum profiling no Java?

Sei que tá meio tarde, mas vou responder a “pergunta original” do tópico:

Em meus quatro anos de trabalho pós-universidade, dois foram em C ou C++ e dois foram em Java. E de todos os sistemas que eu vi em C e C++, todos poderiam ser feitos em Java numa boa. Razões: não eram sistemas de tempo real, envolvia grande quantidade de I/O e nunca usava cálculos matemáticos complexos.

Existe até um mito de que, se envolver manipulação de bytes, o ideal é C. Não é verdade, Java possui as classes DataInputStream e DataOutputStream que fazem a manipulação de bytes puros vindo da (ou indo para) rede, transformando em tipos primitivos apropriados. O controle é até melhor, e não há a chance de esquecer de dar o ntoh ou hton nas variáveis.

Eu não acredito que exista liberdade em C++. Creio no contrário, o fato de estar num ambiente gerenciado como a JVM me permite me ver livre de problemas de memória e me deixa livre para me preocupar naquilo que realmente me interessa, o negócio. O C ou o C+ seriam apenas quando apropriado, como em casos de manipulação de hardware, por exemplo. Não usaria essa linguagem nem se minha preocupação fosse performance; caso precisasse de um componente nativo da máquina (e tivesse liberdade para tal) tentaria antes usar alguma linguagem funcional que compila nativamente (como Haskell, OCaml ou CommonLisp), e ver se eu obtive algum ganho.

sergiotaborda:

juliocbq:

sergiotaborda:

Não é possivel comparar linguagens gerenciadas com não-gerenciadas e muito menos linguagens baseadas em VM e não baseadas em VM.

Para qualquer aplicação empresarial Java é mais do que suficiente. C pode ter afetos no campo do hardware, mas ai é para sofrer mesmo.

Se em java , que é gerenciado, os programadores já fazem muita arsneira ( as quais a VM segura no muito bom modelo de exceções)
imagine em não gerenciadas onde o esquecimento ou um mau design levam a desastres.

Java é uma linguagem de alto nivel para aplicações de alto nivel de abstração (ninguem quer se preocupar com o espaço de memoria e coisas "fisicas" assim).C é o inverso. Cada um tem o seu nicho.

hoje em dia a própria linguagem java assume para a VM o papel que o C++ assume para a máquina real, sendo utilizada para criar ferramental (compiladores e extensões) para linguagens ainda mais alto nivel.

Elas não são concorrentes. Existe uma simbiose entre elas. A prova é o JNI ( e agora o JNA)

Esse ae é o ponto onde queria chegar. Poder de escolha na codificação. Na minha opinião, o jni é muito complicado de se operar, e jna não é muito confiável. Mas d e c# conseguiram dar esse poder de escolha. Não estou falando de framework, mas da linguagem em si. Vamos esquecer .net, java vm e as outras coisas, e pensar somente na linguagem.

bom, meu ponto era exactamente o oposto. hoje em dia pensar na linguagem é secundário. É preciso pensar na plataforma.
Plataforma inclui não apenas as libs e as linguagens possiveis, mas tb a facilidade de protabilidade e extensão.

O consumo de recursos como a RAM (e até a a bateria) são importantes em certas aplicações. Mas essas aplicações são especificas, portanto é natural que as soluções sejam especificas. A sacada é usar plataforma genéricas para essas mesmas soluções especificas.

Quanto à linguagem ser promiscua acho uma falha de design. Java permite a extensão sem ser promiscuo.
O fato do C# ter o unsafe é um contrasenso para um ambiente gerenciado.

Não é falha não, na verdade, é um recurso que te dá muita flexibilidade. Por exemplo:

//Gerenciado
public void filtraImagem(Bitmap bitmap){
bitmap.setBits(x,y,pixel / 3);

}

//Não Gerenciado
public unsafe void filtraImagem(Bitmap *bitmap){
bitmap[i] = pixel / 3; //Vermelho
bitmap[i+1] = pixel / 3; //Verde
bitmap[i+2] = pixel / 3; //Azul

}

O segundo código não é gerenciado, então o responsável pela otimização sou eu. Ele vai executar bem mais rápido que o primeiro, pois não tenho o coletor de lixo, e quem libera a memória é meu código.

Tenho poder de escolher entre os dois. Em código que exigisse operações com tempo crítico de processamento, posso optar pelo segundo, ou, o primeiro, caso contrário. Isso não tem nada haver com plataforma.

No caso da linguagem D, ela possui coletor de lixo, e gera código nativo, ou seja, não preciso de máquina virtual.

Leonardo3001:

Sei que tá meio tarde, mas vou responder a “pergunta original” do tópico:

Em meus quatro anos de trabalho pós-universidade, dois foram em C ou C++ e dois foram em Java. E de todos os sistemas que eu vi em C e C++, todos poderiam ser feitos em Java numa boa. Razões: não eram sistemas de tempo real, envolvia grande quantidade de I/O e nunca usava cálculos matemáticos complexos.

Existe até um mito de que, se envolver manipulação de bytes, o ideal é C. Não é verdade, Java possui as classes DataInputStream e DataOutputStream que fazem a manipulação de bytes puros vindo da (ou indo para) rede, transformando em tipos primitivos apropriados. O controle é até melhor, e não há a chance de esquecer de dar o ntoh ou hton nas variáveis.

Eu não acredito que exista liberdade em C++. Creio no contrário, o fato de estar num ambiente gerenciado como a JVM me permite me ver livre de problemas de memória e me deixa livre para me preocupar naquilo que realmente me interessa, o negócio. O C ou o C+ seriam apenas quando apropriado, como em casos de manipulação de hardware, por exemplo. Não usaria essa linguagem nem se minha preocupação fosse performance; caso precisasse de um componente nativo da máquina (e tivesse liberdade para tal) tentaria antes usar alguma linguagem funcional que compila nativamente (como Haskell, OCaml ou CommonLisp), e ver se eu obtive algum ganho.

Ela existe, e posso te dizer, de experiência própria. Um bom caso de testes, seria implementar uma aplicação de vídeo, e desenvolver filtros que processassem a imagem em tempo real. Trabalho com esse tipo de aplicação, para segurança.

Tive que portar aplicações de java para c++ ou pascal, pela possibilidade de lidar com ponteiros. Mas como citado no post acima, existem linguagem que te dão opção de ter memória gerenciada ou não, que na minha opinião, foi um grande avanço em facilidade e uso.

Bom, tenho que discordar de você. O Java não trabalha com o tipo unsigned e, nem nas classes que você citou, nem nas classes do pacote NIO, há qualquer suporte para eles. É relativamente fácil implementar esse suporte, mas acho uma pena que a API nativa do Java não cubra isso já que, a principio, uma aplicação em rede deveria suportar hosts em qualquer linguagem. E os dados binários de vindos arquivos também poderiam ter sido gerados por qualquer software.

Existe também outra vantagem ao se trabalhar com comunicação de dados em C ou C++. Você pode pegar vários bytes de dados e converte-los para uma struct ou classe diretamente. É uma das poucas vantagens de se ter casts mais “agressivos”. No Java, você é obrigado a fazer uma leitura para cada campo, gerando um código muito mais longo e trabalhoso.

Não sei, mas a sua sua justificativa pareceu contradizer a sua primeira afirmação.

1. O Java não deixa você escolher uma nova estratégia para alocação de memória;
2. O Java não permite que você chame métodos nativos (JNI é código C / C++);
3. O Java não permite que você trabalhe sem conversão na arquitetura mais otimizada do seu processador.
4. O Java não te dá escolhe sobre quando o garbage collector vai rodar;

Se isso não é restringir liberdade, é o que? Tudo isso é possível em C++, então, podemos dizer que lá tem mais liberdade sim.

Claro, na maior parte das vezes, não queremos ter de lidar diretamente com essas coisas brutas, e é melhor mesmo focar no negócio e deixar a liberdade para isso de lado.

Agora, se nosso negócio envolve lidar com esses detalhes (como o caso do hardware), ou se precisamos de uma otimização nesse campo, então, aí começaremos a sentir falta dessa liberdade. Obviamente recair ao C++ não é a única alternativa, você mesmo citou algumas outras.

Bem, voltando ao tema original do tópico. Dizer “qual é preferível” é muito difícil. Eu diria que para a absoluta maioria dos negócios hoje em dia, vai ser muito melhor escolher uma linguagem gerenciada. Não é à toa que elas tem ganhado tanto espaço no mercado. Ninguém quer perder horas do dia implementando um gerente de memória, e nem precisa ter preocupações extremas sobre poupar memória economizando aquele primeiro bit de uma variável unsigned.

Entretanto, em mercados específicos, como o científico, o de jogos, hardware, produção gráfica, o meteorológico, o matemático, você ainda vai encontrar muita aplicação para linguagens não gerenciadas, já que esses mercados vão justificar um investimento em performance ou vão exigir uma integração com hardware que as linguagens gerenciadas procuram abstrair.

da primeira vez que vi d, não acreditei que pudesse ter coletor de lixo, suporte a ponteiros, e gerasse código nativo. Não implementei muitas coisas nela, mas existe uma grande possibilidade de eu começar a usar e aplicar no meu trabalho, pelas razões que o vini citou, e também por ter opção de coleta de lixo automática.

http://www.digitalmars.com/d/
http://elderane.50webs.com/tuto/d/index.html

Bom, tenho que discordar de você. O Java não trabalha com o tipo unsigned e, nem nas classes que você citou, nem nas classes do pacote NIO, há qualquer suporte para eles. É relativamente fácil implementar esse suporte, mas acho uma pena que a API nativa do Java não cubra isso já que, a principio, uma aplicação em rede deveria suportar hosts em qualquer linguagem. E os dados binários de vindos arquivos também poderiam ter sido gerados por qualquer software.

Vc está esquecendo que mensagens em bytes são protocolos E protocolos envolvem consenso. Java pode ler qualquer protocolo, mas não precisa ser amarrado aos protocolos que pode ler. é muit mais importante ter primitivos seguros que ter programação fácil
de protocolos binários (aka não OO).

Sim. C lhe dá liberdade. Java lhe dá portabilidade. Mas C não lhe dá a liberdade de portar a sua aplicação sem recompilação.
além disso essas coisa que enumera são o tipo de liberdade que não queremos.

É como o GOTO. Lhe dá toda a liberdade, mas é uma porcaria de instrução em programação estruturada.
Vai me dizer que não prefere programação estruturada ?

Java é acima de tudo estruturada. O seus objetivos são segurança e portabilidade. Os objetivos de C são fazer qualquer coisa
a qualquer preço.

Bom, tenho que discordar de você. O Java não trabalha com o tipo unsigned e, nem nas classes que você citou, nem nas classes do pacote NIO, há qualquer suporte para eles. É relativamente fácil implementar esse suporte, mas acho uma pena que a API nativa do Java não cubra isso já que, a principio, uma aplicação em rede deveria suportar hosts em qualquer linguagem. E os dados binários de vindos arquivos também poderiam ter sido gerados por qualquer software.

Vc está esquecendo que mensagens em bytes são protocolos E protocolos envolvem consenso. Java pode ler qualquer protocolo, mas não precisa ser amarrado aos protocolos que pode ler. é muit mais importante ter primitivos seguros que ter programação fácil
de protocolos binários (aka não OO).

Sim. C lhe dá liberdade. Java lhe dá portabilidade. Mas C não lhe dá a liberdade de portar a sua aplicação sem recompilação.
além disso essas coisa que enumera são o tipo de liberdade que não queremos.

É como o GOTO. Lhe dá toda a liberdade, mas é uma porcaria de instrução em programação estruturada.
Vai me dizer que não prefere programação estruturada ?

Java é acima de tudo estruturada. O seus objetivos são segurança e portabilidade. Os objetivos de C são fazer qualquer coisa
a qualquer preço.

Sim, mas em outras áreas, como o vini mesmo citou elas são necessárias. Para mim ajuda bastante.

C, C++ é uma linguagem que atua na esphera de uma eletronica complexa algo como projetar controladores de sistemas do tipo que você não recorra ao assembly, java tem um proposito que envolve um aspecto orientado integrações para soluções de outros fornecedores de tecnologia que por vias de sua Maquina Virtual , fazer o join entre modelos de negocios a projetarem soluções e inovações tecnologicas, então não podemos confundir propositos aqui.

juliocbq:

“Me parece que a maioria das “novas” linguagens de programação se encaixam em uma entre duas categorias: Aquelas de academia, com novos paradigmas radicais, e aquelas de grandes corporações, com foco em RAD e na web. Talvez esteja na hora de uma nova linguagem surgir da experiência prática de implementar compiladores.” – Michael

Você já começou mal em colocar o C++ e o C no mesmo balaio. Depois, desprezou o fato do C++ ser uma das linguagens com o maior número de bibliotecas integráveis que existe.
No segundo post, também ignorou o fato do C++ também encapsular a absurda maioria dos protocolos de rede, e ter as mais rápidas implementações de WebServices do mercado.

sergiotaborda:

Vc está esquecendo que mensagens em bytes são protocolos E protocolos envolvem consenso. Java pode ler qualquer protocolo, mas não precisa ser amarrado aos protocolos que pode ler. é muit mais importante ter primitivos seguros que ter programação fácil
de protocolos binários (aka não OO).

Não estou esquecendo, não.

Tudo isso que você falou não exclui o fato de ser extremamente difícil ler protocolos de mercado simples, como FTP, etc, que tem dados do tipo “unsigned”. Considero uma falha grave de projeto uma biblioteca feita para uso em networking não lidar com um tipo de dado tão comum. Aliás, não só networking. Muitos arquivos, como o wav, formatos de vídeo, cabeçalhos de imagem e de compactador tem informações importantes do tipo unsigned. Para ler isso no java, só fazendo mágicas de bits.

Uma biblioteca para ler coisas externas, como é o caso de I/O, já deveria encapsular isso.
Não se pode cair na inocência de que tudo vai ser escrito e lido em Java. Aliás, mesmo que se pense isso, é um pensamento infantil, já é muitíssimo pouco provável que Java se torne a única opção do mercado.

Note que não estou falando em colocar tipos novos na linguagem Java. Estou falando que o DataInputStream deveria ter um método chamado readUnsignedShort, que lesse 2 bytes da rede, e me retornasse um int, contendo o valor desse dado sem sinal.

sergiotaborda:

Sim. C lhe dá liberdade. Java lhe dá portabilidade. Mas C não lhe dá a liberdade de portar a sua aplicação sem recompilação.
além disso essas coisa que enumera são o tipo de liberdade que não queremos.

Foi por isso que conclui que na maior parte das vezes, o Java é mesmo uma boa opção. E citei diversos mercados onde não se encaixa no caso do “não queremos”. E o detalhe, não são mercados pequenos. Se ainda não acredita, basta olhar para o número de aplicações na sua máquina que ainda são desktop, já que usam muitos recursos de SO. Vai desde o seu próprio SO, até o webbrowser onde está lendo o que escrevi. Nada disso foi feito em Java.

sergiotaborda:

É como o GOTO. Lhe dá toda a liberdade, mas é uma porcaria de instrução em programação estruturada.
Vai me dizer que não prefere programação estruturada ?

De onde surgiu o assunto de programação estruturada?

sergiotaborda:

Java é acima de tudo estruturada. O seus objetivos são segurança e portabilidade. Os objetivos de C são fazer qualquer coisa
a qualquer preço.

O C++ tem dois objetivos que contrastam muito com a linguagem Java:

1. O C++ é uma linguagem criada para dar ao programador escolhas, mesmo que isso implique em ele fazer as escolhas erradas;
2. O C++ baseia-se no princípio de recursos mínimos: o programador não deve pagar por coisas que não use;
3. O C++ é projetado para suportar multiplos estilos e paradigmas de programação.

Nos artigos do Java, escutamos muito o “não implementamos esse recurso por que muitos programadores podem errar…”. Além disso, o Java reserva recursos por conta própria. O GC pré-aloca memória no heap, a linguagem Java cria diversos caches. Finalmente, o Java foca-se em um único paradigma, que é o orientado à objetos (embora haja também a possibilidade de programação reflexiva em menor escala), enquanto o C++ engloba 3 paradigmas: estruturado, OO e genérico.

Isso implica também no fato do C++ exigir um programador informado, responsável e disciplinado. Mas admito que seja difícil porque tradicionalmente não somos disciplinados. O que se torna ainda pior quando se trabalha em equipe.

Mas Vini, minha argumentação se baseia no fato de que é possível ler um unsigned de um DataInputStream url=http://java.sun.com/javase/6/docs/api/java/io/DataInput.html#readUnsignedShort%28%29[/url].

E anteriormente, você havia dito que seria possível jogar os dados de uma rede numa struct, o que eu discordo. Isso só é possível se você tiver certeza que as duas máquinas que se comunicam em rede são da mesma arquitetura. Se for o caso de um Sparc mandar dados para um Intel, então você terá que mudar o “endian” das variáveis um a um. Por isso que eu acredito que interpretação de bytes é um caso que pode ser feito melhor em Java.

Leonardo3001:

Note que não estou falando em colocar tipos novos na linguagem Java. Estou falando que o DataInputStream deveria ter um método chamado readUnsignedShort, que lesse 2 bytes da rede, e me retornasse um int, contendo o valor desse dado sem sinal.
Mas Vini, minha argumentação se baseia no fato de que é possível ler um unsigned de um DataInputStream(link)[/url].

É verdade, tinha me esquecido desse método. Mas ainda não tem métodos como readUnsignedInt e readUnsignedLong (e esse era justamente o meu problema).
Ironicamente, esses métodos não existem na java.nio também.

Leonardo3001:

E anteriormente, você havia dito que seria possível jogar os dados de uma rede numa struct, o que eu discordo. Isso só é possível se você tiver certeza que as duas máquinas que se comunicam em rede são da mesma arquitetura. Se for o caso de um Sparc mandar dados para um Intel, então você terá que mudar o “endian” das variáveis um a um. Por isso que eu acredito que interpretação de bytes é um caso que pode ser feito melhor em Java.

Sim, verdade. Mas eu estava falando de manipulação de bytes no geral, e isso é muito prático com arquivos, por exemplo (meu exemplo foi realmente infeliz). Entretanto, no java, você também só tem o benefício do DataInputStream se for Java com Java. Se for java com máquina Sparc rodando C, aí você também vai ter que girar bytes, e essa será uma tarefa igualmente difícil com DataInputStream. Claro que o Java.nio já implementa a classe prática ByteBuffer, que faz isso por você, assim como as funções práticas do boost::asio no C++.

Aliás, geralmente, falam mal da parte de rede de C++, sendo que a maior parte das pessoas só usou os métodos nativos do SO, ou os métodos derivados do C. Uma forma bastante primitiva de usar sockets em C++. Aí, claro, fica injusto comparar as bibliotecas canhão do Java, com a arquitetura usada pelos caras que faziam TCP ainda na época do Unix.

Na verdade, é bem comum em fóruns como esse, de Java, as pessoas relatarem suas experiências traumatizantes em C, e associarem as mesmas experiências ao C++. Em termos de analogia, é como vocês reclamarem do Java, porque insistem em usar uma versão 1.0 do compilador…

Enfim, não é o caso de vocês que já tiveram experiência profissional, mas tenho certeza que parte da culpa é das próprias faculdades. Um professor dá aula de C, mal e mal esbarrando nas classes, e chama aquilo de C++. O aluno vê tudo no braço, de uma maneira que não se programa desde da época que os computadores eram medidos em megahertz. Aí, no semestre seguinte o neguinho vê Java… lógico, vai achar o negócio a quinta maravilha do mundo, e associar a imagem do C ao C++. Detalhe que esse mesmo cara sai da faculdade usando DefaultTableModel, Vector e HashTable, porque, afinal, o professor de Java dele também é um pouco defasado…

Mas… voltando a rede, se querem ver como se faz sockets no C++ hoje em dia, vale a pena conferir essa biblioteca aqui:
http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio.html

Ali também não há chances de se esquecer de um hton e nem de um ntoh.

PS: Embora eu esteja defendendo bastante o C++ aqui, quero deixar claro que sou muito fã de Java. Aliás, continuo recomendando ele para a absurda maioria dos casos. Só que, infelizmente, muita gente ainda não conhece a forma moderna de se programar em C++, e acaba falando mal da linguagem sem qualquer conhecimento de causa. Vocês também vão achar tópicos meus falando sobre performance de Java em fóruns de C++, e explicando para eles que o Java já não é lento também desde que inventaram uma tal de hotspot vm…

Bom pode dar exemplo usando RestFull em C++, ou em OSB ?

É muito fácil fazer um backend RESTFul em C++.

Obviamente, você vai fazer o backend em C++ e deixar o front end para linguagens feitas para isso, como o JSP ou mesmo o Asp.net (é até possível fazer o frontend em C++, mas seria tão prático quanto faze-lo em java diretamente).

Depois, você integra o backend com o frontend usando componentes como esses aqui:
http://www.webtoolkit.eu/wt
http://www.hughes.com.au/products/libhttpd/
http://www.webdav.org/neon/
http://xaxxon.slackworks.com/ehs/html/

Existem milhares de pessoas fazendo web com C++ por aí (inclusive a Google). Só ignorantes acham que o mundo é restrito ao Java, ou que só o java tem uma comunidade ativa, que cria componentes gratuitos. O C++ tem uma comunidade igualmente grande, fóruns bastante ativos e desenvolvimento gratuito e de boa qualidade.

E também não se faz coisas do zero por lá. Há centenas de milhares de libs prontas para toda e qualquer necessidade.

Agora, se for para fazer web, volto a recomendar o uso de Java, a menos que sua aplicação web acabe recaindo numa das exceções que citei em posts anteriores. Vejam bem, em momento nenhum eu falei que devemos substituir tudo por C++, ou que é a melhor linguagem do mundo. Só estou tentando esclarecer que não é tão ruim quanto a imagem que a maior parte das pessoas tem dele. O desenvolvimento por lá amadureceu muito. Agora, ele continua sendo uma linguagem mais difícil do que o Java.

ViniGodoy:

É muito fácil fazer um backend RESTFul em C++.
Obviamente, você vai fazer o backend em C++ e deixar o front end para linguagens feitas para isso, como o JSP ou mesmo o Asp.net (é até possível fazer o frontend em C++, mas seria tão prático quanto faze-lo em java diretamente).

Aqui algo que vou explorar melhor ao assunto comentado.

Google usa Python para suportar sua Plataforma

E também não se faz coisas do zero por lá. Há centenas de milhares de libs prontas para toda e qualquer necessidade.
Agora, se for para fazer web, volto a recomendar o uso de Java, a menos que sua aplicação web acabe recaindo numa das exceções que citei em posts anteriores. Vejam bem, em momento nenhum eu falei que devemos substituir tudo por C++, ou que é a melhor linguagem do mundo. Só estou tentando esclarecer que não é tão ruim quanto a imagem que a maior parte das pessoas tem dele. O desenvolvimento por lá amadureceu muito. Agora, ele continua sendo uma linguagem mais difícil do que o Java.

… que é feita em C++.

… que é feita em C++.
E você esta no backend dessa sua observação na aplicação com C++, pois para chamada de serviço e somente com python mesmo sendo é uma linguagem de programação de alto nível, interpretada, imperativa, orientada a objetos, de tipagem dinâmica e forte.

… que é feita em C++.

E daí? JRuby é feito em Java. Aliás, é perfeitamente possível fazer um compilador que gere código nativo ou interpretador em qualquer linguagem. BTW, Lisp é feito em Lisp.

… que é feita em C++.

E daí? JRuby é feito em Java. Aliás, é perfeitamente possível fazer um compilador que gere código nativo ou interpretador em qualquer linguagem. BTW, Lisp é feito em Lisp.

Eu não falei que o Python era feito em C++, embora seja. Mas que a plataforma do Google, o backend, é em C++.

Ahem… e daí?

Só citei o google como um exemplo de empresa que usa o C++ em backend. E eles usam mesmo. Existem diversas linguagens fazendo front end sobre ela, como o Java (Orkut) e o Python. Mas não entendi… Porque da insistência em dizer que o python é tudo isso? Ninguém em momento nenhum está questionando os méritos do Python.

Nem inferiorizando qualquer linguagem.

Ahem… e daí?

Só citei o google como um exemplo de empresa que usa o C++ em backend. E eles usam mesmo. Existem diversas linguagens fazendo front end sobre ela, como o Java (Orkut) e o Python. Mas não entendi… Porque da insistência em dizer que o python é tudo isso? Ninguém em momento nenhum está questionando os méritos do Python.

Nem inferiorizando qualquer linguagem.

Só reforcei que ao contexto que a tecnologica tem ao seu papel, a liberdade do C++ em foco com a JVM ou melhor ainda as engines que rodam sobre a VM tais como JRuby, JPython que tem intercambeamento para usar padrões não alcançados, então precisamos entender cenários e sobre o que é backend ao C++, que não deixa de ter a sua importancia, mas não querer usar a ótica ao aspecto que ela não tem atuação, imagina usar C++ para IOC no Spring ao menos nunca ouvi falar.

Realmente. Aliás, até pela ausência de estruturas para reflexão, é uma tarefa árdua fazer injeção de dependências em C++. Ela é possível (até pq injetar dependências não obriga ter reflexão), mas é bem menos prático.

ViniGodoy:

Realmente. Aliás, até pela ausência de estruturas para reflexão, é uma tarefa árdua fazer injeção de dependências em C++. Ela é possível (até pq injetar dependências não obriga ter reflexão), mas é bem menos prático.

O C++ é uma linguagem multi-paradigma. Ela suporta os paradigmas orientado a objetos, estruturado e genérico (não suportada pelo Java);

Também não entendi pq sua sopa de letrinhas não são possíveis em C++. Todas elas são apenas métodos de desenvolvimento, todos independentes de linguagem, todos independentes da capacidade ou não de ter reflexão. E nenhuma delas depende de uma linguagem ser ou não orientada a aspectos.

Pegue por exemplo o TDD. É possível e anterior ao Java a prática de TDD em C++. Algumas bibliotecas já faziam TDD até mesmo em C. E onde aspectos são aplicados em TDD? Talvez facilite a implementação de um executor de testes automático. Mas nada que o uso de uma linguagem de script de suporte não torna possível também. Ou mesmo chamar estaticamente os métodos de teste dentro de um main (abordagem citada pelo fowler, no livro Refactoring, por sinal).

Todas as outras metodologias citadas por você são plenamente cabíveis em C++. Inclusive MDA, BDD e FDD. Talvez você esteja simplesmente ignorando o fato de que o C++ está presente em aplicações de desktop, inclusive com muito mais força que o Java, e que tudo isso não é só aplicável a web.

ViniGodoy:

O C++ é uma linguagem multi-paradigma. Ela suporta os paradigmas orientado a objetos, estruturado e genérico (não suportada pelo Java);

Também não entendi pq sua sopa de letrinhas não são possíveis em C++. Todas elas são apenas métodos de desenvolvimento, todos independentes de linguagem, todos independentes da capacidade ou não de ter reflexão. E nenhuma delas depende de uma linguagem ser ou não orientada a aspectos.

Pegue por exemplo o TDD. É possível e anterior ao Java a prática de TDD em C++. Algumas bibliotecas já faziam TDD até mesmo em C. E onde aspectos são aplicados em TDD? Talvez facilite a implementação de um executor de testes automático. Mas nada que o uso de uma linguagem de script de suporte não torna possível também. Ou mesmo chamar estaticamente os métodos de teste dentro de um main (abordagem citada pelo fowler, no livro Refactoring, por sinal).

Todas as outras metodologias citadas por você são plenamente cabíveis em C++. Inclusive MDA, BDD e FDD. Talvez você esteja simplesmente ignorando o fato de que o C++ está presente em aplicações de desktop, inclusive com muito mais força que o Java, e que tudo isso não é só aplicável a web.

JavaLivros:

ViniGodoy:

O C++ é uma linguagem multi-paradigma. Ela suporta os paradigmas orientado a objetos, estruturado e genérico (não suportada pelo Java);

Java é uma linguagem portável e C, C++ não é, posso ter java rodando em cenários multi-diferenciados, isso é a razão por que Java faz tanto sucesso, e a Oracle não pagou seus 7 bilhões, sem ter previsões para os seus negocios, motivo ai de ter uma tecnologia superior a muitas ai no controle de ESB usando Oracle Service Bus, é o que faz SOA realmente acontecer.

Também não entendi pq sua sopa de letrinhas não são possíveis em C++. Todas elas são apenas métodos de desenvolvimento, todos independentes de linguagem, todos independentes da capacidade ou não de ter reflexão. E nenhuma delas depende de uma linguagem ser ou não orientada a aspectos.

Se Ruby já existe mesmo antes do Java, porque não elegeram C++ para ser uma linguagem Ágil ?

Pegue por exemplo o TDD. É possível e anterior ao Java a prática de TDD em C++. Algumas bibliotecas já faziam TDD até mesmo em C. E onde aspectos são aplicados em TDD? Talvez facilite a implementação de um executor de testes automático. Mas nada que o uso de uma linguagem de script de suporte não torna possível também. Ou mesmo chamar estaticamente os métodos de teste dentro de um main (abordagem citada pelo fowler, no livro Refactoring, por sinal).

C++ trabalha junto ao Hibernete, então eu teria classe em C++ que são classes que persistem usando o modelo DAO, algo estranho nunca ouvi falar sobre o uso de C++ para essas condições, se tiver alguem que conheça pode se manisfestar.

Apesar de não rodar em máquina virtual, c++ é portável a todos os sistemas que você pode imaginar, além de outros cenários que java não é utilizado, como eletrônica digital.

Toda metodologia é cabível em qualquer linguagem. Tudo isso também foi implementado em pascal e n outras linguagens.

Java é uma linguagem portável, pena que a Sun só disponibilize VMs para 3 sistemas operacionais. Já no C++, você tem portabilidade para centenas de plataformas. Infelizmente, a portabilidade do C++ envolve mais disciplina no código e recompilação, ou seja, acaba sendo um pouco mais difícil que em Java. Entretanto, já escrevi jogos em SDL, que foram portáveis em aproximadamente 16 plataformas, inclusive algumas que o Java nunca sequer ouviu falar.

Bom, obviamente você não ouviu falar de muita coisa em C++…
Mas como volto a repetir pela ducentézima vez, o C++ é menos forte nos mercados do Java, não porque não seja possível usar as técnicas em C++, mas porque realmente é mais difícil. Tanto porque a linguagem exige a preocupação em detalhes que na maior parte das vezes são inúteis para esse tipo de aplicação (como a gerência de memória), quanto porque os profissionais Java são mais disponíveis e mais baratos.

“javalivros”:

No cenário Backend mas não que faça uso disso usando um Patterns de Controle, ou mesmo imagina usar anotação em C++ nunca ouvi falar disso também, as metodologias são efeitos de empregos aceitos em pró do Design de projetos e C++ é standAlone não vejo ser Domain ou ter MultiCamadas para tratar de modelos que não são compreensiveis ou fatos de que comprovem o uso até para essas novas adoções ao cenário Ágil, alguém já deu exemplos de Rails suportando C++ não lembro.

Patterns de controle são usados também em qualquer linguagem. Modelos multicamadas também.

Agora, anotações, não. Como falei, o C++ não implementa o paradigma reflexivo, então, não existem anotações. Você pode driblar isso como o hibernate fazia antigamente, através de arquivos xml, ou usando scripts escritos em Lua, Squirrel, ou qualquer outra linguagem do tipo.

Só lembrando. “Cenário ágil” não se restringe ao Rails. Novamente, você ignora a existência de outros tipos de aplicação, como as de desktop, onde o C++ é fortemente inserido. Para se ter um cenário ágil existe uma série de práticas, e como isso se trata de uma metodologia relacionada ao processo de desenvolvimento, pode ser aplicado em qualquer linguagem.

Só falta você dizer que C++ é a melhor solução em cloud-computing.

JavaLivros:

ViniGodoy:

Só falta você dizer que C++ é a melhor solução em cloud-computing.

http://news.cnet.com/8301-17939_109-10227150-2.html

Não é melhor nem pior. Mas o Google utiliza nos projetos de cloud computing.

Você pode escrever qualquer tipo de aplicação em qualquer linguagem.

O que tem a ver o conceito de cloud computing?
Na verdade, ele afeta pouco o desenvolvimento C++: http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=430

O que tem a ver o conceito de cloud computing?
Na verdade, ele afeta pouco o desenvolvimento C++: http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=430

sim. É uma das melhores.

O que tem a ver o conceito de cloud computing?
Na verdade, ele afeta pouco o desenvolvimento C++: http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=430

sim. É uma das melhores.

Algo que podemos concordar e acredito nisso também

The cloud computing technology today is similar to digital photography in 1990. The technology is promising and it’s certainly not about to vanish. However, it will take about a decade for cloud computing to become the default standard in a typical office. What does cloud computing mean for C++ programmers? I am inclined to conclude that cloud computing will not affect the C++ market much. You will see engineers shifting from client applications to server-side applications, and perhaps less focus on homemade GUI, but C++ is one of the better programming languages for server side programming – it has always been so. It doesn’t carry the excess baggage of spurious portability, for example, which means that you get a server side executable optimized for the target architecture instantly. You can look at it from a different point of view: whereas today a lot of efforts are dedicated to client-server compatibility, either in the form of special protocols (DCOM, CORBA etc.) or design choices, cloud computing will make these protocols less needed. Instead, the emphasis will be on software reliability, security and performance.

"

marcosalex:

Quem já programou pra Mainframe, de certa forma usávamos “cloud computing”, já que o processamento e armazenagem dos dados ficavam hospedados no servidor central. Até virtualização já existia com o famoso VMS.

As ondas de tecnologias vão e vem e o que é ruim hoje pode ser o padrão amanhã.

O Cenário de Virtualização esta em escalas onde ultrapassa o sentindo de virtualização, estamos falando em um novo cenários entre padrões e convergência.