Hola, On Dec/04/2009, Pedro Lopez-Cabanillas wrote: > On Friday, December 4, 2009, Carles Pina i Estany wrote: > > > A primera vista yo haría un método. Una regla fácil para colocar cosas > > > en la > > > > Yo no, ni mucho menos. Argumentos para el no: > > > > -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 > > Es posible que en el futuro te des cuenta de que lo que necesitabas en > realidad era hacer bacalao al pil pil. Así que, por previsión, podrías > usar desde ya mismo una cazuela de barro.
Si Alex hace un namespace y yo quiero añadir la función A y tú la B es fácil hacerlo para los dos en cualquier momento. Si Alex extiende string con string_tokenizer y yo quiero añadir string_to_csv y tú string_from_csv es más complicado/incómodo (herencias en vez de añadir funciones a un namespace, si seguimos la misma filosofia). > > > Claro que además de la herencia, también puede tener sentido la > > > composición. Es decir, varias clases incluyen miembros de tipo > > > std::string, y necesitan partir esas cadenas miembro de una misma > > > forma. Si la operación es común, entonces podría ser un método > > > heredado de un ascendiente común. > > > > Si es posible prefiero evitar herencia multiple. Lleva fácilmente a > > dependencias en rombo con más bugs sutiles. > > En ningún momento he sugerido herencia múltiple. > > Pero precisamente la herencia múltiple de la implementación en C++ me > parece una de las mayores fortalezas/ventaja de este lenguaje sobre > Java, C#, Delphi y similares, que solamente permiten herencia múltiple > de interfaces. Sí lo sé, ya tuve que implementar unos cuantos bridges en C# (heretar un interfaz, instanciar componer el objecto dentro y hacer llamadas a él, pensando... C++ C++ :-) ) > > Generar una clase que haga composición de string lo veo trabajo por el > > hecho de tener que redefinir el interfaz público de string, no? > > No. http://en.wikipedia.org/wiki/Object_composition Entiendo que te refieres a algo como: #include <string> #include <iostream> class string_tokenizer { public: string_tokenizer() : m_string() {} string_tokenizer(std::string s) : m_string(s) {} std::string& getString() { return m_string; } void tokenizer() { std::cout << "Tokenized" << std::endl; } private: std::string m_string; }; void test(string_tokenizer s) { std::cout << s.getString() << "- tested" << std::endl; } int main() { string_tokenizer nombre; nombre.getString() = "El Nombre"; std::cout << nombre.getString() << std::endl; std::string apellido; apellido = "El Apellido"; std::cout << apellido << std::endl; test(nombre); return 0; } Le veo el problema que ahora no se le puede pasar un string a test. Si le paso un string tendría que pasarle un string y no un string_togenizer, así que dentro debería crear un string_togenizer para tokenizar. Además de tener que usar el getString() "todo" el rato... Te refieres a lo de arriba o te mal-entendí -es posible, viernes noche... -- Carles Pina i Estany http://pinux.info -- _______________________________________________ Comandob mailing list [email protected] http://lists.badopi.org/mailman/listinfo/comandob
