Bgl + Escape

[zupervaca]

 he bajado el codigo fuente para hecharle un vistazo pero me da error el archivo comprimido  :(  

[sés]

 Es cierto, estaba mal. He vuelto a subirlo.

[ethernet]

 

bueno yo puedo decir y sentirme orgullo que yo no uso stl tampoco ya que usa templates (no os hecheis las manos a la cabeza jeje), los templates no me gustan por que por cada tipo que definas el compilador genera una clase entera con ese nuevo tipo y el exe y la memoria en ejecuacion aumentan, mientras que si usas conversiones de void solo generas una clase en disco y en memoria, ademas las conversiones entre puntero son "ficticias" ya que son para que el compilador entienda el tipo de dato y no implica perdida de velocidad en ningun caso y si no os gusta el void hacer una clase base y derivar de ella

Me hace bastante gracia que nos preocupemos de eso teniendo después:
1.- imágenes,  sonidos y modelos que ocupan 100 veces (me quedo corto) más que el código
2.- usando otras librerías que tienen miles de capas de abstracción, por dios, STL son contenedores

Me hace gracia también que se penalice el tamaño en memoria de ejecutable... como si el código fuera el responsable mayor del consumo de memoria que lo es, pero no por su propio código, si no por la memoria que el consume.

Además lanzo una pregunta: si el compilador no te genera el código autmáticamente, quien lo debe generar? y no quiero respuestas de void* ni nada así, puesto que hay implementaciones de contenerdores con una clase base basada en void* y por encima templatizadas para que el trabajo sucio lo haga el compilador. Dudo mucho que el que haga esas implementaciones tenga en mente el paradigma orientado a objetos y me gustaría ver  cómo lidia con operator=, etc, etc, si std::vector  tiene restricciones me gustaría ver esa implementación.  

Quiero matizar tb que aunque genere más código no quiere decir que la aplicación sea más lenta en ejecución ya que por introducir un template no añade código extra a cada una de las implementaciones.

En conclusión, para mi carece de sentido no usar STL salvo que sea porque estás codeando algo para un dispositivo embebido donde el tamaño si importa, seas tan bueno que seas capaz de hacer una implementación mejor o, como sés, te de el gusto de no usarla. En cuanto a la frase "los templates no me gustan" y "te ahorras la conversión de punteros" y los razonamientos posteriores me ahorré el comentario y dejaré que zupervaca lo medite.

[sés]

 Bueno ^_^... es que yo no tengo modelos que ocupen 100 veces más.

Si estoy haciendo un programa enorme, ese tamaño me daría exactamente igual.
Lo mismo si fuera para algo del trabajo. En el trabajo utilizo lo que tenga a mano, no voy a comerme la cabeza.

La diferencia es que por esto no me pagan, lo hago porque quiero. No me va a pasar nada por "perder" el tiempo rehaciendo algunas cosas a mi gusto, la verdad.

Otra cosa, es que BGL no es un programa. Yo no digo que alguna vez utilize STL para algún programa mío, o para algún juego, pero este no es el caso: es una librería. Una de las características que quiero que tenga, es que debe ser ligera.

Y esa clase Vector ni siquiera está en la documentación; es "privada" y no debería usarse de momento. Seguramente lo haga de otra forma (posiblemente con una lista o yo qué sé). Y si algún día veo que necesito utilizar STL en mi librería pues... qué narices, la uso y listo.

[zupervaca]

 ethernet realmente veo lo que sabes de programacion orientada a objetos desde la primera linea, pero te pondre un ejemplo rapido de como solucionar el problema de un contenedor la sobrecarga de operadores

class item
{
};

class contenedor
{
void operator << ( item &i );
};

class naveespacial : public item
{
};

void main()
{
nameespacial protagonista;
contenedor naves;
nave << protagonista;
}

lo he puesto sencillo para que veas la solucion, no se a mi me parece muy orientada a objetos  ;)  

[ethernet]

 ¿? no sé qué tiene que ver lo que yo te he puesto con lo que has puesto tú

Yo hago referencia a lo siguiente:

Código [Seleccionar] Expand


class  vector
{
void* _data;

void push_back(void*):
// etc

};


void main()
{
vector v1,v2;
v1.push_back(reinterpret_cast<void*>(new std::string));
//etc

v2 = v1; // no funciona,  porque string tiene su operator= y no es invocado

}



de estos ejemplos te puedo poner todos los que quieras

saludos

