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.
[quote=marcosalex][quote=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.
[code]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);
}[/code][/quote]
O ‘recurso’ do C# é uma chamada da API do Windows. O Delphi.net também tinha isso.[/quote]
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++;
}
}
}[quote=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.[/quote]
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:
- Construtores implícitos por default;
- Destrutores não virtuais de classes virtuais;
- 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).[/quote]
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)
[quote=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)[/quote]
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.
[quote=juliocbq][quote=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)[/quote]
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.[/quote]
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.
"
[quote=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++.[/quote]
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.
[quote=sergiotaborda][quote=juliocbq][quote=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)[/quote]
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.[/quote]
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.
[/quote]
Não é falha não, na verdade, é um recurso que te dá muita flexibilidade. Por exemplo:
[code]//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
}[/code]
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.
[quote=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.
[/quote]
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.
- O Java não deixa você escolher uma nova estratégia para alocação de memória;
- O Java não permite que você chame métodos nativos (JNI é código C / C++);
- O Java não permite que você trabalhe sem conversão na arquitetura mais otimizada do seu processador.
- 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.
[/quote]
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.
[/quote]
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.
[/quote]
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.
"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[quote=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 [/quote]
Compilador é bem o seu proposito de o que tem que fazer para os projetos embarcados que a linguagem C++ é necessária e faz muito bem na linha da Industria de Automação e Mecatronica veja ainda estamos a linha de um segmento que tem seu nicho e proposito, Java já atende outras cadeias de infraestrutura que encapsula desde procotolos TCP/IP e vai para Webservices entre outras features que C++, C nunca vão esta envolvida pois não são projetadas para esse Core e aceitação.