Hola,
On Dec/04/2009, Alejandro Exojo wrote:
> El Viernes, 4 de Diciembre de 2009, Carles Pina i Estany escribió:
> > -string es un basic_string (creo) y no tiene el destructor virtual. Si
> > por despiste ponemos, ahora en un futuro (mantenimiento) datos en la
> > clase derivada que se tuvieran que destruir en el destructor no sería
> > llamado (si se usa polimorfismo). Es fácil que en algun punto de la vida
> > del programa esto pase y haya un "sutil" memory leak
> >
> > (aunque tuviera destructor virtual NO lo haría)
> >
> > -se puede hacer sin extender la clase principal? Sí. Pues mejor hacerlo
> > para que sea más pequeña y ligera. Sinó cada uno añadiría cosas a
> > string, cada capa de software haría su string. Encapsular los datos y
> > las funciones mínimas, no las de conveniencia.
> >
> > -se puede complicar que en el programa haya strings y
> > string_con_tokenizer, aunque tal como lo planteó Alex no debería ser el
> > caso
>
> Este caso es justo lo que me gustaría evitar. Lo poco que he programado en
> C++
> ha sido con Qt (y sin tocar la biblioteca estándar), y ahí sí que le
> veía sentido a crear tu clase derivada de QLoquesea para una parte
> concreta de la interfaz, o que incluía varios QWidget, pero aquí,
> crear una clase derivada de string o de cualquier tipo tan básico me
> parecía muy mala idea. Es como si me creyera capaz de "mejorar" la
> biblioteca estándar. :-P
:-)
De hecho lo busqué después: del libro "Effective C++" (Third Edition) de
Scott Meyers, item 23, se titula: "Prefer non-member non-friend
functions to member functions." y explica un caso parecido, que no es de
la biblioteca básica (a mí aún me chirría más por compatibilidad con
otros strings si es la biblioteca básica, forzar casts, etc.)
Si puedes revisa este capítulo, quizás en Google Books? Si es de la
segunda edición es el item 18. Básicamente, todo lo que pueda ser
implementado con funciones públicas mejor no ponerlo en la clase por
tamaño, flexibilidad y demás cosas que explica y no te cuento. Ah, y que
puedes hacer una clase auxiliar para esto como dije, aunque ayer no me
acordaba que justamente había un item de esto. Sinó te hubiera mandado
el libro directo.
> De momento lo tengo en una función aislada en un espacio de nombres,
> pero porque solo es una función y bastante corta. Sí que es verdad que
> me ha gustado lo de tenerlo en una clase por si hubiera que crear
> funciones auxiliares de forma privada.
lo pensé después: puedes crear funciones dentro de funciones si
necesitaras funciones auxiliares que solo son llamadas desde una
función. Es decir, que el tokenizer necesite una función auxiliar pero
no otras funciones.
> De todas formas el programa es solo un ejercicio de clase, no es nada
> serio, pero es por eso de aprender algo, y tal. :-)
Suele ser divertido pensar estas cosas.
--
Carles Pina i Estany
http://pinux.info
--
_______________________________________________
Comandob mailing list
Comandob@badopi.org
http://lists.badopi.org/mailman/listinfo/comandob