[ethernet]

 Ah! y por cierto no sé qué quieres decir con lo de "solo viendo la primera frase sé lo que sabes de programación orientada a objetos".  Frases de ese tipo sobran en mi opinión, las calificaciones personales las dejamos para la barra del bar.

[zupervaca]

 

Dudo mucho que el que haga esas implementaciones tenga en mente el paradigma orientado a objetos y me gustaría ver cómo lidia con operator=, etc, etc, si std::vector tiene restricciones me gustaría ver esa implementación.

de ahi lo saco que mas da << que =, son funciones que controlas como quieras, puedes hacer que << sea sacar en vez de meter o que incluso no haga nada o saque un mensaje en pantalla  :P

realmente ese ejemplo no se para que sirve, ya que no tiene sentido meter en una clase un string para ocultarlo, y si no creas una funcion en la clase vector con el operador igual no te funcionara en la vida hagas lo que hagas

Ah! y por cierto no sé qué quieres decir con lo de "solo viendo la primera frase sé lo que sabes de programación orientada a objetos". Frases de ese tipo sobran en mi opinión, las calificaciones personales las dejamos para la barra del bar.

es una opinion personal en la que no digo si es mala o buena con lo que no llega a calificacion y no te he podido ofender ni gratificar


si quieres que te funcione con clases derivadas que es en lo que consiste la programacion orientada a objetos se hace con este codigo:

Código [Seleccionar] Expand

class base
{
virtual base &operator=( base *clase ) = 0;
};

class string : public base
{
virtual base &operator=( base *clase );
}

class vector : public base
{
base *_data;
void push_back(base*);
virtual base &operator= ( base *clase );
}

void main()
{
vector v1, v2;
v1.push_back( new string() );
v2 = v1; // Si funciona ya que todo deriva de la clase base y en la funcion operator= de vector haces lo que quieras
}

pd: voy a acabar poniendo al pie de mis post la lucha contra el stl  (twist), yo creo que todos los ejemplos que se pongan siempre tendran solucion con programacion orientada a objetos, los templates como su nombre indica son plantillas y mientras mas plantillas mas tochas las apps, fijaros que simplemente si tienes un contenedor por cada tipo de dato (byte, word, dword, string, personalizados....) en una aplicacion grande puede aumentar mucho su tamaño, en cambio si derivas la clase contenedor y cambias la forma de calcular o buscar los indices estas agregando una sola funcion ya que todo el codigo se aprovecha, no se, no obstante cada uno es libre de programar como quiera, yo por mi parte pienso que los templates se usan por comodidad y no tener que pensar en jerarquias de clases

saludos

[ethernet]

 ¿? de nuevo
Se supone que un contenedor debe aceptar cualquier tipo de clase y no una derivada de una clase base que defines. Estás implementando en el fondo los que hacen lenguajes como C# o java. Haciendo eso lo único que consigues es tener que activar el rtti ...

Cuando puse el ejemplo de string, podrías haber puesto cualquier otra clase y sin necesidad de tener que heredar de un objeto base consigues la misma funcionalidad, de eso se trata, ese no es el objetivo que se propone.

Me gustaría ver el código para retornar de base* a la clase concreta que hemos metido y me gustaría ver también qué pasaría en el caso de querer (por error) asignar un string (derivado de base claro)  a un MiObjeto (tb derivado de clase)  por poner un ejemplo. Y no hablar claro de si hay por medio herencia, herencia múltiple u otras cosas.

por último cabe descatar que para implementar todo tu sistema basta con hacer:

typedef std::vector tuvector;

y con eso tengo implementado la clase vector en un momento, sin ocupar memoria extra (solo tengo la implementación para una clase) y además optimizadísima (tanto como son de expertos los que programan cualquier a de als implementaciones de STL).

Para eso sirve STL y para eso sirven los templates.

Con respecto a la frase y haciendo referencia a lo que dices me reafirmo más en mi opinión, esa frase sobra. Me parece que una frase no se pone para no decir nada.

saludos

[zupervaca]

 

Se supone que un contenedor debe aceptar cualquier tipo de clase y no una derivada de una clase base que defines. Estás implementando en el fondo los que hacen lenguajes como C# o java. Haciendo eso lo único que consigues es tener que activar el rtti ...

tu mismo das la solucion mas abajo, herencia multiple, el c# nunca lo he tocado y el java no es uno de los lenguajes que mas me gustan, incluso su sistema de eventos no me gusta

