🚀 go-pugleaf

El d�a Mon, 25 Jan 1999 18:18:24 +0100, Jonathan Revusky
<jrevusky@jet.es> escribi�:

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

En fin...

>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

No s� a qu� viene esto, de verdad.

>nadie que proporcione empleo y vivienda a cada espa�ol.) El argumento
>que haces sobre lo que es legal, a nivel pr�ctico, me temo, no tiene
>mucha base real.

No hago ning�n argumento. Solo digo que el C es perfectamente portable
si te atienes al est�ndar, que para eso est�. El hecho de que no haya
miles y miles de controles y chequeos y vigilancias etc etc como los
hay en Java es simplemente por motivos de *velocidad*, que teniendo en
cuenta para qu� est� dise�ado C parece un factor bastante importante.

>Pero todo eso nos lleva, como siempre, a la siguiente observaci�n.
>
>La portabilidad en C es algo:
>
>(1) definido de manera muy limitada

La portabilidad de C est� perfectamente definida para permitir
trabajar sin tener un overhead del 1000% s�lo en comprobaciones sobre
si el programador es lo suficientemente inteligente como para no
acceder a un elemento inexistente en un array, por ejemplo. Ya he
dicho que el �nico motivo de no tener los muchos mecanismos que tiene
Java de protecci�n contra errores son motivos de eficiencia, y est�n
plenamente justificados.Repito por en�sima vez que me da exactamente
igual que Java sea m�s portable que C o que deje de serlo. Lo que
defiendo es que C puede ser perfectamente portable.

>y 
>
>(2) no tiene mucho significado pr�ctico.

Claro, por eso herramientas como por ejemplo todas las de gnu est�n
�ntegramente escritas en C y son perfectamente portables a docenas de
sistemas distintos.

>Eso a nivel de empresas grandes que pueden dedicar muchos a�os-hombre al
>tema de portar software. A nivel de gente como yo, un desarrollador
>independiente, o incluso empresas peque�as, a nivel pr�ctico, esa
>portabilidad casi no existe.

Nunca he dicho que el C sea un buen lenguaje para t�, ni para la gente
como t�, ni para peque�as empresas que desarrollan mayoritariamente
aplicaciones de gesti�n o similares. He dicho que el C es el lenguaje
de los que desarrollan sistemas operativos, aplicaciones de sistema,
herramientas, etc. Se me va a caer la boca de decirlo.

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

�Por qu� te empe�as en convencerme de que Java es m�s portable que C,
cuando yo nunca he defendido lo contrario?

Java es m�s portable que C, porque Java est� dise�ado con el objetivo
prioritario de ser portable. C est� dise�ado con el objetivo
prioritario de ser eficiente, y luego _permitir_ pero no_forzar_ la
portabilidad, simplemente por una cuesti�n de versatilidad.

>
>> Por el contrario, un programa *ilegal* en C puede tener un
>> comportamiento indefinido, o simplemente dependiente de la
>> implementaci�n. <resto cortado>
>
>Ese tipo de cosa me suena tecnicismo de abogado, no realmente un
>argumento de ingeniero. La definici�n que propuse, que el mismo programa
>produce el mismo comportamiento en distintas plataformas, de punto de
>vista de ingenier�a, me parece ser m�s o menos la definici�n correcta.

Si un mismo programa produce el mismo comportamiento en distintas
plataformas, el programa es portable.

Y yo a�ado: en C puedes escribir programas perfectamente portables,
siguiendo las directrices que marca el est�ndar ANSI C, que para eso
se ha creado. Lo cual no impide que puedas escribir programas que NO
sean portables, bien deliberadamente o bien porque no sepas escribir
un programa que siga el est�ndar.

El trozo de mi p�rrafo anterior que has cortado explicaba por qu� en
Java dispones de un mecanismo de excepciones muy complejo y en C no:
porque se decidi� que fuera as�, porque C ten�a que ser eficiente.
Porque, como ya estoy harto de decir, Java est� pensado para
aplicaciones de usuario y C para aplicaciones del sistema.

>> No es m�a, es de las organizaciones ANSI e ISO, que me da a m� en la
>> nariz que de esto deben saber un poco.
>
>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 escandaliza, simplemente me parece un poco retorcido. Por
cierto, que en el comit� no solo hab�a "fabricantes de compiladores".

>> No es eso lo que he dicho. He dicho que no puedes basar tu c�digo en
>> trabajar a base de excepciones. 
>
>S�, bueno, pero la situaci�n de leer o escribir a un puntero inv�lido no
>es precisamente muy excepcional en el mundo C. Es bastante cotidiano. No
>obstante, el C no trata el problema. Decir "es ilegal" pero no hay
>ning�n mecanismo que impone la m�s m�nima disciplina es realmente una
>contradicci�n.

