🚀 go-pugleaf

On Mon, 25 Jan 1999 18:18:24 +0100, in es.comp.lenguajes.java Jonathan Revusky
wrote:

>Es incorrecto obviamente. Pero no s� si es ilegal. Quiz� se describa
>como ilegal en la especificaci�n, pero no me parece un argumento muy
>potente en todo caso.

No. En la spec (tanto C como C++) no hay _nada_ referente a control de l�mites.
Todo eso se obvi� por razones de velocidad. Esta es una de las principales
razones porque la velocidad de un ejecutable en C pulveriza java en muchos
aspectos. Si quieres control de l�mites usa C++ y una librer�a de clases con
soporte para estos, para algo Stroustrup invent� overload.

>Incluso si es oficialmente ilegal, carece de significado. Si algo es
>ilegal y no hay absolutamente ning�n mecanismo para "imponer la ley", su
>ilegalidad es m�s bien te�rica. Por ejemplo, si hay un limite de
>velocidad en una carretera de 100 km/h pero no hay ninguna vigilancia y
>nunca te multan, ese l�mite no tiene importancia pr�ctica (por lo menos
>en un pa�s latino -- un pa�s n�rdico es otra cosa ;-). (Por cierto, me

Esta comparaci�n es absurda.

>La portabilidad en C es algo:
>
>(1) definido de manera muy limitada

Simplemente no est� definida c�mo tampoco lo est� la de java. En cuanto a
portabilidad no hay diferencias en las spec de java y C. Tampoco hay una raz�n
t�cnica por la que un fuente en C/C++ no pueda ser 100% portable a otra
plataforma. Todo esto son temas dependientes del compilador y por ext de quienes
lo hacen. La cuesti�n que java sea m�s portable es simplemente que SUN a
supervisado todos los portings no permitiendo llamar a nada 'Java' si antes no
ha pasado sus controles. En C/C++ tenemos que, por un lado, C es un lenguaje
_muy_ antig�o y as� sus compiladores, de los cuales hay much�simos y de
infinidad de compa��as. Y por otro, de C++ no hab�a un standar aprobado hasta
principios del a�o pasado �C�mo puede ser portable un lenguaje que no ha
terminado de desarrollarse?

Ten en cuenta que hay fuentes/programas Java no portables, sin ir m�s lejos
_serias_ incompatibilidades entre los de norton y el jdk de unix. �Significa
esto que Java no es portable? No, simplemente significa que hay implementaci�n
que difieren del resto.

Con todo esto quiero decir que: �Basta ya de discursiones absurdas sobre
lenguajes!! Cada lenguaje sirve para lo que sirve y punto. Hay infinidad de
aplicaciones que ser�an sinplemente imposible hacerse en Java y hay infinidad de
otras en que Java es el candidato ideal.

Yo por mi parte todav�a no he visto en un x86 una aplicaci�n _grande_ hecha en
Java que consiga un grado de eficiencia (velocidad) suficiente. Y te lo dice
alguien que hace poco program� una aplicaci�n para un PicoJava. En un procesador
as� la apps java vuelan.
>
>y 
>
>(2) no tiene mucho significado pr�ctico.

Aja, por eso ayer se public� el kernel de Linux v2.2 y lo puedes compilar en
x86, Alpha, mk8, ARM... claro que esto no tiene significado pr�ctico.


>En el contexto de un foro sobre lenguaje Java, yo creo que es bastante
>justo decir que "el C no es realmente portable". O bien, dicho de otro
>modo, la portabilidad en el mundo C/C++ est� definida de forma tan
>limitada, que no es lo que estamos llamando portabilidad en el mundo
>Java en un principio.

Pues m�s de lo mismo. Tu afirmaci�n lleva a decir que Java tampoco es realmente
portable. Si me dices que tal fuente para el compilador X no es portable al
compilador Y pues vale, totalmente de acuerdo. Porque si seguimos tu
razonamiento el lenguaje m�s portable es Clipper, todos los compiladores de
Clipper son 100% compatibles, incluyendo el de unix.

>Bueno, a m� lo que me da en la nariz es lo siguiente. En el comit�,
>tienes representantes de los principales fabricantes de compiladores C,
>que tienen muchas implementaciones incompatibles, y en vez de realmente
>ponerse de acuerdo para hacerlos verdaderamente compatibles, redefinen
>la palabra "compatible" o "portable" -- porque es m�s f�cil hacer eso
>que hacer que las cosas sean compatibles o portables de verdad. 
>Supongo que es una interpretaci�n c�nica de todo eso. Si eso
>escandaliza, lo siento.

No me escandalizo pero no es as�. Por ponerte un ejemplo, cuando sali� BC5
hab�an claras incompatibilidades con VC. �La raz�n de esto? Pues simplemente que
meses antes se hab�a sacado un nuevo C++ draft y el BC se ajustaba a este. Ahora
que la cosa se ha estabilizado C++ ambos compiladores son 100% compatibles (con
la opci�n ansi) con tal grado que puedes programar perfectamente MFC bajo BCB.

>Para m�, el C no tiene arrays. Para ser un array, debe tener un
>principio y un fin. Dicho de otro modo, un array tiene una dimensi�n. En
>ese sentido, el Java tiene arrays y el C no los tiene. Tiene sintaxis de
>arrays implementada con punteros.

Pues como yo lo entiendo C tiene arrays, en C++ tienes la opci�n de usar arrays
con control de l�mites y Java s�lo tiene arrays con control de l�mites.

>"Hay fans de otros lenguajes que afirman que en C, los arrays, punteros,
>y cadenas, es todo la misma cosa. Si es verdad que, bajo ciertas
>condiciones, esas tres cosas son intercambiables, bla bla bla, las tres
>cosas son elementos distintos...
>
>�No es simplemente m�s misticismo, que s�lo los te�logos entienden?

Pues ser� un te�logo ?:-) pero no son la misma cosa, lo dice en el estandar ;-).

>En el fondo, lo que est�s describiendo es la libertad de acceder a
>memoria de forma inv�lida. Est�s hablando de la libertad de tratar
>cualquier elemento -- un array, cadena, o en C++ un objeto -- como un
>puntero crudo. Tengo serias dudas de que uno deber�a *querer* hacer eso.

Umm �Has programado alg�n driver o similar? Normalmente almacenas muchas
structuras como structs o arrays y a veces es indispensable poder hacer
indirecciones en estas estructuras basadas en valores runtime. Muchas veces
llegas a sobrepasar l�mites de estructuras con un puntero porque sabes
exactamente lo que tienes despu�s y usar una sentencia estructurada generar�a un
c�digo menos eficiente.

>C". La "supuesta eficacia de C" es algo que procurar� refutar luego,
>cuando tenga un momento.

Aja, pues da benchmarks.

(for USENET postings) Delete 'CUTTHIS' from my e-mail to reply.
        -----------
        Enrique I.R.
 Freelance Software Developer.
   Gran Canaria. Spain.
-(linuxnet,hispano)#linux->CtrInt-