problemas herencia templates

[Gabriel Fusca]

Para el manejo de lista tengo definida una clase

template <class ELEM>
class ListaSimple {
   protected:
   // atributos de la lista
   public:
   //metodos de la lista
};

a la hora de querer heredar
#include "ListaSimple.h"
template <class ELEM>
linea 12-> class ListaSimpleOrdenada : public ListaSimple {
}

tengo los siguientes errores en el compliador

ListaSimpleOrdenada.h:12: error: expected class-name before ‘{’ token

y en los metodos que implemente de esta clase me dice que los atributos heredados (los que estaban como protected en el padre) no fueron declarados en el scope.

Alguno me puede orientar para ver donde puede estar el error?

Muchas gracias!

[Rafael Barrera Oro]

Recuerdo que una vez alguien de la cátedra me advirtió que heredar templates solo podía traerme problemas, o al menos que no me meta en eso por ahora, y me recomendó que implemente el ordenamiento mediante la sobrecarga de los operadores de comparacion o que haga que la lista reciba un objeto comparador, pero que trate de no heredar templates (hablo de ordenamiento porque noto que la clase que hereda se llama lista ordenada). ¿Es viable en tu caso?

Espero haber ayudado ¡Saludos!

--
Has recibido este mensaje porque estás suscrito al grupo "7542 - Taller de Programación" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a tallerdepr...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a tallerdeprograma...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/tallerdeprogramacion?hl=es.

[Matias Mazzei]

Para heredar tenés que hacer así:

#include "ListaSimple.h"
template <class ELEM>

 class ListaSimpleOrdenada : public ListaSimple<ELEM> {
}                                                                         ^^^^

Fijate que agregué el <ELEM> al final.

¡Saludos!

---

Matías Mazzei

2010/4/10 Gabriel Fusca <gfu...@gmail.com>

--

[Gabriel Fusca]

es el caso. Busco ordenamiento para la lista. . Lo de un comparador par tener algo que me indique el orden de los objetos podria ser viable, o directamente con la sobrecargarga  de los operadores < > == ordenar la lista con algun metodo de ordenamiento.

Agregandole <ELEM> pude hacer que los errores se reduzcan solamente a no poder acceder a los atributos que tiene la clase Padre (que herede con protected).

Ahora me surge la duda de que si es una "buena practica" usar herencia y templates.
por ejemplo atributos de la clase ListaSimple
protected:
        NodoLS<ELEM> *primero;
        NodoLS<ELEM> *actual;
   

cuando quiero hacer por ejemlo en la clase Derivada
 if (!primero)

me dice error: ‘primero’ was not declared in this scope

[Matias Mazzei]

Para poder acceder a un miembro protegido de la clase padre, anteponele el nombre _completo_ de la misma.

En tu ejemplo sería:

if (! ListaSimple<ELEM>::primero) {

   // etc.

}

Pero antes te recomendaría descansar porque nada bueno saldrá a esta hora de un viernes ;-)

¡Saludos!

---

Matías Mazzei

2010/4/10 Gabriel Fusca <gfu...@gmail.com>

es el caso. Busco ordenamiento para la lista. . Lo de un comparador par tener algo que me indique el orden de los objetos podria ser viable, o directamente con la sobrecargarga  de los operadores < > == ordenar la lista con algun metodo de ordenamiento.

[Gabriel Fusca]

jjeje si me fui a dormir gracias =P.

Con ListaSimple<ELEM>:: ahora solucione el problema. Ahora tengo otro que no mehabia detectado el compilador.
 Tengo una clase NodoLS que es friend de ListaSimple<ELEM>  de modo que en la clase ListaSimple puedo acceder a los atributos y hacer nodo->siguiente = nodo ;
 Ahora en la clase hija me dice que es privado. Cuando uno hereda, esta clase deja de ser friend?

[Gabriel Fusca]

los errores de compliacion los solucione declarando como friend tambien a ListaSimpleOrdenada dentro de la clase NodoLS. Esta bien esto?

[Pablo Daniel Roca]

Aclaro por las dudas. Lo que estamos buscando es que el ejercicio lo hagan con polimorfismo y herencia. Ud. no tuvieron la clase de Templates con l oque no podemos pedirles eso y en principio recomendamos que no lo usen para no confundirlos/perder tiempo/confundir al resto de los compañeros.


Respecto de lo que hablan en los mails:
-NO usen protected para atributos. Es una mala práctica que impide modificar libremente la implementación interna de la clase. Les dejo un link [1] sobre principios que es bastante bueno. Básicamente, si querés modificar la clase base y esta tiene atributos protected, jamás vas a poder. sacar/modificar el uso de esos atributos. Cuando necesites acceso hacia arriba se escribe un getter ya sea público o protected. (si quieren discutir sobre esto hablamos en otro thread)
-NO usen friend a menos que sea altamente necesario (al escribir el operator<< se acepta ese uso pero incluso con clases muy acopladas como Lista y Nodo está discutido el tema). Si usan FRIEND recuerden que están violando el principio de ocultar la implementación del objeto.
-Las listas se pueden resolver sin templates si no los entienden y hacer que siempre almacenen una clase base de todas las enteidades. Algo similar a lo que se hacía con el ArrayList en J2SE o en .Net antes de templates: 

ClaseEspecifica objetoEspecifico;
ClaseBase& referenciaNoEspecifica = objetoEspecifico;
ArrayList lista;
lista.add(referenciaNoEspecifica);
ClaseEspecifica* punteroEspecifico = (ClaseEspecifica*)lista.get(0);

Creo que esto deberìa funcionar.


Saludos.
Pablo.

El 10 de abril de 2010 13:26, Gabriel Fusca <gfu...@gmail.com> escribió:

los errores de compliacion los solucione declarando como friend tambien a ListaSimpleOrdenada dentro de la clase NodoLS. Esta bien esto?

[Pablo Daniel Roca]

Me olvidé de agregar el link.

[1] http://www.objectmentor.com/resources/articles/ocp.pdf

[Matias Mazzei]

Pablo:

   Respecto a lo que comentaste sobre el uso de clases "friend" ¿está mal un trabajo donde Lista sea friend de Nodo?

   Si bien en este caso no es "altamente necesario" que sean amigas, es lo más práctico ya que podría catalogarse a Nodo como una clase interna de Lista y que existe sólo en función de ésta.

   ¡Saludos!

---

Matías Mazzei

[Pablo Daniel Roca]

El 10 de abril de 2010 16:55, Matias Mazzei <matias...@gmail.com> escribió:

Pablo:

   Respecto a lo que comentaste sobre el uso de clases "friend" ¿está mal un trabajo donde Lista sea friend de Nodo?

No, no está mal, es una posibilidad que te dá C++ y un uso aceptable sería ese....

   Si bien en este caso no es "altamente necesario" que sean amigas, es lo más práctico

 

Justamente, vos querés agregar un friend por cuestiones de practicidad, no porque el diseño lo requiera. Te repito, en ese caso es aceptable, pero pensá como lo soluciona un programador de otro lenguaje...hace publico los atributos?

 

ya que podría catalogarse a Nodo como una clase interna de Lista

C++ también te permite tener clases internas y creo que incluso podés definirlas como privadas hacia afuera... en ese caso podés poner friends o simplemente hacer todo publico... pero si hacés todo público te quedás con un struct ....
¡qué dilema !   :-)

Otra vez, no hay reglas fijas para todo esto. Depende del caso. Lo único seguro es que los friends se tienen que justificar.

Saludos.
Pablo.

y que existe sólo en función de ésta.

   ¡Saludos!

---

Matías Mazzei

--