Bgl + Escape

[fiero]

 A mí me gusta la forma de programar de sés. Yo programo igual. Y no entiendo nada de poo de lo que estais hablando XD

El tamaño importa.

un saludo

[shephiroth]

 Buenas....

Respecto al offtopic, y yo que creía saber algo de POO   O_O
El tema esta bastante interesante, pero si que es cierto que quizás este post no sea el mejor lugar. Os invito (como si lo necesitarais, sorry >_<) a crear un post en general o en offtopic para continuar este alocado pero interesante tema xDD

Respecto a BGL+Escape, mis felicitaciones sés, tanto por la libreria como con el juego  (ole)  (ole)

[sés]

 

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

Lo más gracioso es que tu juego era el de 4Kb X'D

A mí me gusta la forma de programar de sés. Yo programo igual.

Gracias.

Respecto a BGL+Escape, mis felicitaciones sés, tanto por la libreria como con el juego  (ole)  (ole)

Gracias de nuevo :)

No pasa nada por el off-topic, pasa siempre, qué se le va a hacer. Igualmente me parece un tema interesante.
Estoy acostumbrado a C y a Java, no soy precisamente un experto en C++ y en su forma de hacer las cosas. Todo lo que pueda aprender estará bien.
Como ya dije, yo no he hablado a favor ni en contra de STL. Supongo que están bien para lo que están, nada más. Lo único que defiendo, y que no veo nada raro ni malo en ello (que para algo somos programadores), es el rehacernos las cosas que no nos gusten.

Lo dicho, me apunto a otro hilo para hablar del tema.


P.D.: Ya he quitado mi clase Vector de BGL, ale. Irá en la próxima versión.

[ethernet]

 Con respecto a BGL símplemente hice un comentario pero me parece muy respetable que sés no quiera meter STL, hay muchos programadores que por una u otra razón no usan STL. Si ir más lejos tim sweney no usa STL en el code del unreal y se codea sus propios contenedores. En mi opinión los hubiera usado pero, como digo, es un opinión como cualquier otra. En cuanto a la librería me parece bastante interesante y que el desarrollo y progresión que ha llevado es muy buena. Además a todo el desarrollo de la librería se le un el juego del concurso 24 horas que es un buen escaparate para la librería.


En cuanto al offtopic: Yo definendo el uso de templates, no para todo, pero sí para lo que es necesario y acepto (y uso ) otras opciones como las que zupervaca cita (usar void* como contenedor) pero sabiendo las restricciones que eso conlleva (uso para tipos básicos, sin necesidad de construcción explícita, sin herencia, etc). Esta discusión podría ser fructífera si los problemas que he propuesto sobre la implementación que propone zupervaca fueran coherentes, sin embargo no he obtenido ninguna respuesta que me sirva, y por extensión, que sirva  a nadie interesado en el tema. Un ejemplo de las contradicciones es el último post:

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

Te plateo el siguiete código:

Código [Seleccionar] Expand


#include <iostream>

