Proyectos (era Re: Problemas con GTK)
Juan Carlos Muñoz Ilabaca
jcmunoz en dcc.uchile.cl
Mar Oct 11 00:38:30 CLST 2005
Disque el Lunes 10 Octubre 2005 23:43, Horst von Brand escribiosese:
> Alvaro Herrera <alvherre en alvh.no-ip.org> wrote:
> > Horst von Brand escribio:
> > > Alvaro Herrera <alvherre en alvh.no-ip.org> wrote:
>
> [...]
>
> > > > Hmm ... que tanto soporte para "debugging" te ofrece un lenguaje es
> > > > una consideracion muy importante. Este solo detalle me hace
> > > > descartar PHP para casi cualquier cosa.
> > >
> > > Linus difiere fuertemente con tu punto de vista... es por su
> > > imperturbable oposicion que Linux no tiene un "debugger oficial"
> > > integrado al nucleo.
> >
> > Siempre he considerado esa posicion bastante absurda. Un debugger puede
> > ayudar a entender _donde_ esta el problema, y con esa informacion
> > corregir el problema de fondo. Por supuesto, si un idiota cualquiera
> > toma la informacion del debugger y corrige el sintoma en lugar del
> > problema, es un idiota como los que se encuentran en cualquier parte; no
> > es culpa del debugger.
>
> En mi personal experiencia, las situaciones donde un debugger realmente ha
> sido de ayuda han sido pocas (me ayudo bastante cuando aprendia Perl y no
> sabia que estaba escribiendo, pero fuera de eso...). Y en el caso del
> nucleo creo que tiene toda la razon: Lo que hay que hacer para que tal cosa
> funcione es /mucho/ trabajo, que mete sus tentaculos en las partes mas
> reconditas del sistema, y simplemente no lo vale.
>
> [...]
>
> > Yo no soy un programador demasiado brillante -- por ejemplo, nunca he
> > hecho uno de esos programas ofuscados que a la gente le gusta poner en
> > el pie de sus firmas. En cambio, prefiero buscar soluciones simples a
> > los problemas que me planteo.
>
> Segun mis parametros, /eso/ es lo que hace un excelente programador.
>
> > Esta aproximacion me ha permitido
> > resolver problemas grandes, y usar depuradores para ver errores en mis
> > soluciones. El paradigma "programacion por contrato" ayuda mucho en
> > este aspecto, y el depurador es una buena herramienta para buscar nuevas
> > clausulas para los contratos, y ver donde estan fallando.
>
> Podrias detallar? No veo como un debugger ayude alli
>
> > PHP no es un lenguaje que se preste para esto -- por ejemplo los
> > Assert() son demasiado debiles, y la OO no tenia las suficientes
> > facilidades que a mi me habria gustado. (Observaciones de hace tiempo
> > ya; quizas PHP 5 haya corregido esto).
>
> Me declaro ignorante en esos aspectos.
La programación con contratos permite mantener la consistencia de los metodos
de las clases, esto se hace en tres partes, condiciones iniciales, finales y
globales, el ejemplo típico es el de las pilas, el método push por ejemplo
tiene como condición inicial que no esté lleno el arreglo de datos (si es que
se implementa de esa forma), el pop tiene como condición inicial que no esté
vacío el arreglo, el contrato global permite mantener la consistencia de la
clase, y el final es para que al momento de terminar la ejecución del método
todo esté como corresponde, la gracia de los contratos es que se pueden
eliminar al momento de compilar, entonces al momento de programar depuramos
con contratos y cuando esta todo funcionando ok entonces se compila
eliminandolos con un DEFINE, por lo menos así es en c++.
para el caso del uso de malloc, para mi ha sido muy importante el tema del
debug, debido a que aveces uno no hace un free donde corresponde y al final
el error se muestra varias lineas (cientas en mi caso) despues sin tener como
saber por que se cayó ahí.
EJ: stack.h
#include <assert.h>
template<class T>
class stack{
public:
stack();
stack(int);
stack(stack<T>& s);
~stack();
void push(T elemento);
void pop();
T top();
int empty();
private:
T* contenedor;
int tamano;
int tope;
int operator==(stack<T>& s);
int invariante(){
return tamano > 0 && tope >=-1 && tope < tamano && contenedor !=
NULL;
}
};
template<class T> stack<T>::stack(){
assert(0);
}
template<class T> stack<T>::stack(int t){
assert(t>0);
tamano = t;
tope = -1;
contenedor = new T[t];
assert(invariante());
}
template<class T> stack<T>::stack(stack<T>& s){
assert(s.invariante());
tamano = s.tamano;
tope = s.tope;
contenedor = new T[s.tamano];
for(int i=0; i<=tope; i++)
contenedor[i] = s.contenedor[i];
assert(invariante() && s.invariante() && s == *this);
}
template<class T> stack<T>::~stack(){
assert(invariante());
delete contenedor;
}
template<class T> void stack<T>::push(T elemento){
assert(invariante() && (tope+1) < tamano);
contenedor[tope+1] = elemento;
tope +=1;
assert(contenedor[tope] == elemento &&
invariante());
}
template<class T> void stack<T>::pop(){
assert( !empty() && invariante());
tope -=1;
assert(invariante());
}
template<class T> int stack<T>::empty(){
assert(invariante());
return tope == -1;
}
template<class T> T stack<T>::top(){
assert( !empty() && invariante());
return contenedor[tope];
}
template<class T> int stack<T>::operator==(stack<T>& s){
assert( invariante() || s.invariante() );
/* solo el contenido debe der igual */
if( tope != s.tope ) return 0;
int i;
for(i=0; i <= tope; i++ )
if( contenedor[i] != s.contenedor[i]) return 0;
return 1;
}
--
Carol's head ached as she trailed behind the unsmiling Calibrees
along the block of booths. She chirruped at Kennicott, "Let's be wild!
Let's ride on the merry-go-round and grab a gold ring!"
Kennicott considered it, and mumbled to Calibree, "Think you folks
would like to stop and try a ride on the merry-go-round?"
Calibree considered it, and mumbled to his wife, "Think you'd like
to stop and try a ride on the merry-go-round?"
Mrs. Calibree smiled in a washed-out manner, and sighed, "Oh no,
I don't believe I care to much, but you folks go ahead and try it."
Calibree stated to Kennicott, "No, I don't believe we care to a
whole lot, but you folks go ahead and try it."
Kennicott summarized the whole case against wildness: "Let's try
it some other time, Carrie."
She gave it up.
-- Sinclair Lewis, "Main Street"
Más información sobre la lista de distribución Linux