🚀 go-pugleaf

La verdad, no se si contestarte, o que te informes tu mismo.

Aqu� lo oficial: http://gcc.gnu.org/gcc-2.96.html quiz�s no lo aceptes, pero
ellos son los que hacen el GCC
Una conversaci�n de Linus: http://lwn.net/2000/1221/a/lt-rh7.php3 no es la
�nica, pero se pueden buscar, no es muy dif�cil.

> > El gcc-2.96 no ha existido oficialmente nunca.
>
> Ah, no? Entonces, como es que lo tengo instalado?
>
> > La introdujo RedHat del CVS
> > y fue un fracaso total,
>
> Craso error.

Vete a GCC.

> Pero, de hecho, cuantos programas vienen en las distribuciones que son
> "noseque-0.12.3-5" ? Cuantos Linuxeros utilizan Debian-unstable?

Que se usen programas considerados inestables, pero que un usuario normal no
encuentre fallos es normal, s�lo usando el programa al 100% salen los fallos
es decir usando todas las caracter�sticas, y por periodos prolongados. No
has oido nunca la t�pica frase "si no encuentras fallos es que no los tiene"
es falsa totalmente, y no voy a intentar hacertelo ver, pero es as�.

> De hecho, gcc 2.96 es casi casi igual a lo que sera el gcc 3.0 . Vamos,
que
> si no te compila con 2.96, no te va a compilar con 3.0 , porque ambos son
> igual de estrictos.

Falso, vete a GCC, la versi�n 3.0x es muy estricto en C++ S�LO. "El resto no
se ha modificado".

> > por que estaban reformando totalmente el nucleo de
> > gcc, que es lo que ahora es gcc-3.0, que incorpora muchas mejoras, pero
> > todav�a estaba muy verde.
>
> Muy verde? Pues se utiliza en Red Hat Linux 7.0, 7.1, 7.2 y Mandrake 8.0 y
> 8.1.

Y que pretendes demostrar con eso, que se use no quiere decir que no est�
verde comparado con la versi�n 3.0

> > Gcc-3.0 admite los �ltimos estandares, y
> > gcc-2.96 s�lo algunos como C99, de ah� lo que hayas leido, pero p.ej. el
> > de C++ no entero, y es la principal reforma.
>
> 2.96 admite practicamente tood lo que admite 3.0. 2.9x son los
> "pre-releases" o "release candidates" de 3.0. Vamos, que son casi iguales.

Vete a GCC y los comparas, tanto en los lenguajes que acepta como la
implantaci�n del estandar de C++. Y no digas que son PR o RC por que no son
m�s que unas instantaneas del CVS, nada m�s es un punto y seguido, s�lo para
desarroyadores, para poder corregir los fallos sobre una instantanea u otra.
Hazte esta pregunta, �por qu� no se sac� gcc-2.97?

> > Por qu� la mayoria de distribuciones tienen gcc-2.96, por que est�n
> > basadas en RedHat.
>
> Lo usan porque es (era) el mejor compilador existente.

Falso, es un buen compilador ahora y hasta cierto punto, C si, C++ no p.ej..

> > Pero no es recomendable,
>
> Falso. Totalmente recomendable. A menos que tengas codigo no estandar.

Intenta hacer cualquier cosa totalmente estandar y algo enrevesada en C++
con �l, no s�lo dar� errores de compilaci�n sino tambi�n en ejecuci�n.

> > aunque ahora es m�s o menos estable,
>
> Igual que cuando salio la RH 7.0

No

> > despues de los parches pertinentes claro.
>
> que no tienen nada que ver con el tema. Parches de seguridad, bugfixes...
> peero nada que cambie el comportamiento del gcc

Pues deberias decirselo a RedHat, que saco un parche bastante grande. Lo he
estado buscando pero no lo he encontrado. Por que crees que no sac� la
gcc-2.97 para no cometer un error como el que cometi�.

> > La principal pol�mica es que no compilaba el nucleo,
>
> Nucleo 2.2.x, recordemos.
>
> > e incluso Linus dijo que era imposible trabajar con �l.
>
> Imposible trabajar con la combinacion Kernel 2.2.x con gcc 2.96 debido a
> que el KErnel 2.2.x no era todo lo limpio y "cumplidor de estandares" que
> deberia ser. En cambio, 2.4.x si que cumple los estandares. Y compila
> perfectamente.