Cuando puse el ejemplo de string, podrías haber puesto cualquier otra clase y sin necesidad de tener que heredar de un objeto base consigues la misma funcionalidad, de eso se trata, ese no es el objetivo que se propone.

la clase base se pone precisamente para meter en la funcion del operador= de vector esto:
*_data = *clase;

Me gustaría ver el código para retornar de base* a la clase concreta que hemos metido y me gustaría ver también qué pasaría en el caso de querer (por error) asignar un string (derivado de base claro) a un MiObjeto (tb derivado de clase) por poner un ejemplo. Y no hablar claro de si hay por medio herencia, herencia múltiple u otras cosas.

pues si metes una clase por error seria lo mismo que si le metes a vector una conversion de un puntero a una clase que no toca; ej: v1.push_back( (tipo del template*)new aviondepapel ); con esto el template traga pa entro  :D
para retornar es de lo mas sencilla: base *get(){return _data; };
lo dicho la herencia multiple evita precisamente uno de los problemas que mencionabas arriba  :rolleyes:

por último cabe descatar que para implementar todo tu sistema basta con hacer:

typedef std::vector tuvector;

y con eso tengo implementado la clase vector en un momento, sin ocupar memoria extra (solo tengo la implementación para una clase) y además optimizadísima (tanto como son de expertos los que programan cualquier a de als implementaciones de STL).

el numero de lineas no importa, ya que entonces el lenguaje del basic gana a todos los demas  :P, ademas quien no te dice que la la clase vector que mencionas esta que da ascucho por dentro  B)

Con respecto a la frase y haciendo referencia a lo que dices me reafirmo más en mi opinión, esa frase sobra. Me parece que una frase no se pone para no decir nada.

esa frase dice algo para mi muy importante, que se tu nivel de programacion orientada a objetos  :)


saludos xente

[ethernet]

 

tu mismo das la solucion mas abajo, herencia multiple, el c# nunca lo he tocado y el java no es uno de los lenguajes que mas me gustan, incluso su sistema de eventos no me gusta

yo no doy ninguna solución de eso, y si es así muestramle aexplícitamente

a clase base se pone precisamente para meter en la funcion del operador= de vector esto:
*_data = *clase;

no respondes a mi pregunta, te la haré de forma directa: qué sucede si quiero meter en tu contenedor una clase de una librería aparte que no deriba de base?

pues si metes una clase por error seria lo mismo que si le metes a vector una conversion de un puntero a una clase que no toca; ej: v1.push_back( (tipo del template*)new aviondepapel ); con esto el template traga pa entro biggrin.gif
para retornar es de lo mas sencilla: base *get(){return _data; };
lo dicho la herencia multiple evita precisamente uno de los problemas que mencionabas arriba

por puntos:
1.- no usas los cast de c++ por lo tanto no me sirve ese ejemplo, esto es c++ no c.
2.- Yo no abogo por usar es implemenación, yo prefiero usar templates para evitar precisamente eso
3.- con respecto a retornar: me refería a como vuelves de un tipo base* al tipo que verdaderamente yo he metido?
4.- Con herencia múltiple lo único que haces aquí es liarla más porque tienes que ndar con herencia virtual si sigues tu patrón de seguir una clase base.

el numero de lineas no importa, ya que entonces el lenguaje del basic gana a todos los demas tongue.gif, ademas quien no te dice que la la clase vector que mencionas esta que da ascucho por dentro cool.gif

No he hablado del número de lineas y por cierto, la implementación de std::vector de SGI (que es a que yo uso) es bastante elegante aunque eso sí, con una notación infernal.


Por último me gustaría que respondieras a mis preguntas y no uses terminología de c++ que no responde y además confunde las respuestas.  En este post no has contestado a nada de lo que he preguntado, si la tónica en el siguiente post sigue así pasaré de largo de esta conversación porque no creo que beneficie a nadie y, la verdad, creo que ya todos saben lo que cada uno sabemos de OOP.

saludos

[zupervaca]

 

yo no doy ninguna solución de eso, y si es así muestramle aexplícitamente

si quieres agregar una clase que tiene otra clase base a un contenedor que requiere una clase base distitanta simplemente utiliza herencia multiple

no respondes a mi pregunta, te la haré de forma directa: qué sucede si quiero meter en tu contenedor una clase de una librería aparte que no deriba de base?

haz un interfaz que contenga la clase de esa libreria como se ha hecho toda la vida