No es ninguna contradicci�n. Es decir lo siguiente: si te atienes a
las reglas, tu programa ser� portable. Si no te atienes a las reglas,
puede funcionar, o puede no funcionar. No te vamos a "imponer la
disciplina" porque eso supone una carga adicional que no queremos
obligarte a sufrir, cuando probablemente no la necesites.

>> No te confundas. El hecho de que punteros y arrays sean equivalentes
>> en muchas ocasiones no quiere decir que sean totalmente
>> intercambiables. De hecho, el est�ndar define cu�ndo son equivalentes
>> y cuando no lo son; internamente cada compilador los puede implementar
>> como le parezca, aunque lo l�gico es hacerlo mediante punteros.
>
>Para m�, el C no tiene arrays.

Menos mal que para los programadores de C s� que los tiene.

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

Un array tiene una dimensi�n, pero eso no implica que el lenguaje
tenga que obligarte por narices a respetarla. Son cosas distintas.

>> Y much�simos otros ejemplos. La llamada "equivalencia" de punteros y
>> arrays en C no significa que sean totalmente id�nticos. Son
>> equivalentes, por ejemplo, como par�metros formales en una funci�n,
>> pero en muchos otros contextos no lo son.
>
>De hecho, ya era consciente de que hay diferencias sutiles en la
>especificaci�n, pero a nivel pr�ctico, existe el mismo problema. El
>puntero tiene un principio y ning�n fin definido. Pasar un array a una
>funci�n es efectivamente lo mismo que pasar un puntero, y por lo tanto,

Concretamente, pasar un array a una funci�n es equivalente a pasar un
puntero al primer elemento del array. Pero de ah� no debes deducir que
en cualquier otro contexto, un puntero y un array sean tipos
equivalentes. Porque no lo son. Fin.

>> === Empieza ===
>> 6.3:  So what is meant by the "equivalence of pointers and arrays"
>>      in C?
>> 
>> A:  Much of the confusion surrounding arrays and pointers in C can
>>     be traced to a misunderstanding of this statement.  Saying that
>>     arrays and pointers are "equivalent" means neither that they are
>>     identical nor even interchangeable.
>> 
>>     "Equivalence" refers to the following key definition:
>> 
>>         An lvalue of type array-of-T which appears in an
>>         expression decays (with three exceptions) into a
>>         pointer to its first element; the type of the
>>         resultant pointer is pointer-to-T.
>> 
>>     (The exceptions are when the array is the operand of a sizeof or
>>     & operator, or is a string literal initializer for a character
>>     array.)
>> === Acaba ===
>
>Pero bueno, citas los escritos sagrados que casi nadie lee...  

Anda, pues f�jate que casualidad, que los escritos sagrados "que casi
nadie lee", como t� los llamas, son el FAQ de comp.lang.c, as� que me
parece que no debe existir ning�n documento m�s le�do por la comunidad
de programadores de C que ese.

>(Espero que no he topado con algunos religiosos. Lo que quiero decir es
>que todo eso es misticismo, que adem�s, prima facie, parece
>contradecirse, o quiz� no se contradiga, yo que s�.. pero nadie lo
>entiende realmente...)

Querr�s decir que no lo entiendes t�. No extrapoles con tanta
facilidad.

De todas formas, si quieres te puedo poner m�s ejemplos y dar m�s
explicaciones de por qu� punteros y arrays no son lo mismo, pero es
que ya me parec�a un poco aburrido.

>En el fondo, que es la diferencia entre eso y:
>
>"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?

Sin comentarios.

>> No hablo de la libertad de escribir a una direcci�n de memoria
>> inv�lida, ni a la libertad de que tropieces en un suelo lleno de
>> porquer�a. Hablo de la libertad de tratar los arrays y los punteros
>> como tipos equivalentes, en las situaciones en la que est�
>> perfectamente especificado que puedes hacerlo.
>
>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.

Bien: si no *quieres*, pues no lo hagas. Pero otros pueden *querer*, y
entonces est� bien que *puedan* hacerlo.

>En todo caso, la idea que esta libertad de romperse el culo produce
>mucha eficacia en el c�digo resultante, la tratar� luego, ya que esto se
>vuelve demasiado largo. Quer�a hablar de "la supuesta portabilidad de
>C". La "supuesta eficacia de C" es algo que procurar� refutar luego,
>cuando tenga un momento.

Como quieras.

Salu2: GUILLE
----
Guillermo Rodriguez Garcia
<XXguille@XXiies.XXes>  (ya sabes :-)