🚀 go-pugleaf

Juan Pablo Hierro �lvarez <hierro@no.al.xspan.es> wrote:
>>Eso aparte de una burrada es algo innecesario, dado que existen herramientas
>>que ya lo hacen sin necesidad de reescribir c�digo:
>>
> �En qu� quedamos en que es una burrada o en que ya est� hecho?

En que es una burrada no usar lo que ya est� hecho. Lo digo por experiencia
personal: en el trabajo, poco despu�s de comenzar estuve teniendo problemas
de punteros y no era capaz de pillarlos. Me llev� el MSS porque compilaba
tanto con Watcom, DJGPP y MSVC (lo que usaba por aquellos d�as, ahora ya
hemos dejado Watcom), y encontr� los fallos inmediatamente. Estuve sugiriendo
a los dem�s compa�eros el uso del MSS, cuya �nica necesidad era hacer un
#include <mss.h> antes que cualquier otra cosa, para que pueda capturar
todos los malloc, realloc, etc. Na, ni caso.

Misteriosamente unas semanas despu�s el jefe se saca de la manga una soluci�n
que promet�a lo parecido, pero mucho m�s rupestre: hab�a que cambiar todos
los malloc por ReservaMemoria y cosas as�, aparte de que hab�a que a�adir
manualmente una cadena de texto est�tica (no pod�a ser generada) para que el
sistema se arreglase. Se pasaron varios d�as reescribiendo todo el c�digo.

Resultado: no pilla ni la mitad de los fallos, hay d�as que "los otros" se
siguen comiendo el tarro para encontrar esos punteros locos. Yo de todas
formas apenas uso el MSS a d�a de hoy porque encapsul� todos �stos en
plantillas C++ y constructores/destructores manuales, pero sigo pensando que
de haber usado MSS en un principio ahora me ahorrar�a todos estos truquitos.
O podr�amos pasarnos a C++ _completamente_, no s�lo cambiar el compilador
y recompilar c�digo, pero por aqu� todos son "muy agarraos".

> Es simplemente una cuesti�n de sacrificar prestaciones de las bibliotecas
> en favor del rendimiento del c�digo escrito a mano que no controla tantas
> cosas;

Bueno, antes dec�as que s�lo lo ibas a usar en versiones debug, �no? Pues
yo antes usaba...

#ifdef DEBUG
#include <mss.h>
#endif

...y todo arreglado, la versi�n 'release' era veloz como el rayo.

> De todos modos, para proyectos intensivos en la gesti�n de memoria, ser�a
> mejor contar con un recolector de basura, ni las librer�as, ni el bricolage
> optimizado solucionan la papeleta en estos casos.

En eso no estoy de acuerdo, inventar parches para un determinado tipo de
lenguajes en los que no es "natural" la gesti�n autom�tica de la memoria,
suele resultar bastante cutre, aparte de que si desarrollas una aplicaci�n
en tiempo real no puedes permitirte la duda de saber cu�ndo se ejecuta el
recolector, o cu�nto va a consumir antes de dejar aire al resto del SO.

--
 Grzegorz Adam Hankiewicz   gradha@terra.es   http://gradha.infierno.org