Ir para o conteúdo
nunopicado

C++ vs Java vs Delphi - Sintaxe e Estrutura

Mensagens Recomendadas

nunopicado

Antes de mais, isto não é uma deixa para mais uma guerrinha de tamanhos - "A minha é a maior" aqui não interessa nada!

Apenas um artigo interessante sobre as diferenças (e semelhanças) de sintax e estrutura entre estas três linguagens OOP.

http://www.marcocantu.com/papers/ooplang.htm


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
pwseo

Estive a ler isso com alguma profundidade, mas confesso que não tenho os conhecimentos necessários para opinar sobre as secções de aspectos mais avançados da programação orientada a objectos.

Ainda assim, acho que vale a pena referir que esta comparação foi feita há imenso tempo atrás. Desde então, todas as três linguagens referidas mudaram substancialmente (ex.: C++ agora suporta multithreading, Pascal tem programação genérica, Java é muito mais eficiente e também tem programação genérica, etc).

No entanto, é um artigo bom para se compreender as diversas abordagens possíveis a este paradigma, embora o inglês não seja bem o forte do autor.

Acho que valia a pena ter focado um pouco mais a ausência de um sistema de módulos em C++ (algo que herdou de C, mas que é várias ordens de magnitude mais problemático que em C). Neste aspecto, Pascal, Java e quase qualquer outra linguagem razoavelmente madura consegue ser melhor (e é aqui que começam muitos dos problemas com os tempos de compilação).

Algo que também não foi muito falado foi a grande facilidade com que se utilizam as APIs do Windows (uma vez que o artigo visa o Delphi) a partir das diversas linguagens. Sendo o Windows primariamente programado em C++, é natural que esta linguagem seja beneficiada nesse aspecto, mas Delphi não lhe fica atrás. De facto, quando eu utilizava Windows e Delphi, recorria frequentemente à documentação oficial (C/C++) da API do Windows e conseguia utilizar no Delphi sem grande problema, algo que poderá não ser tão fácil em Java (não sei se é ou não, mas em Delphi era canja!).

No entanto, isto era um artigo sobre OOP, pelo que este tema poderia ficar um pouco fora do âmbito.

Seria interessante ver um artigo semelhante mas que comparasse as versões mais recentes destas linguagens :)

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nunopicado

Concordo, um mais recente seria melhor.

Mas não encontrei nenhum suficientemente imparcial. ;)

A nivel das API's, sem duvida, Delphi é canja. Aliás, muitas vezes, quando preciso e não encontro por algum motivo em Delphi, vou directamente à fonte, à documentação da Microsoft da MSDN, e aplico ao Delphi com facilidade.

Ainda há pouco tempo o fiz, quando quis alterar o código do Cu5co dos webservices para abrir um certificado sem ter de estar instalado no Windows.

Mas é verdade, isto já sai do ambito do artigo, que era quase exclusivamente sobre OOP.

Mas é curioso pensar como três linguagens, cujos defensores mais acérrimos andam sempre à batatada para ver qual a melhor, têm tanto em comum, a nível da sua interligação ao paradigma OOP.

O tempo de um programador seria bem melhor aproveitado se este o utilizasse a programar, na linguagem que melhor se aplicasse ao projecto em questão, do que a medir forças.

No fundo estamos a falar de 3 linguagens derivadas de outras duas, que têm por sua vez uma forte interligação entre elas: C e Pascal.


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
pwseo

Pois, é normal que eventualmente as ferramentas sejam convergentes, uma vez que são utilizadas para o mesmo fim. Parecem ainda mais convergentes quando comparamos uma linguagem de outro paradigma (do funcional, por exemplo). Aí sim é existem diferenças grandes!

Como disseste, é difícil encontrar um artigo imparcial sobre estas coisas, e quando alguém escreve, puxa sempre para o seu lado, claro.

Quanto a utilizar ou não a linguagem mais adequada, isso terá sempre entraves porque nem todos os programadores querem aprender a melhor linguagem para determinado trabalho (e muitas vezes recusam-se a saber mais que uma única linguagem, utilizando-a para tudo), e há também a questão do custo... aprender uma linguagem está associado a custos monetários avultados nalguns casos, especialmente quando além da linguagem é necessário aprender todo o tipo de APIs relacionadas.