no usas los cast de c++ por lo tanto no me sirve ese ejemplo, esto es c++ no c

Yo no abogo por usar es implemenación, yo prefiero usar templates para evitar precisamente eso

esos casting son validos 100%, ademas de que si te la pueden colar asi y tu no quieres sigue siendo problema del template o un bug de programacion, la solucion es muy sencilla, con una clase base podrias definir el tipo de clase en una variable y comprobar si son iguales o diferentes, quitando el bug al 100%, un ejemplo lo tienes en la clase CObject de las MFC

con respecto a retornar: me refería a como vuelves de un tipo base* al tipo que verdaderamente yo he metido?

se llama casting de toda la vida, aunque mejor seria decir que con el template solo puedes introducir un solo tipo de clase con lo que en el contendor siempre tienes un solo tipo de clase

Con herencia múltiple lo único que haces aquí es liarla más porque tienes que ndar con herencia virtual si sigues tu patrón de seguir una clase base

a mi no me resulta complicado trabajar con herencia multiple, es mas lo encuentro sumamente util y facil de utilizar en c++, ademas si no la quieres usar siempre tienes la posibilidad de realizar un interface como siempre se ha hecho

No he hablado del número de lineas y por cierto, la implementación de std::vector de SGI (que es a que yo uso) es bastante elegante aunque eso sí, con una notación infernal.

yo nunca he visto el codigo fuente de la clase std::vector y creo que la han hecho dos personas, para mi gusto la clase std::vector es lenta, siempre prefiero mi clase hash interpolada con arboles  :D

Por último me gustaría que respondieras a mis preguntas y no uses terminología de c++ que no responde y además confunde las respuestas.

es que el bgl esta programado en c++ y por eso salio el tema de templates en c++, ademas las stl tambien son c++, con lo que no logro entenderte

En este post no has contestado a nada de lo que he preguntado, si la tónica en el siguiente post sigue así pasaré de largo de esta conversación porque no creo que beneficie a nadie y, la verdad, creo que ya todos saben lo que cada uno sabemos de OOP

creo haber respondido a tus preguntas, pero si ves que falta alguna por responder ponmela directamente, yo por mi parte no creo ofender a nadie, el tema me parece interesante ya que tal vez sea yo el que me de cuenta que estoy equivocado nunca se sabe, por ahora los templates no me han convencido salvo si en un trabajo me exigieran usarlas  :), es mas, la ultima vez que me llamaron para una entrevista mencionaron si sabia manejar las stl, lo cual para mi me sorprendio ya que son cuatro clases y comparado con cualquier otro api mas moderno no son mucha cosa
en serio te digo que para mi esto no es ir en contra tuya ni nada, para mi es exponer dos opiniones diferentes y poder llegar conclusiones nuevas


saludos

[sés]

 A mí los templates me gustan, pero lo veo como XML: no es la solución a todo :P


Y a todo esto... (ses) ¿de qué iba este hilo?

[ethernet]

 Por mi parte pido disculpas a sés por entrometerme en el post de su librería.

en cuanto a zupervaca, como te dije, no has respondido a lo que te he preguntado y además demuestras tener carencias en el uso de cast y otras cosas, te recomiendo leer effective c++ y more effective c++. Te podría poner mil pegas a todos tus intentos de respuesta pero para eso lee un libro, te vendrá mejor.

saludos

[zupervaca]

 

Por mi parte pido disculpas a sés por entrometerme en el post de su librería.

en cuanto a zupervaca, como te dije, no has respondido a lo que te he preguntado y además demuestras tener carencias en el uso de cast y otras cosas, te recomiendo leer effective c++ y more effective c++. Te podría poner mil pegas a todos tus intentos de respuesta pero para eso lee un libro, te vendrá mejor.

saludos

¿realmente no ves el codigo que te estoy poniendo? ¿o simplemente no quieres verlo?
no te entiendo ya que estas viendo miles de soluciones para evitar usar templates y ahorrar memoria y tamaño del ejecutable y sigues diciendo que no son validos y que hay una pregunta que no te contesto.

¿que pregunta es esa?

los casting de c++ son para programadores que tienden a equivocarse al realizar casting y estos son meros chequeos que hace el compilador ya que no se si sabras que los casting son ficticios y solo sirven para que el compilador entienda que estructura es la que se esta procesando

me gustaria que me dijeras una sola pega de las miles que mencionas, por cada pega que pongas te aseguro que te digo varias buenas razones y desmiento esa pega  :P