Newsgroup: it.comp.programmare.win32
Titolo: Calling convention e dll c++

Hi all
mi sto scontrando con un problema che mi risulta bloccante e purtroppo
sinora non sono riuscito ad uscirne. Un aiuto qualsiasi mi sarebbe veramente
prezioso.
Background del problema:
sviluppo di un sistema a plugin in c++; i plugin sono delle dll in c++ con
delle caratteristiche particolari.
Sviluppo su winxp con compilatori microsoft 7.1 (2003) e gcc 3.4.
L'idea é che i plugin possano essere prodotti con qualsiasi compilatore.
Problema:
Al momento di provare l'interazione fra il main program (visual studio) e il
plugin (gcc) ottengo degli errori a runtime che ho ipotizzato possano dipendere
dalla calling convention. Con errore a runtime intendo un accesso ad
indirizzi non validi, rilevato dal debugger. Il problema comunque non é
legato alla presenza o meno dei simboli di debug.
Le funzioni esportate dai plugin hanno c.c. __stdcall, vengono correttamente
esportate e mappate, tant'é che usando lo stesso compilatore per main e
plugin non c'é alcun problema.
Semplificando:
plugin.cpp
void __stdcall funzioneX (std::string& x)
{
	x = "abcde"
}
main.cpp
int main (int argc, char* argv[])
{
	...Linko la libreria e mappo il simbolo funzioneX, tutto ok...
	void (__stdcall *fx)(std::string&);
	std::string s;
	fx(s);
	...A questo punto salta fuori il runtime error di cui sopra...
}
Se qualcuno volesse propormi una spiegazione gli sarei veramente grato. In
fin dei conti non può essere un problema così grosso, no? :-)
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! I Never Wanted To Be What They Told Me To Be
	Fulfill My Fate Then I'll Be Free >!- Blind Guardian - Mordred's Song

usi dei .lib per compilare ? in genere i .lib di Visual Studio nn sono 
utilizzabili con gcc e viceversa da quanto ricordo. Un po di info le 
trovi sul sito di Mingw
Giuseppe Corbelli ha scritto:



Scusa, c'e' qualcosa che mi sfugge, ed e' la dichiarazione void (__stdcall
*fx)(std::string&); che dichiara un puntatore a funzione con return value
void. e che non mi pare essere inizializzato....
il richiamo della funzione FunzioneX e' altra cosa...
Sko

 trovi sul sito di Mingw
No, niente import library, mi sono dimenticato di specificarlo.
Uso linkaggio dinamico esplicito (LoadLibrary + GetProcAddress).
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
-<! Gesu' e' morto per i nostri peccati.  Non rendiamo inutile il suo
		martirio non commettendone !>-

 void. e che non mi pare essere inizializzato....
Sono stato troppo criptico :-)
Non ho postato il codice completo, ma il puntatore a funzione é
correttamente inizializzato con l'indirizzo del simbolo mappato da una
libreria con GetProcAddress.
In sostanza: il problema non é il link dinamico esplicito della libreria, né
della funzione, ma proprio la chiamata della funzione in sè.
Da prove fatte oggi pomeriggio ho "empiricamente" scoperto che i problemi
saltano fuori con degli oggetti STL, non con i tipi C. Al che forse il
problema é dovuto a diverse STL usate dai diversi compilatori...
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 


L'idea é che i plugin possano essere prodotti con qualsiasi compilatore.
Se vuoi che il tuo codice sfugga al "name mangling", che ogni
compilatore C++ applica in modo del tutto indipendente (leggi
"incompatibile") dagli altri compilatori, usa: 
extern "C" {
... // il tuo codice va qui...
}
I tuoi nomi non verranno decorati.

Giuseppe Corbelli ha scritto:

Se n'e' gia' parlato, non ricordo se in questo N.G., ma il problema e'
la gestione di memoria che non puo' essere fatta in due moduli diversi.
Usando la string, ogni sua modifica puo' risolversi in una
deallocazione e riallocazione di memoria. Se la inizializzi in un
modulo non puoi farla lavorare in un altro (probabilmente potrebbe
funzionare se fosse costante).
Se vuoi continuare ad usare le string (o qualunque cosa che utilizzi la
memoria dinamica) dovresti riuscire ad usare, in tutti i moduli, lo
stesso runtime del C non linkato staticamente. Oppure fornire, tramite
il programma base un allocatore di memoria.
Ciao

 "incompatibile") dagli altri compilatori, usa: 
...
Ok. Però il punto non era questo :-)
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
           -<! GOD is real, unless declared as integer !>-

 il programma base un allocatore di memoria.
Good. Per il runtime C penso che non ci siano speranze, ma l'allocatore é
una strada percorribile.
Grazie mille!
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**


Ok. Perň il punto non era questo :-)
Il punto č *anche* quello.

On Sat, 25 Feb 2006 18:56:26 +0100, Andrea Laforgia 
was talkin'about:
#define IMHO

Naturalmente. Forse non mi sono spiegato bene, ma il mio problema non sta nel
linkaggio; in particolare la risoluzione dei simboli va bene.
A quanto pare non sta nemmeno nella calling convention come avevo
ipotizzato, ma piuttosto nei diversi allocatori usati dalle diverse STL 
che ho provato.
Tant'é che pare che usando stlport il tutto funzioni. Sto valutando se
prendere la scorciatoia e richiedere l'uso di stlport oppure se fornire un
allocatore unico per gli oggetti che vado a condividere.
Al momento propendo per stlport, ma si accettano suggerimenti!
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
        **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
 [cowo@braveheart cowo]$ make sex
    make: *** No rule to make target 'sex'.  Stop.