Sim, é a atitude correcta, mas pouca gente a põe em prática.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nunopicado

Claro, mas aí depois também se podem fazer cedências controladas...

Se uma ferramenta até é ligeiramente melhor que outra, mas os meus conhecimentos da outra são bem melhores do que da uma... É preferivel fazer na que estamos mais à vontade, exactamente para evitar os tais custos extra (e custos podem ser monetários ou simplesmente de tempo).

O que é preciso é não tapar o sol com a peneira, e porque sabemos mais de uma determinada linguagem, não vamos dizer que a outra não presta...


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
KTachyon

Pah, em primeiro lugar, é um artigo que foi actualizado a última vez em 1997. As linguagens já evoluíram bastante desde então. O autor refere o Objective-C no artigo, mas na altura o impacto dessa linguagem não era tão extensivo como o de hoje em dia. E o Objective-C está a milhas do C++.

Mas há algumas coisas que o autor diz que são muito boas (em comparação), mas não refere os detalhes da sua utilização. Por exemplo, sem conhecer Object Pascal assim tão bem, li a secção "Recycle Bin", onde diz:

OP: Object Pascal, instead, has no garbage collection mechanism. However Delphi components support the idea of an owner object: the owner becomes responsible for destroying all the object is owns. This makes handling the object destruction very simple and straightforward.

Isto parece ser muito fixe se esquecermos o pormenor de que é normal passar referências para objectos entre vários objectos. Nesse caso, quem é o owner? E, se o owner for destruído é possível que esse objecto referenciado passe a ser owned por outro objecto antes de ser feita a destruição? No fundo, como se lida com um objecto que tem um owner mas que tem múltiplas strong references? Podemos tornar esse objecto global (sendo o owner o objecto que corresponde à aplicação), mas parece-me que isso é uma má resposta ao problema. Penso que aqui se mostra que o autor não é imparcial :)

