Hola a todos. A ver si me podeis aclarar una duda. Supongamos que tenemos dos clases A y B.
La clase A seria:
#ifndef AH
#define AH
//---------------------------------------------------------------------------
#include "B.h"
//---------------------------------------------------------------------------
class A
{
B b;
};
//---------------------------------------------------------------------------
#endif
La clase B seria:
#ifndef BH
#define BH
//---------------------------------------------------------------------------
#include "A.h"
//---------------------------------------------------------------------------
class B
{
A a;
};
//---------------------------------------------------------------------------
#endif
Si compilo esto me da el siguiente error en la clase A "Type name expected". El problema lo resuelvo haciendo una declaracion anticipada de cada clase pero eso solo me permite trabajar con punteros. Por ejemplo en la clase A puedo definir un puntero B* pero no puedo declarar un objeto B. Alguien sabe como puedo hacer para no tener que trabajar con punteros en un caso como este.
P.D. Con punteros ya me va bien, es solo por si hay una forma más sencilla y evidente que a mi se me escapa ;)
Deberias modificar el diseño de tu aplicación para evitar ese tipo de relaciones. El compilador jamás podrá generar el código que tu quieres(sin punteros)... intenta hacer una traza mental del orden de construcción de los objetos y verás por qué :rolleyes:
Me repito: mal diseño
Cuando te pase una cosa de estas, lo mejor que puedes hacer es tirar de declaraciones de clases adelantadas:
Citar
//Fichero A.H
#ifndef A_H
#define A_H
class B;
class A
{
B b;
};
#endif
//Fichero B.H
#ifndef B_H
#define B_H
class A;
class B
{
A a;
};
#endif
Y los #include "(a|b).h", déjalos para los ficheros cpp de turno.
Citar
El problema lo resuelvo haciendo una declaracion anticipada de cada clase pero eso solo me permite trabajar con punteros
Perdón, perdón, perdón. Debería haberme leido el post entero :rolleyes:
Como ha dicho Zaelsius ... dejas al compilador pensando: "que vino primero?, el huevo o la gallina?" :P
Por si no te das cuenta aun:
A tiene un B, B tiene un A, A tiene un B, B tiene un A ... etc.
Saludos.
Cita de: " ZaelSiuS @ 11/03/06"
Me repito: mal diseño
El caso es que me doy cuenta de que estoy trampeando el error pero como funciona :rolleyes: . Además esto de programar es como la vida misma. Una vez que coges vicios...
Imaginaros que en este caso A es un objeto 3D (CMesh) y que B en una clase (CLoader) para cargar varios tipos de archivo (BMP, TGA, OBJ, 3DS...). Ahora lo estoy solucionado con las clases anidadas de la siguiente forma:
CMesh mesh;
CLoader loader;
loader.load(string file, (void*)mesh.this);
Como lo enfocariais vosotros?
Pedazo de declaración recursiva. Lo dicho anteriormente, es un problema de diseño, deberias plantearte reestructurar, todos nos hemos encontrado con ese problema alguna vez.
CMesh no deberia de saber que existe una CLoader, pero CLoader si deberia de saber como trabajar con CMesh ya que CMesh se deberia de poder crear y modificar sin CLoader, ejemplo:
Fichero CMesh
class CMesh
{
CMesh(int triangulos, int vertices,...)
{
...
}
}
Fichero CLoader
#include "CMesh.h"
class CLoader
{
CMesh *leer(char* nombre)
{
int triangulos, vertices;
...
return new CMesh(triangulos, vertices,...);
}
}
Cita de: "Marci"
CMesh mesh;
CLoader loader;
loader.load(string file, (void*)mesh.this);
Como lo enfocariais vosotros?
Supongo que ese es un buen método, pero también podrias hacer que mesh fuese un puntero y entoces podrías hacer algo así:
mesh = loader.load(string file);
Pero si tu método te da buenos resultados...para que cambiar.
Se me adelantó zupervaca (rules) .
Cita de: " zupervaca @ 11/03/06"
CMesh no deberia de saber que existe una CLoader, pero CLoader si deberia de saber como trabajar con CMesh ya que CMesh se deberia de poder crear y modificar sin CLoader
Ahi esta mi mal diseño :angry: . Todas las clases que necesitan cargar datos de un archivo llevan una funcion load desde la que se llama a CLoader. El codigo completo seria asi:
void __fastcall CMesh::Load(AnsiString asFile)
{
// Cargamos los datos en la malla
CLoader Loader;
Loader.Load(asFile, this);
// Conseguimos un identificador para el buffer object
m_CGLExtensions.glGenBuffersARB(1, &m_iId);
// Creamos el buffer object
m_CGLExtensions.glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER, m_iId);
// Cargamos los datos en el buffer object
m_CGLExtensions.glBufferDataARB();
}
El mesh = loader.load(string file) ya lo pense pero como estoy dentro de la clase tendria que ser this = loader.load(string file) y no se puede
Yo creo que lo mejor sería que el tema de calgar el mesh no fuese un método de la clase CMesh, sino que lo hiciese un ResourceManager o algo así.
Para este tema es mejor tener tres clases como minimo, malla, lectores de formato de mallas y administrador de recursos, la malla no conoce a nadie, los lectores de formato de mallas conoce solo a la clase malla y el administrador de recursos conoce a todos los formatos de mallas, este ultimo se puede hacer que los conozca estaticamente o dinamicamente, es decir, que los conozca por que los hemos implementado directamente dentro de la clase o los conozca por que tengamos una clase base para todos los lectores que se entiende con el administrador de recursos, tipo plugin, este ultimo sin duda es la mejor eleccion.
Eso no es una clase anidada, sino una dependencia cíclica. Y no, no puede solucionarse sin punteros (no se si se puede con referencias), porque cuando haces
A a;
El compilador necesita saber cuanto ocupa un objeto de tipo A, y no puede saberlo de la forma en que lo tienes. En cambio, un puntero a cualquier tipo siempre ocupa igual, por eso se permite declarar punteros de clases que no están "todavía" definidas, pero que "existirán", que es lo que le dices cuando pones cosas como "class A;".
De paso, una clase anidada sería algo así:
class A
{
class B
{
};
};
Cita de: "AK47"Y no, no puede solucionarse sin punteros (no se si se puede con referencias)
Sí se puede solucionarse con referencias. El código sería:
class A;
class B
{
public:
B(A & padre) : a(padre) {}
A & a;
};
class A
{
public:
A(): b(*this) {}
B b;
};Te dará posiblemente un warning porque estás usando una referencia a this en la lista de inicialización de un constructor pero si no se usa la referencia en el constructor, funiona.
La solución es asimétrica ya que ambos objetos se tienen que construir a la vez y eso se hace construyendo A que contiene a B.
Yo utilizaría y de hecho lo hago asi la siguiente estructura:
Cmesh.h:
class Cmesh
{
}
CmeshLoader.h:
#include "Cmesh.h"
class CmeshLoader
{
bool load(const char*,Cmesh&);
};
Cmesh no tiene porque saber del loader. Pero loader si tiene que saber como leer a Cmesh.
Otra cosa es donde se almacene el mesh, que como se ha comentado sera cosa de un manager
de forma que:
CmeshMgr.h:
#include "Cmesh.h"
#include "CmeshLoader.h"
typedef std::vector TVec_Mesh;
class CmeshMgr
{
TVec_mesh m_Vec_Mesh;
bool load(const char* fileMesh)
{
Cmesh Mesh;
CmeshLoader ML;
if (!ML.load(fileMesh,Mesh))
{
return (false);
}
m_Vec_Mesh.push_back(Mesh);
}
}
Se puede mejorar haciendo
typedef std::vector TVec_mesh;
asi no hay que hacer tantas copias... espero que te ayude.
Yo no uso std pero me parece que al usar push_back estas pasandolo por referencia y no hace copia, lo mas seguro que al poner Cmesh* te de error ya que le sera imposible resolver Cmesh*&, otra cosa, en un manager deberia de poder indicarse un indice para cada recurso y asi reaprovecharlo.
Las STL funcionan a base de copias, por lo que si le pasas un Cmesh al push_back, te lo va a copiar, con el consiguiente problema de punteros copiados al tuntun etc. Para controlar esto puedes definir el constructor de copia y el operador de asignación, o usar un std::vector (no olvidarse de borrar los punteros cuando toque, que nos conocemos :D). Tampoco estaría mal usar el std::string en vez de const char *, pero esto último es pa chinchar, más que nada :P
Pues segun estos links no es asi, podria poner mas, pero en principio siempre que he puesto links no se han hecho caso.
http://www.cppreference.com/cppvector/push_back.htmlhttp://decsai.ugr.es/~mgs/ed/stl.htmlhttp://support.microsoft.com/?scid=kb;es;158620Citarvoid vector::push_back(const _TYPE& X);
Se pasa por referencia, con lo que no realiza una copia.
Si a lo que te refieres es que dentro de esta funcion crea una clase copia pues si, son una mierda las std :P
En efecto, me refería a que es dentro de push_back se copia lo que apunta la referencia. Mmmmm, ¿por que son una mierda las STL? Yo creo que están de puta madre :)
Bueno, pues a pesar de que funcionaba lo he cambiado siguiendo varias de las ideas que me habeis dado. Basicamente he sacado la clase CLoader del interior de la clase CMesh. Ahora si quiero cargar una malla, una textura o lo que sea:
CLoader Loader;
CMesh Mesh;
Loader.Load("Malla.obj", Mesh);
CTexture Texture;
Loader.LoadTexture("Textura.bmp", Texture);
A mi las STL me van bien para la mayor parte de los casos.
Cita de: "AK47"Mmmmm, ¿por que son una mierda las STL? Yo creo que están de puta madre :)
Y efectivamente, STL está de puta madre. Muchos consideran que su uso en el desarrollo de videojuegos es inadecuado por lo que respecta al rendimiento; en realidad, el problema muchas veces está en la elección de la estructura de datos concreta a utilizar: si eliges la estructura incorrecta evidentemente el rendimiento no será el óptimo. Del mismo modo, puede haber problemas con la reserva dinámica de memoria para un contenedor particular o con la introducción de copias extras al copiar elementos. También tienes inconvenientes como el depurado de código, los mensajes de error crípticos y la reserva de memoria en entornos como las consolas.
Es decir, que la gran mayoría de problemas vienen asociados al desconocimiento de lo que ocurre a nivel interno cuando se trabaja con STL. En situaciones específicas podrás crear estructuras más rápidas, utilizando conocimientos avanzados de los datos con los que trabajes o de la plataforma sobre la que se ejecute tu programa.
Decir que STL es una mierda implica admitir no tener ni puta idea de STL. Lo importante es saber elegir la herramienta adecuada para el trabajo adecuado. Y STL cumplirá con creces en la gran mayoría de ocasiones. Porque no hay que olvidar que STL es el producto de una mejora continuada con el paso de los años por parte de cientos de programadores, y el resultado es un código robusto, genérico y fiable; que, insisto, será la mejor elección en la mayoría de los casos.
Y que esto lo diga yo no tiene ninguna importancia, pero recordemos que en la inmensa mayoría de libros o papers actuales sobre desarrollo de videojuegos se utiliza STL sin plantearse la conveniencia de su uso.
Son una mierda por que dan una funcionalidad peor que escasa, ademas de que si traceas el codigo te puede dar la risa de las chapuzas que se ven para ser algo que se quiere mostrar como estandar.
CitarDecir que STL es una mierda implica admitir no tener ni puta idea de STL
Sabia que estarías al acecho :P, STL es
esto, si te parece un trabajo de años no quisiera ver lo que tardarían en hacer algo decente, solo se puede decir una cosa, obsoleto.
Cita de: "zupervaca"Son una mierda por que dan una funcionalidad peor que escasa, ademas de que si traceas el codigo te puede dar la risa de las chapuzas que se ven para ser algo que se quiere mostrar como estandar.
Estaría bien que dieras ejemplos concretos antes de afirmar eso tan tajantemente.
Pero, oye, que no voy a ser yo quien te intente convencer de las bondades de STL (y de sus inconvenientes, que algo ya he comentado). Lo tomas o lo dejas.
Yo no puedo decir que sean buenos o malos por desconocimiento. Eso si, la unika vez q intente usar vector, con sus queridos pop y push no iba ni p'atras. De hecho puse en su dia un post aqui, y la gente no sabia el porque de su No funcionamiento :P
Saludos!
PD:
Mi post del que hable
Un ejemplo mas claro de por que son una mierda es un tio que esta empezando a programar en basic y le enseñan el gosub, el dira que es una pasada, dentro de un tiempo vera las funciones y dira que son una pasada y que vaya mierda el gosub, pues basicamente esto es lo que pasa con stl, el dia que den un buen soporte como las collections del csharp me callare la boca y pondre el culo en pompa :D
Hombre, creo que ahí faltan los algoritmos de las STL. Además, lo bueno de los mismos no son solo estas cosas sino todos los conceptos que usan (iteradores, etc), de forma que cada cual puede crear un "containers" que aproveche toda la infraestructura de las STL.
Cita de: "zupervaca"Un ejemplo mas claro de por que son una mierda es un tio que esta empezando a programar en basic y le enseñan el gosub, el dira que es una pasada, dentro de un tiempo vera las funciones y dira que son una pasada y que vaya mierda el gosub, pues basicamente esto es lo que pasa con stl, el dia que den un buen soporte como las collections del csharp me callare la boca y pondre el culo en pompa :D
Vamos, que no dices nada. Quizá porque realmente no conoces STL o no la has tocado a fondo. :lol:
Cita de: "zupervaca"Hombre, creo que ahí faltan los algoritmos de las STL. Además, lo bueno de los mismos no son solo estas cosas sino todos los conceptos que usan (iteradores, etc), de forma que cada cual puede crear un "containers" que aproveche toda la infraestructura de las STL.
Efectivamente. Entre las estructuras de datos y los algoritmos de STL, tienes un sistema potentísimo a tu disposición.
CitarVamos, que no dices nada. Quizá porque realmente no conoces STL
Puse esto:
CitarSon una mierda por que dan una funcionalidad peor que escasa
Citarel dia que den un buen soporte como las collections del csharp me callare la boca y pondre el culo en pompa
En definitiva para cualquier persona le valdria para picarle la curiosidad e ir a ojear las collections de csharp.
Los iterators estan explicados
aqui que se encuentra en la misma pagina web que he puesto antes, solo era pulsar sobre el link superior izquierda "cppreference.com" y luego se veia el link abajo a la derecha, los iterators no son nada nuevo ni cuando se empezo a hacer la stl.
Sobre el ejemplo del basic con el gosub y las funciones creo que no lo entendiste, es sencillo, si no se ha visto nada mejor (no quiero ofender con esto ya que no ver nada mejor no significa ser peor ni nada por el estilo) pues claro que son una pasada, pero para el que ha visto cosas mejores son una mierda.
Vaya la que se ha montado con la STL...
El mayor problema que puede encontrarse programando con estas puede llegar a ser la declaración de tipos de datos, como iteradores o contenedores anidados, pudiendo llegar a verse cosas como "std::map, std::set > > >::reverse_iterator", pero no es nada que no se pueda arreglar con unos typedef's bien situados.
Lo bueno de la STL es que es puedes usar la estructura más apropiada según tus necesidades, y no matar una mosca a cañonazos como viene siendo habitual últimamente.
Por ejemplo, si quieres indexación, usa un vector o un deque, pero ten en cuenta que puede darse el caso de que, al hacer un push_back en un vector (no se si pasará lo mismo con los deques), puede ser que se reserve una nueva zona de memoria equivalente en tamaño (corregidme si me equivoco) a la ya asignada para este.
Una lista, por el contrario, no te va a hacer eso, pero ojito si tienes que acceder a los elementos de esta: No hay indexación, por lo que te ves obligado a hacer una búsqueda de orden O(n).
Para mi, la STL es la mejor biblioteca para un lenguaje jamás construida. Viene a ser como la Gentoo es a GNU/Linux :D.
Eso de los chorizos "STL"riles se solucionará en parte con la próxima iteración de C++, que traerá la palabra clave "auto", con el que podras hacer cosas como:
std::map<chorizo impresionante> mapaNoseke;
for(auto it = mapaNoseke.begin(); it != mapaNoseke.end(); ++it)
{
// Bla bla
}
Gracias por ser tan criticos con el codigo, pero no me voy a poner a escribirlo todo al detalle. Solo pretendía exponer un ejemplo de uso y estructura.
Para los 'mitismiquis', que se quejan de todo:
Cresource.h:
class Cresource
{
int m_id;
};
Cmesh.h:
class Cmesh : public Cresource
{
}
CmeshLoader.h:
class Cmesh;
class CmeshLoader
{
bool load(cont std::string&,Cmesh*);
};
CmeshMgr.h:
#include
Cita de: "zupervaca"CitarVamos, que no dices nada. Quizá porque realmente no conoces STL
Puse esto:
CitarSon una mierda por que dan una funcionalidad peor que escasa
Citarel dia que den un buen soporte como las collections del csharp me callare la boca y pondre el culo en pompa
En definitiva para cualquier persona le valdria para picarle la curiosidad e ir a ojear las collections de csharp.
Los iterators estan explicados aqui que se encuentra en la misma pagina web que he puesto antes, solo era pulsar sobre el link superior izquierda "cppreference.com" y luego se veia el link abajo a la derecha, los iterators no son nada nuevo ni cuando se empezo a hacer la stl.
Sobre el ejemplo del basic con el gosub y las funciones creo que no lo entendiste, es sencillo, si no se ha visto nada mejor (no quiero ofender con esto ya que no ver nada mejor no significa ser peor ni nada por el estilo) pues claro que son una pasada, pero para el que ha visto cosas mejores son una mierda.
Me refiero a que estás metiendo Basic y C# en una discusión de STL (C++). ¿Qué tiene que ver? Me parece muy bien que te emociones con las collections de C#, pero, ¿te van a aportar algo si tienes que programar en C++? Lo único que se me ocurre es que te interese implementar en C++ un sistema similar al de collections, pero me da que no podría alguien solito.
Y en cuanto a lo de los iterators, ¿acaso he dicho que supongan una novedad en STL o algo similar?
El problema es el mismo de siempre contigo: que metes "sobradas" de tanto en cuando. Pero te lo digo sin absolutamente ningún ánimo de ofender, de verdad. Tan sólo eso, que no veo la relación entre una cosa y otra.
¡Un saludo, zupervaca!
Te lo explico otra vez por que esta visto que sigues sin entenderlo, pero con c++ en vez de basic y con c++ en vez de csharp.
Las stl son una mierda por que dan poca funcionalidad es como cuando un tio esta aprendiendo c++ y aprende las a manejar stl y dice que es una pasada, al cabo de un tiempo se coge otra libreria identica al collections del csharp y ve que es una pasada y que las stl son una mierda.
¿Te gusta mas asi?
Citar¿te van a aportar algo si tienes que programar en C++?
Me aprender a diferencia la mierda de la calidad (twist), deberias de aprender metodologia ya que esta se puede aplicar a cualquier lenguaje de programacion, te explico esta frase para que veas que no es una sobrada, ver diferentes tipos de metodologia te ayuda a programar en todos los lenguajes, con lo que ver como estan hechas las collections del csharp te puede aportar muchisimo.
CitarEl problema es el mismo de siempre contigo: que metes "sobradas" de tanto en cuando. Pero te lo digo sin absolutamente ningún ánimo de ofender, de verdad. Tan sólo eso, que no veo la relación entre una cosa y otra
Al final parece que si tenia que ver, pero que no querias verlo o no lo veiais.
El problema es el mismo de siempre contigo: que eres una "especia nueva" y no un troll. Pero te lo digo sin absolutamente ningún ánimo de ofender, de verdad.
¡Un saludo, Flint!
STL da poca funcionalidad (¿me lo explique?) y cuando ves collections las consideras una mierda (¿me lo explique?)... :lol:
Juas. Dile eso a Scott Meyers. Dile eso a Mike McShaffry. Dile eso a Noel Llopis. Los primeros que me vienen a la cabeza. Me fío más de profesionales que lidian día a día con C++ que de ti, qué quieres que te diga. Y no digo que uno tenga que usar lo que usan los demás, pero cuando los demás están de acuerdo tan ampliamente en algo, por algo será. Aprende STL, y luego lee algún libro de ellos.
Por cierto, llámame troll o lo que quieras, pero el primero (y único) que ha dicho que STL es una mierda has sido tú. Lo siento, es superior a mí, pero cuando veo que se escribes tonterías sin argumentación alguna me veo obligado a responder. Aunque te moleste. Porque en ningún momento has especificado puntos concretos de STL, para ti es una mierda y no se hable más. Eso sí, de Basic y C# sí que escribes. :lol:
Citary cuando ves collections las consideras una mierda (¿me lo explique?)...
pues por que las collections son mucho mejores que las stl
CitarAprende STL, y luego lee algún libro de ellos
Las use hace unos años y por su escasa funcionalidad y tu amada lentitud de este libreria las deje tiradas y desde aquella uso unas propias, ¿no te acuerdas de otro hilo en el que decias que no tenia ni idea de lo que decia o algo asi?
http://www.stratos-ad.com/forums/index.php...38&t=6065&st=15. Al final del hilo se ve el codigo de lo que segun tu no sabia lo que decia, bueno el caso es que hay uso una lista doblemente enlazada creada por mi llamada strip con tus queridos y espectaculares iterators que yo lo llamo item :P (dib::Collection::Strip
::Item *item), creo que se perfectamente las posibilidades de las stl, el problema es que tu no y crees que son maravillosas por que no has visto nada mas en tu vida.
CitarLo siento, es superior a mí, pero cuando veo que se escribes tonterías sin argumentación alguna me veo obligado a responder
Tener una opinion diferente a ti es decir tonterias, solo hay que ver el post y que sucede cuando has comenzado a postearm, solo sabes que joder post ya que parece ser que te jode sencillamente dar una opinion ¿por que solo te has molestado tu? ¿no has llegado a pensar en eso? puede que los demas respeten mi opinion como yo respete que a ellos les guste stl, pero eso no implica que no pueda decir que las stl son una mierda.
CitarEso sí, de Basic y C# sí que escribes
Busca en un diccionario lo que es una metafora. Por si sigues sin entenderlo te lo repito
"Las stl son una mierda por que dan poca funcionalidad es como cuando un tio esta aprendiendo c++ y aprende las a manejar stl y dice que es una pasada, al cabo de un tiempo se coge otra libreria identica al collections del csharp y ve que es una pasada y que las stl son una mierda.
¿Te gusta mas asi?
Y te lo explico, si nunca has visto nada mejor es normal que digas que stl es una pasada, el dia que veas algo mejor te daras cuenta que stl no es nada del otro mundo.
Cita de: "zupervaca"Citary cuando ves collections las consideras una mierda (¿me lo explique?)...
pues por que las collections son mucho mejores que las stl
CitarAprende STL, y luego lee algún libro de ellos
Las use hace unos años y por su escasa funcionalidad y tu amada lentitud de este libreria las deje tiradas y desde aquella uso unas propias, ¿no te acuerdas de otro hilo en el que decias que no tenia ni idea de lo que decia o algo asi? http://www.stratos-ad.com/forums/index.php...38&t=6065&st=15. Al final del hilo se ve el codigo de lo que segun tu no sabia lo que decia, bueno el caso es que hay uso una lista doblemente enlazada creada por mi llamada strip con tus queridos y espectaculares iterators que yo lo llamo item :P (dib::Collection::Strip::Item *item), creo que se perfectamente las posibilidades de las stl, el problema es que tu no y crees que son maravillosas por que no has visto nada mas en tu vida.
CitarLo siento, es superior a mí, pero cuando veo que se escribes tonterías sin argumentación alguna me veo obligado a responder
Tener una opinion diferente a ti es decir tonterias, solo hay que ver el post y que sucede cuando has comenzado a postearm, solo sabes que joder post ya que parece ser que te jode sencillamente dar una opinion ¿por que solo te has molestado tu? ¿no has llegado a pensar en eso? puede que los demas respeten mi opinion como yo respete que a ellos les guste stl, pero eso no implica que no pueda decir que las stl son una mierda.
CitarEso sí, de Basic y C# sí que escribes
Busca en un diccionario lo que es una metafora. Por si sigues sin entenderlo te lo repito
"Las stl son una mierda por que dan poca funcionalidad es como cuando un tio esta aprendiendo c++ y aprende las a manejar stl y dice que es una pasada, al cabo de un tiempo se coge otra libreria identica al collections del csharp y ve que es una pasada y que las stl son una mierda.
¿Te gusta mas asi?
Y te lo explico, si nunca has visto nada mejor es normal que digas que stl es una pasada, el dia que veas algo mejor te daras cuenta que stl no es nada del otro mundo.
Contigo no se puede discutir, definitivamente se te va la olla y repites las mismas "argumentaciones" sin sentido alguno. Y encima parece que te ofendes: relájate, tío, esto es un foro y cada uno tiene su opinión, aunque la tuya la das y no justificas nada, te vas por las ramas y metes cosas sin relación alguna.
Take it easy.
Por cierto, te recomiendo este producto para mejorar tus habilidades en la lectura y comprensión de materiales escritos, que es lo que te falla:
(http://img47.imageshack.us/img47/1488/leer14aw.jpg)Y además, quién sabe, quizá los programas de Pipo usen STL... :lol:
Güenooo! Se masca la tragedia por aqui XD
Bueno, no pretendo echar más leña al fuego, pero sí decir que la referencia en la que zupervaca se está asentando es muy poco profunda y escueta, te da solo la punta del iceberg.
Para documentarse en la STL, mejor
esta.
hilo equivocado, viva el refresh