🚀 go-pugleaf

"Enrique I.R." wrote:
> 
> 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.

Enrique, si supieras leer y seguir un debate, sabr�as que lo de arriba
es lo que *yo* manten�a. Me consta (como, me parece, que te consta a ti)
que sobreparasar los l�mites de un array *no* es "ilegal" en C. Es
Guillermo que manten�a que eso era "ilegal". 

Es legal y produce un comportamiento indefinidio -- es decir que no es
portable.

> 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. 

C claramente tiene algunas ventajas en rapidez de ejecuci�n, pero NO por
eso. De hecho, lo de la verificaci�n de l�mites no tiene nada que ver
realmente. Mira:

int[] arr = new int[1000000];
for (i = 0; i < arr.length; i++) {
  arr[i] = algo;
  ...etcetera...
}

�T� crees que en el c�digo arriba, que se verifican los l�mites del
acceso un mill�n de veces? �Y que verifica si (arr!=null) otro mill�n de
veces?

Seg�n lo que has dicho, me parece que no sabes la respuesta. As� que te
lo dir�: 

La respuesta es que no.

Ya que se puede demostrar est�ticamente que no es necesario, la
verificaci�n no se hace. Incluso los compiladores JIT como el de
Symantec llevan a cabo esta optimizaci�n en la marcha. Se llama
"loop-invariant optimization". Es muy com�n. Si tienes un compilador que
no lo hace, pues cambia de compiladores.

Entonces, el c�digo de m�quina que genera no tiene porque ser menos
eficaz que el c�digo generado por el caso equivalente en C. (Me parece
que hay una verificaci�n necesaria que ocurre una vez en el c�digo Java,
se verifica una (:-)) vez que (arr != null). 

Me parece que cualquier caso interesante ocurrir�a dentro de un bucle
as� y un compilador bueno (o medianamente competente ya que esto es
coser y cantar a estas alturas) prescindir�a de la verificaci�n de
l�mites.

Conclusi�n: el hecho de que el C no tiene seguridad y te permite
sobrepasar los l�mites de un array no ofrece NINGUNA eficacia en cambio.
(Hay otras cosas que pueden tender a hacer que el C sea m�s r�pido, pero
esto... NO.)

> Si quieres control de l�mites usa C++ 

O Java.... Pero un momento. �Claro que quiero control de l�mites! No
tiene ning�n coste en ning�n caso importante. �Claro que quiero un
lenguaje moderno que me da garant�as sobre los accesos inv�lidos a
memoria! �C�mo puedes NO querer eso? �Estamos en 1999! �Por qu� deber�a
estar trabajando con un lenguaje tan primitivo que no tenga algo tan
b�sico? �Para ser un verdadero macho? (No estoy hablando de comparaci�n
C-Java, estoy comparando algo primitivo hasta un punto absurdo, con algo
que tenga un m�nimo de buen sentido.)

Es que todo este debate sobre la verificaci�n de l�mites es realmente
absurdo.

Mira, yo soy un ser humano y por lo tanto, soy propenso a errores de
c�lculo. Es 100% seguro que voy a cometer errores de vez en cuando sobre
los l�mites de un array. Todo el mundo lo hace de vez en cuando. A
diferencia, el compilador es una m�quina y nunca cometer� ese error.
NUNCA. L�gicamente, la verificaci�n de los l�mites deber�a ser hecha por
la m�quina, no por m�. En el caso arriba, salta a la vista que no hace
falta verificar los l�mites 1000000 de veces, pero a�n y as�, yo puedo
equivocarme en un caso tan sencillo. El compilador NUNCA se equivoca
sobre eso. Y en cualquier caso cr�tico, se puede escribir el c�digo de
tal forma que la verificaci�n al runtime es inecesaria de todas formas. 

> 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.

�Por qu�? Realmente, deber�as sentir alguna obligaci�n de respaldar lo
que dices.
 
> >La portabilidad en C es algo:
> >
> >(1) definido de manera muy limitada

La portabilidad en el mundo C/C++ no quiere decir lo mismo que en el
mundo Java. En el mundo Java, estamos hablando del hecho de usar un
�nico binario ejecutable para todas las plataformas. 

En C, en el fondo, est�s hablando de portabilidad a nivel del c�digo
fuente. Se lo das tu c�digo fuente al usuario final y �l lo recompila
para su plataforma. Eso puede funcionar en algunos �mbitos restringidos,
pero en realidad, no es una portabilidad que tenga mucha relevancia
pr�ctica para la mayor�a de gente. Yo no me acuerdo de haber tenido
ning�n cliente nunca a quien podr�a darle el c�digo fuente y pedirle que
saque su compilador C y que lo recompile todo.

> 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?

Pues, Enrique, yo no soy la persona aqu� sosteniendo que el C++ es
portable. En todo caso, ni siquiera estamos hablando de portabilidad en
el mismo sentido.