class B {            public:    virtual void foo() { std::cout << "B" << std::endl;}};
class D : public B { public:    void foo() { std::cout << "D" << std::endl;} };
class C {            public:    virtual void foo(){std::cout << "C" << std::endl; };};
int main()
{
 B* pb = new D;              
 B* pb2 = new B;
 C* pc = new C;

 D *pd;
 pd = dynamic_cast<D*>(pc);    //upcasteo mal
 if(!pd) std::cout << "fallo if 1" << std::endl; //me percato del error
 pd = (D*)(pc); //upcasteo mal
 if(!pd) std::cout << "fallo if 2" << std::endl; //ni puto caso del error
 pd->foo(); //WOPS! ¿?
 return 0;



Resultados

C:\temp> cl /GR 1.cpp
....
/out:1.exe
1.obj

C:\temp>1
fallo if 1
C

Como ves, un dinamic_cast no es un cast  convencional y tiene sus usos específicos (como los otros 3 cast de c++, e gustaría ver como haces un cast de const a no const con uno de esos tuyos de C tan útiles... ).

Esto aplicado a tu código:

Código [Seleccionar] Expand



tuvector v1;
v1.push_back(new C);

D* d =(D*) v1.get(0);
d->foo(); //error



usando templates y cast adecuados obtendrás errores de compilación y errores en ejecución cuando la cagues. Como ves no se pueden hacer cosas así como así y si en C, C++ y demás lenguajes tipados (C++ fuertemente tipado a mi modo de ver) son para algo, no para pasárselo por el forro. En el caso de herencia múltiple tienes muchísimos más problemas, ejemplos tienes en:  http://msdn.microsoft.com/library/default..../express_72.asp

Supongo que como no te equivocas nunca porque eres un programador que no se equivoca no necesitarás este tipo de cast. Supongo que tampoco harás programas en los que no sepás qué tipo de dato te viene y tengas que definirlo en tiempo de ejecución (ejemplo en la url que te he dado) o quizás te programes tu propio RTTI y así continúes con la tónica de reinventar la rueda programandote un vector para recudir unos 3 o 4k's de código. Si quieres un ejemplo de lo que se puede hacer con templates y C++ solo tienes que mirar el cotw que puse hace unos meses o leerte el libro modern c++ design. La potencia que ofrecen los templates supera con creces la pérdida de espacio en disco e incluso con templates puedes usar código especializado para diferentes plataformas, mejorando el espacio en disco y la velocidad de ejecución (puedes verlo en modern c++ design).

Otra cosa que me gustaría ver es la lentitud de std::vector, teniendo en cuenta que muchos de los métodos que usa son inline (usa bastante métodos porque tiene un código muy ortogonal) y que a la hora de reservar memoria  lo hace de una forma lógica me sorprende que digas eso. Lógicamente cada cosa tiene su uso y no es lógico usar un vector si necesitas hacer inserciones continuadas en el medio del vector. Ya buscaré algún benchmark acerca de eso, tengo curiosidad.

No voy a hacer ningún comentario más acerca de este tema, si acaso de BGL.

saludos

[zupervaca]

 bien en el primer codigo que indicas que falla no es un fallo en si, si el programador no sabe con que clase trabaja es que no sabe sencillamente lo que hace, en ningun caso excepto con templates esto sucede, un motivo mas para eliminarlos de nuestros codigos ya q

[zupervaca]

 ** no se que ha pasado pero tengo que volver a escribir todo el post

bien en el primer codigo que indicas que falla no es un fallo en si, si el programador no sabe con que clase trabaja es que no sabe sencillamente lo que hace, en ningun caso excepto con templates esto sucede, un motivo mas para eliminarlos de nuestros codigos ya que el dinamic_cast de c++ añade codigo extra a nuestros codigos de forma oculta lo que puede provocar que la velocidad general disminuya

en el segundo codigo un contenedor solo tiene un tipo de clase y el programador siempre sabe cuala es ya que si guardas 100 tipos de clases diferentes tendrias que poner 100 ifs para saber que clase es

usando templates y cast adecuados obtendrás errores de compilación y errores en ejecución cuando la cagues

plantear bien el codigo evita precisamente "cagarla", el dinamic_cast solo agrega codigo extra de forma oculta para programadores que efectivamente no saben lo que hacen

Supongo que como no te equivocas nunca porque eres un programador que no se equivoca no necesitarás este tipo de cast. Supongo que tampoco harás programas en los que no sepás qué tipo de dato te viene y tengas que definirlo en tiempo de ejecución (ejemplo en la url que te he dado) o quizás te programes tu propio RTTI y así continúes con la tónica de reinventar la rueda programandote un vector para recudir unos 3 o 4k's de código

normalmente el programador sabe el tipo de dato que es y si no es asi en la clase base se indica una variable para indicarlo, que es algo parecido a lo que hace dinamic_cast de forma oculta y luego como harias con el dinamic_cast compruebas con ifs para saber si es el tipo de dato que buscas

Si quieres un ejemplo de lo que se puede hacer con templates y C++ solo tienes que mirar el cotw que puse hace unos meses o leerte el libro modern c++ design. La potencia que ofrecen los templates supera con creces la pérdida de espacio en disco e incluso con templates puedes usar código especializado para diferentes plataformas, mejorando el espacio en disco y la velocidad de ejecución (puedes verlo en modern c++ design).

el template nunca podra ser mejor que una clase ya que el template es una plantilla para crear clases, el compilador usa el template para crear una clase por tipo de template, esto tiene que quedarte muy claro, la multiplataforma se puede hacer mucho mejor sin templates creando una clase base plataforma y derivando de ella y optimizando 100% para cada plataforma, que yo sepa por ahora todo el mundo lo ha hecho asi, desde glu hasta el famoso y moderno glfw (http://glfw.sourceforge.net/)
sobre esto que solo te quede claro que los templates como su nombre indica son plantillas generadoras de clases es como si cambiaras todos los T por el nombre de la clase que has puesto

Otra cosa que me gustaría ver es la lentitud de std::vector, teniendo en cuenta que muchos de los métodos que usa son inline (usa bastante métodos porque tiene un código muy ortogonal) y que a la hora de reservar memoria lo hace de una forma lógica me sorprende que digas eso. Lógicamente cada cosa tiene su uso y no es lógico usar un vector si necesitas hacer inserciones continuadas en el medio del vector. Ya buscaré algún benchmark acerca de eso, tengo curiosidad.

los metodos inline solo evitan un salto o llamada, lo que realmente importa es la metodologia que usa la clase std::vector, la prueba de esto esta en la funcion standard qsort a la cual le pasas un puntero de funcion para comprobar los buffers a ordenar, me gustaria saber cuanto tarda en buscar 1 millon de registros en ese clase, en una tabla hash interpolada con arboles binarios 0,24 segundos a 1,25 segundos dependiendo del tamaño de la tabla hash con indices tipo string en un piii1200

No voy a hacer ningún comentario más acerca de este tema, si acaso de BGL.

realmente veo que crees que esto es una lucha y no sabes que para mi es un tema tan interesante y que a muchos les podemos ayudar a decidirse en usar o no usar templates y para que puede ser mejor usarlos o no


os voy a poner un ejemplo de lo que puede pasar usando templates:
- tenemos un template para realizar busquedas en nuestra base de datos de 10000 clientes, estos clientes tienen 20 tipos de indices, por cada indice creamos un template y cada template ocupa 10kb compilado el resultado es 20 * 10kb = 200kb mas que ocupa en memoria y en la aplicacion, resulta que el ordenador en el que se trabaja tiene la memoria ram saturada y gracias a nuestra aplicacion que ocupa 200kb en vez de 10kb como deberia ser el ordenador tira de disco duro para crear y trabajar con memoria virtual retardado el sistema de busquedas!!!, consecuencia: comprar mas memoria ram  :lol:
como veis 190kb pueden llegar a ser muy importantes, si usaramos clases bases o void* solo ocuparia 10kb

otra cosa a tener en cuenta es que no por usar sobrecarga de operadores tenemos que usar templates, podemos sobrecargar diferentes tipos o el de la clase base asi como pasar de ellos y usar funciones de nombres; ej: void operator=(base*pepe); es lo mismo que void igualar(base*pepe);, ahora eso si los operadores quedan mas bonitos y son mas logicos

saludos y espero que el tema no pare que por mi parte me esta gustando hablar de ello

[sés]

No voy a hacer ningún comentario más acerca de este tema, si acaso de BGL.

realmente veo que crees que esto es una lucha y no sabes que para mi es un tema tan interesante y que a muchos les podemos ayudar a decidirse en usar o no usar templates y para que puede ser mejor usarlos o no

No es una lucha, solo un off-topic como un piano.

-_- *saca la escoba y empieza a barrer el hilo*

[ethernet]

 -con respecto a dinamic_cast y lo que comentas de añadir una variable a la clase base para indicar el tipo de la clase derivada: eso se llama RTTI y no es necesario que te hagas una clase.


-No he dicho que un template por si solo optimice el código, he dicho que puedes optimizar el código usandolos, como te he dicho  lee el libro modern c++ design y de paso aprendes algo de templates.

-Un template no genera código más lento:

template struct A { T a; };

struct B{ int a;}; es ___totalmente equivalente__ a A

-Por último comentar el ejemplo totalmente irreal que has pueso:

Código [Seleccionar] Expand


os voy a poner un ejemplo de lo que puede pasar usando templates:
- tenemos un template para realizar busquedas en nuestra base de datos de 10000 clientes, estos clientes tienen 20 tipos de indices, por cada indice creamos un template y cada template ocupa 10kb compilado el resultado es 20 * 10kb = 200kb mas que ocupa en memoria y en la aplicacion, resulta que el ordenador en el que se trabaja tiene la memoria ram saturada y gracias a nuestra aplicacion que ocupa 200kb en vez de 10kb como deberia ser el ordenador tira de disco duro para crear y trabajar con memoria virtual retardado el sistema de busquedas!!!, consecuencia: comprar mas memoria ram laugh.gif
como veis 190kb pueden llegar a ser muy importantes, si usaramos clases bases o void* solo ocuparia 10kb


Te reto a que intentes crear una aplicación que ocupe 10k sin templates y otra con templates y 20 tipos templatizados que ocupe 200kb o lo que quieras más, siendo representativo lógicamente, adelante.  (basado en std:vector y en tu versión)

Además por último te animo a que intentes hacer algo con templates para que veas el beneficio que obtienes y te dejes de milongas de 4 ó 5 kb más de código ejecutable que no son representativos actualmente para absolutamente nada.  Si quieres complicarte la vida por 5kb... adelante, tú mismo, un buen programador saber encontrar el equilibrio entre ese tipo de cosas.

ahora sí, fin







 

[zupervaca]

 

-con respecto a dinamic_cast y lo que comentas de añadir una variable a la clase base para indicar el tipo de la clase derivada: eso se llama RTTI y no es necesario que te hagas una clase.

la ventaja de hacerlo tu es sencilla, sabes lo que esta haciendo por debajo

-Un template no genera código más lento:

eso es lo que quiero decirte desde el principio, el template no es ni mejor ni peor simplemente genera clases y repite codigo, es otra forma de programar

Te reto a que intentes crear una aplicación que ocupe 10k sin templates y otra con templates y 20 tipos templatizados que ocupe 200kb o lo que quieras más, siendo representativo lógicamente, adelante. (basado en std:vector y en tu versión)

¿me estas diciendo que el compilador no genera una clase diferente para cada template? el compilador siempre hara una copia del template cambiara el tipo del template y lo compilara, por cada tipo de template el compilador siempre generara una nueva clase, si una clase generada con un template ocupan 10kb y haces 20 clases mas con diferentes tipos de template salen 200kb, las matematicas no fallan (eso solo contando el codigo compilado no hablo de sizeof(clase) que eso da el tamaño de los datos de la clase que es otra cosa totalmente distinta)

Además por último te animo a que intentes hacer algo con templates para que veas el beneficio que obtienes y te dejes de milongas de 4 ó 5 kb más de código ejecutable que no son representativos actualmente para absolutamente nada. Si quieres complicarte la vida por 5kb... adelante, tú mismo, un buen programador saber encontrar el equilibrio entre ese tipo de cosas.

ya he trabajado con ellos, para lo unico que valen es para repetir codigo compilado en tus aplicaciones, que es algo que nunca he entendido, si el c++ se base en la reutilizacion de todo el codigo posible ¿por que los templates crean funciones identicas con diferentes tipos?


saludox xente