Para além disso, se tivermos uma factory (http://en.wikipedia.org/wiki/Abstract_factory_pattern), queremos que o owner do objecto seja o objecto que chama a factory e não a própria factory, que cria o objecto. Nesse caso precisamos de lidar com passagem de ownership em vez de lidarmos com os outros detalhes que as outras linguagens implicam (Garbage Collecting e Reference Counting).

Claro que Garbage Collecting não é a coisa mais flexível (ou nada flexível), mas em termos de simplicidade em lidar com a libertação de memória, que é a comparação que o autor aparenta estar a fazer, o GC é o mais simples. Mas, tendo em conta performance, sempre me pareceu que Reference Counting fosse a melhor abordagem.

Editado por KTachyon

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
pwseo

Relativamente ao caso da ownership, penso que o autor está a falar de um caso específico: componentes da GUI. Nesse caso faz sentido o mecanismo no qual quando destróis uma Form, os seus controlos são também destruídos. E mesmo assim isto só é automático para os controlos definidos visualmente no editor de GUI. Quando crias um objecto que represente um controlo tens que explicitamente passar o owner (se assim quiseres) para que o mecanismo referido funcione.

Nos restantes casos (objectos que não descendam de TControl ou TWinControl, se não estou em erro) não existe noção de ownership nenhuma a menos que explicitamente definida pelo programador nos constructors e destructors. Ou seja, nem sequer é uma questão de linguagem mas sim algo desenvolvido em cima da linguagem.

De qualquer modo, realmente o autor fica aqui com um argumento sem grande significado, tens razão. Não tinha visto esta parte com atenção.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nunopicado

Assim de repente não fiquei com essa ideia... Ou melhor, não fiquei com a ideia que ele se referia a um substituto.

Ele está, parece-me, a dizer que nesse ponto, OP tem uma desvantagem em relação às outras por não ter um GC. Fala no entanto da alternativa possível, não afirmando sobre se é melhor ou pior. Refere apenas que com este método, torna-se simples destruir um objecto.

Pelo menos foi assim que percebi!


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
KTachyon
Ele está, parece-me, a dizer que nesse ponto, OP tem uma desvantagem em relação às outras por não ter um GC. Fala no entanto da alternativa possível, não afirmando sobre se é melhor ou pior. Refere apenas que com este método, torna-se simples destruir um objecto.

Retain counting != Garbage collecting

No fundo não considero um substituto. Isso já o retain counting faz, mas melhor:

No fundo, de cada vez que queres uma referência para um objecto, incrementas o retain count, quando deixas de utilizar esse objecto (na verdade, essa referência), decrementas o retain count. Quando o retain count fica a zero é porque ninguém o está a utilizar, portanto o objecto pode ser removido da memória.

Este conceito funciona porque tu não precisas de saber quem é que tem uma referência para aquele objecto. Só precisas de saber que, se num contexto já não precisas do objecto, só tens que decrementar o retain count.

Ou seja, em vez de teres um owner, tens vários. Quando todos os owners deixam de precisar do objecto, este sai de memória.


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
pwseo

Mais uma vez, em Delphi a questão da ownership funciona apenas com objectos descendentes de TComponent, os quais não têm mais que um owner. Quando o seu owner é destruído, o objecto (ou melhor, o componente) é também destruído, o que facilita imenso a criação e gestão de GUIs. Isto não tem nada a ver com a linguagem em si, mas sim com a forma como a TComponent foi implementada (podíamos fazer o mesmo em C++, Java, etc).

Em Delphi há também outras formas de gestão de memória: os interfaces são reference-counted, e há garbage collection para certos tipos de dados (ex.: strings, arrays dinâmicas).

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
KTachyon

Nem eu disse o contrário, só estava a comentar a frase do nunopicado.

De facto, para uma interface no Mac ou no iOS (e mesmo para outros sistemas) desenvolvida com Objective-C, a gestão é tipicamente essa, com a vantagem de que podes ter mais que um "owner" para o mesmo objecto/componente na interface e permitir que continuem a ser geridos sem qualquer input por parte do programador (com Automatic Reference Counting).

Esse comportamento do Delphi nem sequer é muito complexo de implementar sem qualquer recurso a GC ou RC. Simplesmente "assume-se" que não há nenhuma referência para o objecto para além do owner e, portanto basta chamar a primitiva de libertação de memória destes componentes quando o owner é destruído.


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
pwseo

Esse comportamento do Delphi nem sequer é muito complexo de implementar sem qualquer recurso a GC ou RC. Simplesmente "assume-se" que não há nenhuma referência para o objecto para além do owner e, portanto basta chamar a primitiva de libertação de memória destes componentes quando o owner é destruído.

Esse comportamento é implementado em Delphi sem qualquer recurso a GC ou RC. Quando inseres um TComponent (TButton) noutro TComponent (TForm), o segundo acrescenta o primeiro a uma lista interna que é percorrida no seu destructor, para destruir também os componentes que contém. Nada de GC ou RC (estes são utilizados noutras partes da linguagem).

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
KTachyon

Eu estava a falar na implementação noutras linguagens. Aquilo que queria que fosse lido (entre linhas) é que essa pseudo-solução nem sequer pode ser considerado um desafio tecnológico.

Editado por KTachyon

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
pwseo

Concordo, implementar isso não é sequer um desafio -- já tinha dito acima que podemos fazer isso noutras linguagens e até descrevi o comportamento que voltaste a mencionar.

De qualquer modo, não percebi que (entre linhas) estavas a falar de outras linguagens; pareceu-me que estavas a dizer que esse comportamento podia muito bem ser implementado em Delphi sem GC ou RC, como se a implementação actual utilizasse GC ou RC. Apenas reforcei que não é o caso.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
KTachyon

Mas não foi o que eu quis dizer. Até porque não faz sentido nenhum que tenhas que utilizar qualquer um deles para fazeres esse tipo de gestão de memória, tal como disse naquilo que disse a seguir.

De qualquer forma, não vejo grandes vantagens nisso em relação ao RC (só vejo desvantagens). E muito menos em relação ao ARC.


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
pwseo

Pois, por isso mesmo é que estranhei o post e reforcei que não eram usados GC ou RC (não faz sentido nenhum).

Penso que o autor devia ter sido mais explícito neste aspecto; dizer que em Object Pascal é simples gerir a memória dos objectos é uma simplificação excessiva, visto que a gestão é feita manualmente. Da forma que escreveu, incluiu os defeitos de Java e C++ e esqueceu-se de referir "toda a verdade" sobre Object Pascal relativa a esse tópico, dando uma falsa sensação de superioridade neste aspecto.

Editado por pwseo

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.