Barrapunto

Es claro que estas cosillas de trabajo con memoria son las que dan a C toda su potencia acambio tal vez de solo pedir un poco de cuidado al programador El documento es intereasnte ciertamente util pero ¿Es esto una noticia? ¿Es algo que merezca la primera pagina?

.. Valgrind [valgrind.org] la mayoría de esos problemas son solucionables más fácilmente.
La pega, solo para Linux (y no es portable)

Tal como está redactada la noticia, se puede entender que las fugas de memoria son una herramienta X-)

Aquí tenéis un artículo en castellano que explica cómo usar las herramientas de GNU para detectar y corregir problemas de corrupción de memoria [macprogramadores.org].

En mi opinión, uno de los problemas de C es que los arrays se implementen como punteros "a pelo". Que no se me malinterprete, los punteros son muy útiles y cualquier lenguaje debe tenerlos, aunque sea mediante referencias (menos flexibles pero más seguras). Pero un array tiene una cosa que los punteros no tienen: límites. Y eso en C se ignora, con los resultados que todos conocemos: desbordamientos de buffer.

La mitad de los comentarios son de personajes pedantes que pretenden demostrar su poderío y saber hacer en C, y tratan a toda costa de ridiculizar la noticia ya que "ellos ya lo saben".

Que os den a todos por el cacas, panda de fanáticos engreídos, que nadie sabe de todo. Ahora os chuleáis porque sabéis del tema, pero me gustaría ver cómo se mofan de vosotros los curritos en el taller cuando vais a cambiar el aceite del coche.
Siguiendo vuestra propia teoría no deberían ni echar noticias en la tele pues siempre hay una manera de conocerlas de antemano.

Venga tíos-babas, una vez más: "Vaya mierda de noticia, esto ya lo sé yo, ¿qué tiene de interés?"

No folĺáis ni a la de tres.

Cuando hace un año me compré un fantástico AMD64 (no puedo estar más contento), me encontré con una situación curiosa debido a que tenía código mal escrito. El problema está en las funciones que devuelven una posición de memoria (array, p.e.) pero que no tienen el prototipo definido (o no se ha metido el include), compilando sin opciones que eviten la compilación ante falta de prototipos. Entonces si tienes la función:

int * genera_array( int tamanyo);

pero no la prototipas, en 32 bit "no pasa nada", pero en 64 bit tienes problemas, porque por defecto una función sin prototipo en C devuelve int que ocupa 32bit, mientras que la dirección de memoria en 32bit ocupa 32 bit; si bien en 64bit ocupa 64bit. En 64bit se carga la mitad de la dirección de memoria y te devuelve una dirección inválida :-P

Perseguir este tipo de situaciones es el pequeño esfuerzo que he tenido que hacer para portar el software a 64bit.

En este tema, Qt brilla con luz propia, ya que cuando se programa con Qt no es necesario destruir los punteros a objetos que creemos, de ello se encarga Qt automáticamente. El mecanismo funciona así: todas las clases deben heredar de QObject. Con la interfaz no hay problema porque todos los widgets heredan de QWidget que a su vez hereda de QObject, y con nuestros objetos que no sean de la interfaz obtenemos más ventajas heredándolos de QObject, como poder usar señales y slots. A partir de ese momento, lo único que hay que hacer es pasarle el QObject padre en el constructor. Por ejemplo:

class MiClase : public QObject {
Q_OBJECT
public:
void MiClase(QObject *parent = 0);
};

MiClase::MiClase(QObject *parent)
: QObject(parent) {
// código propio del constructor
}

Y luego sólo tendríamos que crear el objeto, pero no es necesario destruirlo:

MiClase *obj = new MiClase(this);

El destructor de QObject se encargará automáticamente de destruir todos los objetos que sean sus hijos. De ese modo, no hay problemas con punteros que se queden por ahí perdidos. :)

Además, con la interfaz gráfica si un widget se añade a un layout o a otro widget, automáticamente se asigna el padre, con lo cual nisiquiera hace falta el this:

MiFormulario::MiFormulario(QWidget *parent)
: QWidget(parent) {
...
QPushButton *boton = new QPushButton;
QHBoxLayout *layout = new QHBoxLayout;
layout->addWidget(boton);
...
setLayout(layout);
}

Alguien habrá e barrapunto que esté aprendiendo a programar y este enlace le vaya bien...

una cosa es no saber ingles otra opinar que es un idioma de mierda para aprender, como cualquier idioma natural. ^^

Tu presupones que no sabe, yo presupongo que le molesta leer en ingles mas bien.

TIOBE Programming Community Index [tiobe.com]
¿Te refieres a ese lenguaje que esta unos cuatro puntitos por debajo del java?
¿El mismo que es el segundo en uso despues del java?
¿Ese que esta unos seis por encima del c++?
Y hablando de C++, ese esta uno por encima del php. ^^

Claro que eso son solo estadisticas de uso, si tu no lo usas y no te gusta significará que ni siquiera debe existir.¿verdad? ^^

Anda que el Fortran con lo antiguo que es y lo vivo que sigue.
La antiguedad de un lenguaje de programacion no determina su relevancia ni que la información sobre el esté anticuada.

Como te dice el pobrecito hablador de abajo, Python está programado en C, por lo que alguna utilidad tendrá, aunque sólo sea para programar lenguajes megaguays.

Nota: python me parece un lenguaje cojonudo, con megaguays no quiero ser irónico (python es la leche). Me refiero a lenguajes fáciles de programar y con características avanzadas.

Me parece a mí que tu no has programado ni el VHS que tienes en el salón.
Mierda! no hay valgrind para mi VHS! por eso acabo siempre grabando OT en lugar de House :-P