> 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.

En C o C++, hay que hacer un esfuerzo surhumano para escribir y mantener
una base de c�digo que sea portable entre varias plataformas. Poca gente
lo hace y es por eso que la gran mayor�a de software comercial s�lo
corre en la plataforma dominante. 

A diferencia, hay que esforzarse para escribir c�digo Java que no sea
portable -- y adem�s, estamos hablando de un concepto de portabilidad
mucho m�s real que en el mundo C++.

> Con todo esto quiero decir que: �Basta ya de discursiones absurdas sobre
> lenguajes!! 

Mira, si vas a adoptar este tono conmigo, deber�as... saber algo. Decir
tanto disparate y acusar al otro de ser absurdo y en efecto que se
calle.... Pi�nsalo. Comp�rtate.

> Cada lenguaje sirve para lo que sirve y punto. 

Bueno, s�lo en parte tiene que ver con comparar C/Java. La cuesti�n es
que si uno fuera a relacionar las caracter�sticas que quiere en un
lenguaje de proposito general (dejando a un lado la distinci�n un tanto
artificial sistema/aplicaci�n), yo dudo seriamente que el C reuna casi
cualquiera de esas caracteristicas realmente. Seguridad no tiene.
Portabilidad m�s bien te�rica. Etcetera. 

Java no es perfecto, pero reune muchas m�s caracter�sticas de lo que uno
deber�a querer a esta �poca de la historica de la inform�tica.

> 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. 

Si no utilizas las clases GUI, en muchos casos, ya no hay mucha
diferencia con C++. Depende del c�digo, por supuesto. En todo caso,
juzgar el potencial de una tecnolog�a a base de sus primeras
implementaciones es normalmente un error. Sin duda, los primeros coches
eran poco fiables y lentos comparado con un caballo y la gente dec�a que
ese chisme nunca podr�a ir m�s r�pido que un caballo.

De todas formas, Java se dise�� en respuesta a los problemas intr�nsicos
del C y el C++. Tiene sus propios problemas, pero es un progreso.

> 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.

Para ciertas personas, s�, de acuerdo, tiene significado pr�ctico. (Y
consta que dije no tiene mucho... no dije que no ten�a ninguno...) Si
quieres trabajar en el n�cleo de un sistema operativo. Si quieres
recompilar el n�cleo de un sistema operativo. Para la gran mayor�a, no
tiene un significado muy transcendental, no.

Mira, si vas a un foro sobre ciclismo, hay una definici�n de lo que es
r�pido. En un foro sobre automoviles, hay otra definici�n. En un foro
sobre aeronautica, hay otra. 

En un foro sobre lenguaje ensamblador, se puede decir que C es portable
y tiene sentido. Estar en un foro sobre java y decir que C es portable
es una locura, francamente.

> 
> >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.

Clipper tampoco es portable en el mismo sentido que Java. Y tampoco est�
en competencia como lenguaje de prop�sito general. Tiene su rinc�n y ya
est�.

Los mayores problemas de portabilidad en Java est�n con las clases
gr�ficas, el AWT. Es por eso que la gente tiene tantos problemas en
hacer un Applet que se comporte igual en Mac, PC y Unix. �Por qu�?
Porque el AWT tiene un mont�n de clases "peer" que son envoltorios
alrededor de objetos nativos, t�picamente escritos en C. 90% de los
problemas que la gente tiene con la portabilidad de Java son realmente
debidos a la escasa portabilidad del C.

Es una tecnolog�a joven, y tiene sus problemas, pero a�n y as�, la
portabilidad funciona bastante bien. No existe una portabilidad
comparable en el mundo C/C++. Es que no estamos hablando de una
portabilidad te�rica que si dieras el c�digo fuente al usuario, podr�a
recompilarlo.
 
> >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.

Seg�n un thread en los grupos Borland, es que Borland hizo un esfuerzo
surhumano para hacer que BCB pudiese compilar el c�digo MFC. Incluso
crearon un modo especial que ignoraba ciertos aspectos del est�ndar para
compilar c�digo que depend�a de las incompatibilidades del compilador de
MS. Ese tipo de cosa es un foll�n.

En todo caso, tener un sinf�n de casos en que el lenguaje produce un
comportamiento indefinido y los fabricantes pueden implementar como les
da la gana, eso no me parece portabilidad o compatibilidad. Es un truco
sem�ntico. Es realmente problem�tico.
 
> >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.

S�lo un chiflado quiere arrays *sin* control de l�mites. Pens�ndolo, un
array sin ning�n control de l�mites no es realmente un array en el
sentido convencional. Un array tiene una dimensi�n, es decir un
principio y un fin. Un array sin control de l�mites me suena puntero.
Pero aqu� estamos. Vuelta al punto de origen. :-)

> 
> >"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 ;-).

