M4ck wrote:
> S� complementando: o Kernel do Linux � escrito em assembly e C,
> n�o h� suporte a OO nele, isto �, voc� n�o pode escrever um
> driver para Linux em C++ e coloc�-lo como m�dulo ao kernel.
Dia desses o Arnaldo falou que o kernel Linux era programado 'de forma'
OO. Queria saber mais detalhes disso. Arnaldo?
> Apesar de ser um aficcionado do C++ n�o vejo ela como uma
> evolu��o do C. Na verdade � uma linguagem que foi implementada a
> partir do C, utilizando a orienta��o a objetos. Os homens que
> inventaram o C tiveram uma inspira��o divina... n�o h� como
> melhor�-la :-)
A C++ foi criada como o 'C com objetos' e foi denominada dessa mesma
forma pelo proprio Stroustroup at� ser finalmente renomeada como C++
depois de um monte de coisas q jogaram na linguagem de qqer jeito.
Segundo muita gente, a C++ foi um hack horroroso q tentou tornar a C uma
linguagem OO e terminou criando um monstro. Hj, ninguem sabe se eh uma
linguagem procedural, OO, funcional, whatever. A STL s� fez piorar isso.
> J� C# **n�o �** uma evolu��o. N�o vou dar minha opini�o para n�o
> criar uma "flamewar" aqui :-) N�o tenho nada contra, mas, se o
> colega que teve a d�vida quiser partir para OO, deve estudar C++
> ou Java (ou os dois), e depois estude o C# que entender� o que
> eu digo.
Cara desculpa, mas vc est� falando uma temeridade. :)
Nao sei se eu posso me enquadrar na sua categoria, mas eu conhe�o Java e
nesses dois meses estudando C# a minha opiniao � de que a C#, embora
ainda nao seja minha linguagem preferida, *�* de fato uma evolucao.
Fa�amos uma breve comparacao entre as duas:
Vamos discutir OO entao. Java � OO, mas nao totalmente pois ainda usa
tipos primitivos. Em Java, um int � um int e acabou. Na C#, um int e
todos os outros tipos sao derivados de um ancestral comum q � um objeto.
Pq isso � pr�tico? Por exemplo, para converter um tipo para o outro em
Java eu teria q declarar uma variavel com o tipo a converter (digamos,
char), chamar um metodo de outra classe para converter esse tipo
(Integer.parseInt(), por exemplo), e a partir daih pegar o valor de
retorno desse metodo e jogar de volta para uma segunda variavel
redeclarada.
em Java:
char a = "2";
int b = Integer.parseInt(a);
na C#:
char a = "2";
int b = a.ToInt();
Como a variavel 'a' � um tipo primitivo em Java, o objeto Integer teria
que ser instanciado (transparentemente pois faz parte do balaio padr�o
de java.lang), e seu metodo parseInt() chamado gerando overhead, pois
teria q alocar memoria para a variavel, alocar mais memoria para o
objeto q contem o metodo conversor, e executar o metodo conversor. Na
C#, 'a' � um tipo OO e logo � tambem um objeto com seus proprios metodos
q sao alocados em memoria durante o runtime, logo nao � preciso chamar
terceiros para efetuar a conversao, entao ele age com a propria memoria
alocada para o 'objeto' a. Falando em conversao, Java n�o tem
boxing/unboxing, logo eu teria q fazer conversao manual de tipos por
valor e tipos por referencia, enquanto na C# isso � autom�tico. Voltando
a falar em tipos, em Java nao existem tipos unsigned.
Java n�o tem defines. Logo, nao tem compilacao condicional a nao ser q
vc use produtos de terceiros.
Java nao faz switch com strings.
Java n�o tem atributos ('definicoes' paralelas em tempo de execucao de
metodos. Por exemplo, um mesmo metodo pode fazer duas coisas diferentes
durante o runtime dependendo de seu atributo q � checado via reflex�o).
Nem passagem por referencia. Nem enums. Java tb nao tem propriedades
verdadeiras, pois vc tem q emular com 'get' e 'set', implicando em
escrever dois metodos diferentes.
Java n�o tem delegates. Delegates servem para a maioria dos usos dos
ponteiros das outras duas linguagens, ou seja, vc pode usar um delegate
para criar um 'apontador' para o codigo de uma segunda classe. Em Java,
vc teria q instanciar um objeto manualmente, consumindo mais memoria e
linhas de programacao.
Java n�o tem structs. Mas structs s�o mera curiosidade hist�rica q
linguagens OO tornam obsoletas. Java tb nao tem goto. Gra�as a Deus :)
Java n�o tem foreach. Nem sobrecarga de operadores. Nem metodos com
numero variavel de parametros.
O namespace de um pacote Java est� 'travado' no seu arquivo de
declaracao.
De fato, como linguagem a C# *�* superior. Os unicos problemas q eu
encontro sao de ordem pr�tica, como nao existirem implementacoes para
plataformas de deployment comuns, e ainda estar em beta. Sim, Java
continua sendo minha linguagem preferida, at� pq ateh agora soh fiz
brincadeiras em C# :)
Quando usar Java: Hoje, se vc precisa rodar sua aplicacao em plataformas
nao suportadas pela C#, e precisar de um framework maduro com diversas
implementacoes como o J2EE, ou portar sistemas legados, ou programar
para bugigangas tipo palmtop. Mais tarde, pelos mesmos motivos :). Java
1.4 ou uma versao posterior, dependendo do JCP, dever� vir com coisas
muito interessantes como asser��es embutidas na linguagens, e os
benditos atributos.
Quando usar C#: Hoje, qd a linha de deployment do seu programa soh passa
por produtos Microsoft. Mais tarde, qd existirem implementacoes de C#
para outras plataformas e frameworks funcionais (acreditem, nao vai
demorar muito. Foi assim com o COM, o SOAP, e tudo mais q todo mundo
dizia q nao ia dar certo)
Mas se no final, a C# n�o � uma evolucao pelo simples fato de que �
feita pela Microsoft, entao... j� n�o � comigo pois nao sei como refutar
esse tipo de argumento :))))
--
thiago pimentel | mad scientist | [EMAIL PROTECTED]
Assinantes em 02/12/2001: 2402
Mensagens recebidas desde 07/01/1999: 144363
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
