Toda La Vida Haciendolo Asi

[nsL]

 

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!

[zupervaca]

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.

[Jare]

 

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:

Código [Seleccionar] Expand


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. ;)

[Loover]

 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.

[zupervaca]

 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.

[Jare]

 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.

[zupervaca]

 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:

Código [Seleccionar] Expand

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:

Código [Seleccionar] Expand

<?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