S�, dice que un array es lo mismo que un puntero, pero no es realmente
lo mismo que un puntero. Es perfectamente claro.

> 
> >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.

Uf. Lo que est�s describiendo es horrible y es una verdadera receta para
llegar a un desastre. Escribir c�digo que depende tan precisamente de la
disposici�n de memoria de los structs y arrays en memoria. Bueno, es muy
posible que tienes que recurrir a eso para escribir c�digo eficaz en C
en algunos casos. Pero no es un argumento a favor de tu posici�n ni
mucho menos. Si pensaras en lo que est�s diciendo un momento, te dar�as
cuenta de eso. Que te veas forzado a escribir c�digo chapucero que rompe
las reglas as� para conseguir eficacia demuestra que el C NO es
especialmente eficaz por naturaleza.

De hecho, lo que est�s manteniendo es m�s o menos a 180 grados de la
realidad. Los expertos en optimizaci�n de c�digo t�picamente afirman que
el gran obst�culo a la optimizaci�n de c�digo C/C++ es la sem�ntica de
punteros sin restricciones. No poder analizar est�ticamente qu� parte
del c�digo afecta qu� variables hace que ciertas optimizaciones muy
habituales en otros lenguajes al compile-time sean imposibles -- FORTRAN
es el caso m�s citado, por supuesto.

Entonces, el tipo de chapuza que describes es m�s bien un obst�culo a la
optimizaci�n -- y aun m�s a la portabilidad. Pero, bueno, si vas a
sostener que la sem�ntica de punteros sin l�mites es lo que hace que el
C sea eficiente, es que no sabes de qu� est�s hablando.
 
> >C". La "supuesta eficacia de C" es algo que procurar� refutar luego,
> >cuando tenga un momento.
> 
> Aja, pues da benchmarks.

Hay muchos benchmarks p�blicados en el web. Todos tienen alguna
motivaci�n pol�tica por supuesto. En muchos casos, la diferencia entre
C++ y Java es alrededor de 20% o 30%. Depende del caso obviamente.
Aplicaciones de servidor que no utilicen ninguna clase gr�fica
t�picamente no son especialmente m�s lentas que las escritas en C++,
pero no mucho m�s. El mayor problema actual es las librer�as gr�ficas.

Los dos grandes problemas de eficacia de las implementaciones actuales
de Java son las librer�as gr�ficas y la gesti�n de memoria de la JVM.
Pero lo interesante es que no son problemas intr�nsicos de Java. El
problema, en los dos casos, se halla en c�digo nativo de la JVM, que,
por supueesto, es escrito en nuestro lenguaje tan sumamente eficaz, el
C.

Bueno, otro problema es la tendencia de hacer comparaciones que no
comparan realmente los dos lenguajes. Una aplicaci�n escrita en Java
t�picamente est� distribu�do con un modelo de late-binding, es decir,
que carga sus clases dinamicamente -- desde el sistema local o bien de
la red -- y es lo que ha provocado el inter�s en Java -- los applets,
los servlets, etcetera. Pero hay muchas optmizaciones que no son
posibles con esa disposici�n, pero eso no tiene que ver con el
*lenguaje*. Tiene que ver con el modelo de distribuci�n. Es probable que
cualquier modelo dinamico as� tenga un cierto coste de eficacia --
aunque est�n investigando modos de minimizar ese coste.

En una comparaci�n justa entre C y Java como *lenguajes*, se tendr�a que
comparar c�digo compilado est�ticamente donde se sabe todas las clases
del sistema cerrado por adelantado. Es un tema interesante y el campo es
muy joven. Una cosa que he notado. Los expertos en optimizaci�n de
c�digo que est�n trabajando en Java no consideran que el C++ o incluso
el C sea realmente su competencia. Conf�an en superar la eficacia del
C++ e incluso el C, simplemente porque C/C++ no es especialmente eficaz.
Java es m�s intr�nsicamente optimizable. Est�n mirando m�s bien
lenguajes super optimizados como Fortran como la verdadera competencia.
No bromeo. Mira la p�gina sobre HotSpot y tambi�n la de
instantiations.com. http://www.instantiations.com/jovefaq me parece.

Jonathan Revusky

P.D. No estoy especialmente cabreado contigo. Es que he o�do ese
argumento que el C no tiene ning�n control de los l�mites arrays para
alg�n motivo leg�timo ya muchas veces. Demasiadas veces. Me saca del
quicio. Carece de sentido. Es reaccionario. Y siempre presentan ese
argumento de la eficacia de arrays sin l�mites como si yo soy el
ignorante o algo... �Por qu� la gente siempre tiene que resistirse al
m�s m�nimo progreso incluso cuando la situaci�n es tan obvia?


-- 
Java and Delphi Consulting
Make your .class files double-clickable
with SmartJ
http://www.bigfoot.com/~crystalline.solutions