[quote=peczenyj]Acho estranho java ter tipos primitivos, porém nunca senti falta de fazer um swap de ponteiros, ate pq trato strings e numeros como objetos imutaveis.
[/quote]
True.
Nunca vi um caso que só fosse possivel se fazer com ponteiros (a nao ser o swap).
[quote=asaudate]Está correto em alguns pontos e errado em outros. Em Java, existem classes que permitem, sim, manipular diretamente a memória (burlando, assim, o mecanismo do GC). No entanto, isso está longe de ser considerado boa prática, já que deixa o programa inseguro (no sentido de permitir que um programa “invada” o espaço de outro). [/quote]Além das classes da sun (que não devemos usá-las), não conheço nenhuma classe que nos permita obter um endereço de memória e trabalhar com ele.
E em relação a deixar o programa inseguro, se o programador fizer as verificações “necessárias”, ele pode controlar isso. Nesse ponto eu tenho que concordar com ele que o Java não confia no programador. Mas ao mesmo tempo, ao meu ver, isso faz com que o programador confie mais na linguagem.
Ídem sobre o tamanho dos arrays.
[quote=asaudate]Quanto ao exemplo da herança múltipla, essa é uma questão interessante. Existem manuais do próprio C++ que desaconselham o uso de herança múltipla, já que isso pode fazer o compilador “se perder” (o que, inclusive, faz com que se considere o C++ como linguagem “não-assertiva”, ou seja, não dá para garantir o mesmo resultado sempre. Lí sobre isso, inclusive, numa Java Magazine, citada pelo Osvaldo Doederlein. Tentei achar o link para postar aqui mas não achei, desculpe). Ou seja, o melhor a se fazer é, na verdade, garantir a confiabilidade da herança múltipla ou permitir somente herança simples. A equipe do Java optou pela segunda opção. São escolhas [/quote]Então, ainda não vi algum uso prático para herança múltipla, por essa razão, nem posso dizer se é bom ou mal o Java não ter isso.
[quote=renamed]Ponteiros explícitos fazem diferença em alguns momentos, na famosa função de swap de inteiros por exemplo.
view plaincopy to clipboardprint?
1. void swap(int *p1, int *p2){
2. int aux = *p1;
3. *p1 = *p2;
4. *p2 = aux;
5. }
void swap(int *p1, int *p2){ int aux = *p1; *p1 = *p2; *p2 = aux; }
Sinto falta disso em java, você não consegue manipular tipos primitivos na memória, mas isso não é fator preponderante para se abandonar uma linguagem.
Conheço várias pessoas que amam c++ e temos boas “discussões” sobre isso, cada um tem seu ponto de vista.[/quote]Se são tipos primitivos, qual a vantagem de se fazer isso com ponteiros? Se me disser que é pela “economia de memória”, temos pelo menos 1GB de RAM na maioria dos computadores, e para contar os endereços de memória, temos que usar pelo menos uma variável do tipo inteiro (32 bits), sendo que nos SOs de 64Bits, sempre será gasto 64bits para um ponteiro. Ou seja, ao invés de economizar memória, fazendo isso com um int, você estaria praticamente dobrando a quantidade de memória que precisa para fazer essa operação usando ponteiros… (hoje praticamente não temos SOs de 16 bits…).
[quote=deniswsrosa]Sem contar que são poucos os programadores que implementariam em C uma solucao caseira para gerencia de memória melhor que o GC do Java.
[/quote]
Concordo contigo sobre a liberdade(que ela sempre é relativa, nunca vamos ter total liberdade, e acrescento que o nosso referencial de liberdade no momento é o assembler). E sobre as soluçoes em C que gerencia a memória melhor, ainda acrescento, quero ver algum programador C++ implementar um HashTable, HashMap, (e outras trocentas classes) etc… tão eficientes quanto os do Java, e ainda ter essa praticidade que temos.
[quote=Leonardo3001]Não é necessário ponteiros explícitos pra mapear arquivos. O Java possui abstrações em alto nível pra isso, dentro do pacote java.nio; é a classe MappedByteBuffer.
Outra, o “endereço” de arquivo (termo correto: índice) não tem nada a ver com endereço do disco rígido. Índices são uma abstração do sistema operacional. [/quote]Essa foi exatamente a classe que indiquei para ele sobre esse argumento, rsrsrsrs
E quando disse “endereço”, me referi que a técnica MMAP mapeia um local no HD como se fosse um endereço na memória, por isso não precisamos alocar um buffer, por exemplo, para cada operação com um arquivo.
[quote]De qualquer maneira, velocidade é irrelevante. O que é melhor: uma rotina que executa em 0,001 segundos ou uma que executa em 0,005 segundos? Mudando um pouco a frase: você pagaria, sei lá, três vezes mais por um software para que ele traga resultados em 0,001 segundos ao invés de 0,005?
No mundo de hoje, software é limitado por I/O ou por rede, não por velocidade de CPU. Só pra ter uma ideia, imagine um software hipotético onde você mandaria um XML pela rede: você conseguiria maior velocidade se zipar o XML antes de enviar e dezipar após recebê-lo. O processamento é maior, mas a latência em rede menor. [/quote]
eu trabalho com volumes enormes de dados, e nesse caso faz diferença 5x. Mas até onde eu usei, o Java não apresentou nenhuma lentidão. Sempre dentro do esperado e, quando necessário, implementa-se uma pequena biblioteca em outra linguagem e chamamos essa biblioteca no Java (para ganhar desempenho). Um bom exemplo de grande demanda de processamento é rodar um modelo estatístico que faz diversas iterações testando possibilidades. (mas nesse caso, o Java teve um desempenho melhor pelo otimizador de estruturas condicionais e repetitivas dele)
Parece o exemplo que eu dei…
E isso sem falar que as classes que extendem Collection tem uma otimização melhor que um array para pesquisas e para obter elementos.
Ps: Se querem fazer trocas referências em java, não seria melhor usar uma classe que implementa o tipo primitivo? (ainda que eu não veja vantagem em trocar as referências dos tipos primitivos)