Pues vereis llevo toda la vida usando templates con strings de una forma un poco peculiar, pero me gustaria saber si exite otra manera que esta de usar string con templates:
static char valor_para_el_template[] = "Lo que sea";
template <const char *string> class margatita ....
margarita<valor_para_el_template> ....
La unica manera de pasar un valor para el template es con la variable static, ¿pero existe otra manera mas comoda, truco o lo que sea? es que empiezo a tener el codigo lleno de statics :(
tal vez si explicases el proposito del template y de recibir un string como parametro podriamos aconsejarte
Ejemplo un pelin absurdo de lo que digo:
template <const char *nombrehumano> class Humano
{
public:
bool minombrees( const char *humano )
{
if( strcmp(humano, nombrehumano) == 0 )
{
return true;
}
else
{
return false;
}
}
};
Como se ve se le ha de pasar un string al template para luego usarlo en la funcion minombrees
sigo sin entenderlo, por qué no pasas el string como parametro del constructor?
Claro, como dice Tamat para eso que haces, lo más normal sería pasarle el string que quieras como parámetro de un constructor que hagas (que veo que te conformas con el de por defecto).
Los templates normalmente se usan para generalizar y trabajar con más de un tipo de clase. Por ejemplo, los vectores de stl están "templatizados" para que puedas hacer un vector de enteros (vector), un vector de flotantes (vector) o un vector de lo que quieras vamos. Nunca había visto usar los templates para pasar parámetros... xD
(PD: igual no entendí lo q quieres hacer y sí hace falta un template pero a simple vista no)
Veamos, la funcionalidad real es un manager de recursos que saca los recursos de un xml, para ello cada manager tiene un tipo de recurso diferente y un tag de cierre, apertura, etc. si lo pongo en el constructor el template del manager solo tragaria con un tipo de tag xml y esto no vale, si lo paso en el constructor tengo que inicializarlos pasandoles los strings que son constantes para el manager al igual que el tipo de recurso que controla, la mejor solucion es pasarle los strings de esta manera ya que es un template unico para su recurso y para sus tags.
Esto es el objetivo:
template <class RESOURCE, class TYPE, const char *tagCloseManager, const char *tagResource> class IManager{...}
Como se ve el recurso es unico como sus tags y su tipo, con lo que lo correcto es hacer un template en el que le pasas todos los parametros.
He estado buscando mas info por internet y parece que la unica solucion es la que llevo usando toda la vida :(
Yo lo que hago es tener un template Gestor de recursos que recibe como parametro la clase del recurso que va a "gestionar", de esta manera hay diferentes segun diferentes recursos. Pero creo que en tu caso te interesa más mi sistema de modulos:
Tengo una clase llamada Modulo que implementa el interfaz de cada Modulo de mi sistema, todos estos heredan de esa clase (RenderModule, InputModule,...). Lo bueno es que la clase Modulo tiene un contenedor estático de instancias, entonces el constructor de Modulo agrega su instancia a dicho contenedor lo cual viene bien para saber cuantos módulos hay en funcionamiento en mi sistema.
Cada nuevo Modulo que hereda del interfaz le pasa al constructor el nombre de dicho módulo (p.e. "RenderModule") y la lista con los tags XML con los que trabaja el módulo (p.e. "renderconfig,openglconfig". Además reimplementa el método virtual de la clase Modulo llamado ProcessTag(TagXml*).
Entonces la clase Modulo tiene un método estático que es LoadXML(const char*), este carga el XML, va tag a tag y mira qué modulos hay que procesen dicho tag, si hay alguno entonces llamada al método ProcessTag de dicho modulo y le pasa el tag.
De esta manera creo un unico XML y cada módulo coge lo que necesita.
Espero que te sea de ayuda.
No me vale pasar al constructor el string por que tendria que derivar un template, cosa extraña por que los templates se hicieron para crear plantillas y evitar asi derivar una clase de otra y dar soporte sin conocer los tipos, el sistema que indicas obliga al programador a derivar del template siempre que quiera crear un nuevo manager lo cual en proyectos pequeños esta bien, pero cuando tienes mas de 100 managers diferentes puede ser una locura.
100 managers o cómo diseñar con el culo.
Cita de: "Flint"100 managers o cómo diseñar con el culo.
¿Por que no explica el diseño correcto para esto?
Cita de: "zupervaca"Cita de: "Flint"100 managers o cómo diseñar con el culo.
¿Por que no explica el diseño correcto para esto?
Mejor explica tú cómo puedes tener 100 managers sin un diseño de base pésimo. Entre tanto gestor, tendrás alguno que te haga la colada... :P
Cita de: "Flint"Cita de: "zupervaca"Cita de: "Flint"100 managers o cómo diseñar con el culo.
¿Por que no explica el diseño correcto para esto?
Mejor explica tú cómo puedes tener 100 managers sin un diseño de base pésimo. Entre tanto gestor, tendrás alguno que te haga la colada... :P
Pues fijate que puedes tener managers hasta para controlar diferentes tipos de objetos en pantalla, desde enemigos, armas, municion, etc. esta claro que nunca has hecho un proyecto grande en el que no solo se hacen managers para leer texturas, modelos, etc.
Cita de: "zupervaca"Cita de: "Flint"Cita de: "zupervaca"Cita de: "Flint"100 managers o cómo diseñar con el culo.
¿Por que no explica el diseño correcto para esto?
Mejor explica tú cómo puedes tener 100 managers sin un diseño de base pésimo. Entre tanto gestor, tendrás alguno que te haga la colada... :P
Pues fijate que puedes tener managers hasta para controlar diferentes tipos de objetos en pantalla, desde enemigos, armas, municion, etc. esta claro que nunca has hecho un proyecto grande en el que no solo se hacen managers para leer texturas, modelos, etc.
Ahhh, sí, me olvidaba de que eres uno de los grandes de la industria.
Cita de: "Flint"Cita de: "zupervaca"Cita de: "Flint"Cita de: "zupervaca"Cita de: "Flint"100 managers o cómo diseñar con el culo.
¿Por que no explica el diseño correcto para esto?
Mejor explica tú cómo puedes tener 100 managers sin un diseño de base pésimo. Entre tanto gestor, tendrás alguno que te haga la colada... :P
Pues fijate que puedes tener managers hasta para controlar diferentes tipos de objetos en pantalla, desde enemigos, armas, municion, etc. esta claro que nunca has hecho un proyecto grande en el que no solo se hacen managers para leer texturas, modelos, etc.
Ahhh, sí, me olvidaba de que eres uno de los grandes de la industria.
No hay que ser grande para saber hacer analisis previo a la programacion de un juego, con haber hecho algun proyecto, por muy simple que sea, podrias saber que en un juego hay mas que un manager de texturas y modelos.
Cita de: "zupervaca"Cita de: "Flint"Cita de: "zupervaca"Cita de: "Flint"Cita de: "zupervaca"Cita de: "Flint"100 managers o cómo diseñar con el culo.
¿Por que no explica el diseño correcto para esto?
Mejor explica tú cómo puedes tener 100 managers sin un diseño de base pésimo. Entre tanto gestor, tendrás alguno que te haga la colada... :P
Pues fijate que puedes tener managers hasta para controlar diferentes tipos de objetos en pantalla, desde enemigos, armas, municion, etc. esta claro que nunca has hecho un proyecto grande en el que no solo se hacen managers para leer texturas, modelos, etc.
Ahhh, sí, me olvidaba de que eres uno de los grandes de la industria.
No hay que ser grande para saber hacer analisis previo a la programacion de un juego, con haber hecho algun proyecto, por muy simple que sea, podrias saber que en un juego hay mas que un manager de texturas y modelos.
De unos pocos managers a 100 hay una (gran) diferencia: probablemente un diseño hecho con el culo, como he dicho. :P
Citar
De unos pocos managers a 100 hay una (gran) diferencia: probablemente un diseño hecho con el culo, como he dicho
La has cagado y estas intentando salir indemne con tus comentarios. Decirte q no lo consigues y haces el ridiculo progresivamente.
Saludos!
Cita de: "Flint"Cita de: "zupervaca"Cita de: "Flint"Cita de: "zupervaca"Cita de: "Flint"Cita de: "zupervaca"Cita de: "Flint"100 managers o cómo diseñar con el culo.
¿Por que no explica el diseño correcto para esto?
Mejor explica tú cómo puedes tener 100 managers sin un diseño de base pésimo. Entre tanto gestor, tendrás alguno que te haga la colada... :P
Pues fijate que puedes tener managers hasta para controlar diferentes tipos de objetos en pantalla, desde enemigos, armas, municion, etc. esta claro que nunca has hecho un proyecto grande en el que no solo se hacen managers para leer texturas, modelos, etc.
Ahhh, sí, me olvidaba de que eres uno de los grandes de la industria.
No hay que ser grande para saber hacer analisis previo a la programacion de un juego, con haber hecho algun proyecto, por muy simple que sea, podrias saber que en un juego hay mas que un manager de texturas y modelos.
De unos pocos managers a 100 hay una (gran) diferencia: probablemente un diseño hecho con el culo, como he dicho. :P
Lo dicho, ¿y como lo harias tu? por que gracias al sistema que pongo yo con solo declarar una clase parametrizando los strings correctamente no hay que programar nada y se lo hace todo la clase, osea, que mal mal, no creo que este.
Cita de: "zupervaca"No me vale pasar al constructor el string por que tendria que derivar un template, cosa extraña por que los templates se hicieron para crear plantillas y evitar asi derivar una clase de otra
Por puntos:
- Derivar templates es lo más normal del mundo. En absoluto se hicieron para "evitar derivar". El template da el manejo del tipo que quieras parametrizar, y la derivada del template hace las cosas concretas que quieras para un tipo de recurso concreto. Pueden haber varios recursos diferentes que usen el mismo tipo.
- Puedes hacer un template que toma los tipos como parámetro del template, y las cadenas de los tags como parámetro del constructor.
- Tampoco entiendo para qué necesitas derivar el template para pasarle diferentes cadenas, pero no es problema. Si la derivada del template solo debe ser usada con un tag concreto, pues que sea la derivada quien pase el tag (y aunque el constructor del template recibe un tag, el constructor de la derivada no. Por ejemplo:
template<typename T>
class IManager
{
const char *Tag;
public:
typedef T Tipo;
IManager(const char *tag): Tag(tag) { }
//...
};
class ManagerDeLuces: public IManager<float>
{
std::vector<IManager::Tipo> Valores;
public:
ManagerDeLuces(): IManager("luz") { }
//...
};
- NO se pueden pasar cadenas literales como parámetro para la instanciación de un template, hay que hacerlo con los static.
- Es la primera vez que veo a alguien hacer un diseño así, y espero que sea la última. ;)
Lamento el offtopic:
Vosotros dos: (Flint y Zupervaca), ya en serio, ¿os habeis puesto de acuerdo para llenar cada post en el que participais de chorizos de quotes? Vuestras discusiones, con todo el respeto para ambos, me parece que no aportan nada ni a este ni al otro post en el que también discutías. Si lo haceis de coña, no le veo la gracia. Y si es en serio, me parece muy lamentable.
Como mínimo, sería de agradecer, que no pusierais esos quotes anidados tan feos.
Por supuesto esta es solo mi opinión, y os la podeis pasar por el forro. Pero no sé, creo que la sección privada de mensajes del foro está para cosas como esa.
Un saludo y suerte con la solución de tu problema Zupervaca, la explicación de Jare es muy buena.
Ya he dicho en un post anterior que no es factible en este caso derivar el template por que tendria que hacer una clase por cada manager y en un juego grande puedes tener mas de 100 managers, uno para municion, otro para enemigos, etc que se lean del xml igual, pero que sus tags empaquetadores sean diferentes.
Os voy a poner un ejemplo de por que se tiene que pasar el string al template y no se debe derivar pasando el string al constructor:
Tenemos un template array en el que queremos que el programador pueda definir su tamaño solo una vez, ¿lo pondriais en el constructor o lo pondrias como parametro del template? si se pone en el contructor, problema, estas obligando a que todos los arrays sean punteros ya que al no tener un constructor sin parametros no puedes ponerlo como memoria automatica dentro de una clase, si creas una funcion para poder crearlo llamada create por ejemplo estas obligando al programador a que tenga que inicializarlo siempre, pero... ¿que pasa si se pone de template? pues que todos los problemas se solucionan ya que se puede crear como memoria automatica en una clase ya que el compilador sabe el tamaño del objeto.
Espero que haya quedado claro el problema de usar un constructor y los problemas de diseño que ocasiona en un futuro.
Jare el diseño que das tu tiene el problema que he comentado, cuando tienes mas de los 5 managers clasicos te das cuenta que no es factible derivar todo el tiempo del template manager, te hace perder tiempo y hace el codigo engorroso, ademas si por algun casual en un futuro quieres tener la funcionalidad del manager derivando otra clase que haga otras cosas tendrias que juntarlas haciendo un interfaz de las dos, lo implica mas perdida de tiempo a la hora de programar esos casos, parametrizando el template con todos sus valores posibles evista estas cosas.
Usar parametros enteros para templates es relativamente frecuente (p.ej. Vector), pero NO hablamos de números sino de... ¿cadenas? ¿No puedes contarnos QUE es lo que hace tan imprescindible que la construcción de los managers no reciba parámetros? ¿Estás creando arrays u otros contenedores con tus Managers? (En C++0x pretenden resolver ese defecto de C++ con los "sequence constructors", pero seguro que se dejan algo ;)) ¿O lo haces con la idea de optimizar alguna operación? Podría ser un sizeof(tag) en vez de strlen(tag), pero si hablas de leer tags de XML, la unica operación que normalmente harias con el tag dichoso es como mucho un strcmp(), y eso no va a cambiar porque la cadena sea un parámetros del template. Y en cualquier caso, ese coste debería ser nulo en la practica si la lectura está bien diseñada.
Ni idea, pero me encantaría conocer la justificación real. En fin, si realmente quieres hacerlo, la unica forma es con los static.
Realmente es comodidad :D, como veo que a pocos os convence el tema de pasar strings a un template como parametros he decidido cambiar el chip y ni constructor y ni template :D
He hecho una capa por encima de la libreria para tratar xml, ahora segun lo tengo montado con definir unas estructuras se hace el parser del xml automaticamente y despues haces lo que quieras con la jerarquia de arrays creada, un ejemplo:
using namespace dib::XML;
static Flag flag[] =
{
{"uno", 1},
{"dos", 2},
{"cuatro", 4},
{"ocho", 8},
{NULL, 0},
};
struct Item
{
int texture;
int flags;
char name[32];
};
static Format itemFormat[] =
{
{"id", Format::Type::Index, 0, 0, NULL, NULL},
{"texture", Format::Type::Number, XML_OFFSET(Item, texture), XML_SIZE(Item, texture), NULL, NULL},
{"name", Format::Type::String, XML_OFFSET(Item, name), XML_SIZE(Item, name), NULL, NULL},
{"flags", Format::Type::Number, XML_OFFSET(Item, flags), XML_SIZE(Item, flags), flag, NULL},
{"/item", Format::Type::Complete, 0, 0, NULL, NULL},
{NULL, Format::Type::End, 0, 0, NULL, NULL},
};
struct List
{
Array *items;
};
static Format listFormat[] =
{
{"id", Format::Type::Index, 0, 0, NULL, NULL},
{"item", Format::Type::Array, XML_OFFSET(List, items), sizeof(Item), NULL, itemFormat},
{"/list", Format::Type::Complete, 0, 0, NULL, NULL},
{NULL, Format::Type::End, 0, 0, NULL, NULL},
};
struct Body
{
Array *items;
};
static Format bodyFormat[] =
{
{"body.list", Format::Type::Array, XML_OFFSET(Body, items), sizeof(List), NULL, listFormat},
{"body./body", Format::Type::Complete, 0, 0, NULL, NULL},
{NULL, Format::Type::End, 0, 0, NULL, NULL},
};
void main()
{
..... // Abrimos el stream y lo seleccionamos en la clase xml
Reader reader;
Array bodies( bodyFormat, sizeof(Body) );
if( reader.Start(xml, &bodies) )
{
// Tratar todas las estructuras
...
}
En este ejemplo el lector xml lee automaticamente una estructura xml de este tipo en la que puede haber multiples tags list y un solo body:
<?xml version="1.0"?>
<body>
<list>
<item id="15" flags="uno,dos,tres,cuatro,ocho">
<texture>25</texture>
<name>Esto es una prueba</name>
</item>
<item id="16" flags="uno,dos,tres,cuatro,ocho">
<texture>25</texture>
<name>sdfas f asfsd</name>
</item>
<item id="17" flags="uno,dos,tres,cuatro,ocho">
<texture>25</texture>
<name>sdfas f asfsd</name>
</item>
<item id="18" flags="uno,dos,tres,cuatro,ocho">
<texture>25</texture>
<name>sdfas f asfsd</name>
</item>
<item id="19" flags="uno,dos,tres,cuatro,ocho">
<texture>25</texture>
<name>sdfas f asfsd</name>
</item>
<item id="100" flags="uno,dos,tres,cuatro,ocho">
<texture>25</texture>
<name>sdfas f asfsd</name>
</item>
<item id="200" flags="uno,dos,tres,cuatro,ocho">
<texture>25</texture>
<name>sdfas f asfsd</name>
</item>
</list>
</body>
Ademas comprueba si los tags son correctos, convierte strings a valores numericos, etc. aun lo tengo en fase beta, pero ya permite crear los administradores como le plazca al programador.
La forma de tratar las estructuras es mediante arrays con lo que no tiene complicacion alguna, las ventajas son simples:
- no importa que haiga mil objetos que se lean de la misma manera ya que con este sistema con definir una vez el formato nos vale para todos y ademas es reutilizable aunque su tag padre sea diferente
- con realizar el parser de todos los xmls al principio y quearnos con las estructuras que se crean ya nos vale, evitando tener que hacer el parser xml cada vez que indiquemos un archivo, es decir, el manager sabe automaticamente como crear un recurso si no existe con solo indicarle el indice numerico
- todas las clases pueden crearse desde xml si tienen definida este sistema, tan solo deben de tener un constructor que admita la clase Array de xml.
- comprobacion automatica de los tags, es decir, el orden de los tags (padre/hijo) importa
- miles de lineas de codigo para leer diferentes formatos de xml desaparecen dejando solo las estructuras que ocupan poca cosa
Y fijo que tiene mas ventajas pero aun no he visto.
Espero que este sistema os parezca menos polemico o extraño.
Editado: Imagen del codigo por que aqui sin tabulaciones queda guarrisimo
(http://img61.imageshack.us/img61/6742/dibujo3wd.th.jpg)