Si no cumpliera un estandar no compilaria, pero no dar�a errores de
ejecuci�n.

> Linus Dixit. Alan Cox dixit. Jeremy Katz dixit.

Aqu� no te entiendo, bueno mejor dicho no te quiero entender. Por que los
dos primeros que citas son los m�ximos representantes de Linux. El tercero
no lo conozco.

> > Mi experiencia personal con mi SO, es que no es estable,
>
> Que tu SO no sea estable, no tiene nada que ver.

�Te has molestado en probarlo? entonces �por que lo evaluas? Bajatelo te
creas un disquete, y luego dime si es o no es estable.

> > te puedo decir que lo uso para mi SO, a la espera del gcc-3.1 (que debe
> > salir a finales de mes),
>
> Si lo usas, p.q. te basas en "supuestos" problemas para criticarlo? Antes,
> informate, por favor.

Mira lo uso porque _ahora_ est� parcheado y no puedo prescindir de ciertas
caracteristicas similares a las que tiene la versi�n 3.0, pero tengo que
usar protecciones extra, que no deber�an ser
necesarias. -fno-strict-aliasing  y cast innecesarios p.ej. Por qu� no uso
la 3.03 por que no es estable todo lo que se desear�a. Prefiero esperar a la
3.1

> > y en muy raras ocasiones un c�digo probado no funciona, es decir tienes
> varios ficheros, recompilas todo, y no funciona,
>
> Seguramente, el mismo problema que el KErnel 2.2.x : que no es correcto
del
> todo.

Vamos a ver si el mismo c�digo se ha compilado ya, con la misma versi�n y
funciona, recompilas sin cambiar nada y no funciona �de quien es el error?
No son errores de compilaci�n sino de ejecuci�n.

> > hace cosas raras, sin haber modificado una sola linea. Problemas en el
> > equipo no existen. Tambien ciertas caracteristicas "avanzadas" como
> > funciones pure y const, que no funcionan apropiadamente, y algunos cast
> > que no tienen que ponerse, los tienes que poner por que si no, no
> > funciona.
>
> Es mas rigido con el lenguaje. Eso es bueno: te obliga a programar mejor.

Es m�s rigido en C++.

> > Para programas con cosas m�s normalitas, y que no necesiten ser
> > tan estrictas, es buen�simo y no encuentran ning�n problema.
>
> Ah! Es buenisimo!
>
> Entiendo... Pero lo dices despues de muchas lineas.

Si, despues de parches, y para un _usuario normal_ y que s�lo use C.

> > Yo no usar�a gcc-3.0 usar�a gcc-3.03, que es bastante bueno, no tiene
> > pr�cticamente fallos, quiz� en C++ todav�a tiene algunos, pero ya son
> > dif�ciles de encontrar. De echo ya compila el n�cleo, cosa que
> > gcc-3.0[0-2] no, as� que se puede considerar estable.
>
> Yo te recomiendo que uses el que viene con tu distribucion. Si lo han
> puesto, es por algo. Y te aseguro que los paquetes se prueban mucho antes
> de sacar una nueva distribucion.

Mira un programa normal no es un n�cleo, en un n�cleo se manejan cosas
directamente y a muy bajo nivel, algo de ensamblador, estructuras y
direcciones de memoria impuestas por el hardware, con lo cual no puedes
permitirte errores, y claro si el que falla es el compilador pues fastidia,
por que el error no se encuentra f�cilmente, se necesita una gran exactitud
en el c�digo resultante.

El error de que a veces compile correctamente y otras no (raras ocasiones).
Lo veo grabe, y la �nica soluci�n que he encontrado es
poner -fno-strict-aliasing, y ya se ejecuta siempre bien. Quiz�s utilice
accesos a memoria enrevesados con multiples cast y diversos niveles de
indirecci�n, pero creo que eso no justifica que unas veces funcione y otras
no. Adem�s el uso de esas mara�as de c�digo son necesarias, no son por que
me guste ofuscar el c�digo. A m� me gusta la sencillez.

---------------------------------
jespejoYASABES@QUEHACERarrakis.es
�Sistemas Operativos? �Vis�tala!
http://www.arrakis.es/~jespejo
---------------------------------