Problema Desde Una Dll - Y divagaciones 5 años después

[Loover]

Bueno, en el post anterior me convenció la StlPort y empecé a usarla. Va de maravilla... excepto con un problema que no sé resolver.

El caso es que tengo una clase que será usada desde una DLL tal que:

Código [Seleccionar] Expand


#define DLL_EXP __declspec(dllexport)

class DLL_EXP LOV_ImageManager
{
public:
...
...
...
deque <int> mDequeImages;
...
...
...
void MetodoDePrueba ();
...
...
...
};


Hasta ahí todo bien, excepto que al compilar me da el siguiente warning:

Código [Seleccionar] Expand


warning C4251: 'mDequeImages' : class '_STL::deque<int,class _STL::allocator<int> >' needs to have dll-interface to be used by clients of class 'LOV_ImageManager'


Luego, en un método de esa clase tengo:

Código [Seleccionar] Expand


void LOV_ImageManager::MetodoDePrueba ()
{
mDequeImages.push_back(2);      // Le meto un int 2 por meterle algo de prueba
int tema = mDequeImages.at (0); // ESTA LÍNEA PEGA UN REVENTÓN
}


Cuando digo que pega un reventón, me refiero a más tarde. Compilar compila, aunque con ese warnig, y tb lo da al linkar.
Pues bien, una vez desde el código que usa esta DLL, al compilarlo me da el mismo warning. Luego al ejecutarlo pega un reventón en la línea que he señalado y el programa se cuelga.
Como veis he usado un "deque" (muy similar al "vector") pero no es cosa suya, esto peta con cualquier container. Vamos, que si pongo vector en lugar de deque peta igual.
El usar enteros en el deque es solo para hacer la prueba.
Otra cosa, si el deque, vector o el container que sea no está definido en la clase sino dentro de un método entonces no peta. Pero claro, yo quiero que ese container sea accesible por todos los métodos y que no se destruya al acabar el método en cuestión, vamos, que sea public o private.

¿Qué puedo hacer para remediarlo?

[Loover]

 Odio que haya un número fijo de ediciones del post.  <_<

Tb me da este warning:

Código [Seleccionar] Expand


warning C4786: '_STL::_STLP_alloc_proxy<LOV_ImageManager::structImage * * *,LOV_ImageManager::structImage * *,_STL::allocator<LOV_ImageManager::structImage *> >::~_STLP_alloc_proxy<LOV_ImageManager::structImage * * *,LOV_ImageManager::structImage *
*,_STL::allocator<LOV_ImageManager::structImage *> >' : identifier was truncated to '255' characters in the debug information


Aunque bueno este es en el depurado y no creo que haya problema ahí, o eso me han dicho.

[Grugnorr]

 Puede que necesites hacer el import .

#ifdef __BUILD_DLL_
#define __DLL_FUNCTION __ declspec(dllexport)
#else
#define __DLL_FUNCTION__ declspec(dllimport)

Y en la dll declaras el símbolo ese.

PD: Hay una cosa muy bonita llamada namespaces, mucho mejores que los prefijos en las funciones a mi juicio.

[Loover]

 Pues no me queda muy claro que es lo que tengo que hacer

Código [Seleccionar] Expand


#define __BUILD_DLL_

class __DLL_FUNCTION__ LOV_ImageManager ¿¿¿ o es class __BUILD_DLL_ LOV_ImageManager ???
{
public:

...
...


¿Eso?
Y por otro lado lo que has puesto, ¿no?

Pues eso pega un petamiento del copin. En el primer caso no compila y en el segundo caso compila (y sin warnings!!) pero el codigo que utiliza la dll me da un "unresolved external symbol" en los métodos que utilizo de esa clase, vamos, como si no la exportarse bien.
Por favor, explicamelo con algún ejemplo.

[Loover]

 Bueno pues un chaval del canal, EthDra, me ha solucionado el problema de una manera tan trivial que me da hasta vergüenza:

settings>c++>code generation>multithreaded dll

Mecagoentolosmuertosdelastlportlasdllylamadrequelaspario

[Grugnorr]

 Lo primero, me falta el #endif ^_^

#ifdef __BUILD_DLL_
#define __DLL_FUNCTION __ declspec(dllexport)
#else
#define __DLL_FUNCTION__ declspec(dllimport)
#endif                 <-----------

Código [Seleccionar] Expand


-----dll.h------------
#define __BUILD_DLL__

class __DLL_FUNCTION__ CExportada
{
public:

void f();
..........
};


Código [Seleccionar] Expand


----main.cpp------
void f()
{
CExportada kk;
kk.f();

}


Con eso tienes una clase exportada( el método fácil de las dlls).

Tienes que escoger entre crear un .lib que enlace con la dll->carga implícita o cargarla manualmente con LoadLibrary(), pillar los punteros a cada función con GetProcAddress() y liberar la dll con FreeLibrary().

Puede que no hayas linkado con la .lib de la dll

Mañana si tengo algo de tiempo me enrollo más, postea si tienes problemas...

PD: Pon la dll como multithreaded para que puedas traspasar dll boundaries o algo así me suena ^_^

[Grugnorr]

 Eso es posting concurrente  :D  

[Loover]

 Gracias a ti tb Grugnorr :D
Eso último que has dicho, el multithreaded era lo que me jorobaba. Si yo llevaba usando dll ya hacía mucho tiempo (usando .lib al compilar y linkar; y el .exe cliente usando la .dll) pero hasta ahora no me había dado por utilizar STL desde una dll, que por cierto, es una maravilla. Creo que ya he domado a la StlPort (aunque lo mismo vuelvo por aquí con algun nuevo quebradero de cabeza).

Un saludo!

[[Over]]

http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html

[Loover]

[Over], te tengo dicho que no le des al crack bien de mañana. Madre mía, ¡un post del 2003! :D

[[EX3]]

Ya pensaba que era el unico que leia 2003 en vez de 2008 en los replies, no estoy loco :lol:

Salu2...

[Loover]

El caso es que la "solución" fué (y sigue siendo) un: #pragma warning (disable : 4251)

¿Mare mía, tantos años llevo con la LooverLib de los huevos? :S

Jeje.

[Vicente]

Toma ya Over, te has superado :p

[[EX3]]

¿Mare mía, tantos años llevo con la LooverLib de los huevos? :S

No son tantos, yo empece con el mio en el 2001, pues no ha llovido ni nada desde entonces, y Aza creo que anda por ahi tambien con su libreria segun ha comentado en alguna kdd. Se nota que nos lo tomamos con calma esto de programar librerias xD

Salu2...

[Loover]

Es el cuento de nunca acabar. Como hobbie, pues vale, pero si tuvieramos que haber estado 10 años pa hacer la librería y luego el juego, nos podemos pegar un tiro.

A mi lo que más me lleva de cabeza es la documentación. Es un trabajazo tremendo.