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 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. De todas formas el programa es solo un ejercicio de clase, no es nada serio, pero es por eso de aprender algo, y tal. :-) -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net -- _______________________________________________ Comandob mailing list [email protected] http://lists.badopi.org/mailman/listinfo/comandob
