Newsgroup: it.comp.programmare.win32
Titolo: [Win32 C++ DLL]

Salve,
come da topic ho una problema nel creare una serie di DLL in C++ sotto
Windows ( VC 2003 ).
Lo scenario è il seguente: devo creare un server TCP che possa funzionare
indipendentemente dal SO, e deve funzionare sotto Win e linux.
Allora ho creato una classe base astratta GenericServer che implementa i
metodi virtuali puri che devono essere implementati dalle classe
specializzate UnixServer e WinServer.
Ora, le questioni sono tante :
1. Ho creato la DLL per GenericServer senza problemi, e nel main che uso
per testarla linko anche il file il file stub .lib. in fase di
compilazione tutto OK ma in fase di esecuzione mi dice che non riesce a
trovare il file .dll . 
   Ora mi chiedo ( ipotizzando che sia un problema di path ), ma se linko
il .lib perchè vuole il file .dll ?? 
2. Per creare le DLL per le classi specializzate, che faccio per
'conoscere' la classe base ( oltre ad importare GenericServer.h ) : linko
lo stub file oppure fornisco la DLL ad entrambe le classi specializzate ??
Scusate ma sotto linux con gli .so è stato *ovviamente* tutto più facile...
Grazie,
j0k3r
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Ciao, j0k3r!
Il giorno 11/05/2004 alle ore 11:15 hai scritto:
 j> Allora ho creato una classe base astratta GenericServer che implementa i
 j> metodi virtuali puri che devono essere implementati dalle classe
 j> specializzate UnixServer e WinServer.
Tu sai vero che la gestione dei socket sotto Windows e' praticamente
identica a quella Linux, tranne che per poche semplici eccezioni ?
 j>    Ora mi chiedo ( ipotizzando che sia un problema di path ), ma se
 j> linko il .lib perchè vuole il file .dll ??
Perche' il lib "punta" ad una DLL. Dovevi creare una libreria statica e non
una DLL se volevi linkare tutto staticamente.
 j> 2. Per creare le DLL per le classi specializzate, che faccio per
 j> 'conoscere' la classe base ( oltre ad importare GenericServer.h ) :
 j> linko lo stub file oppure fornisco la DLL ad entrambe le classi
 j> specializzate ??
Ho l'impressione che tu ti stia impantanando clamorosamente. Evita per il
momento il discorso DLL e fai quello che devi fare. Anzi, io ti consiglierei
di realizzare un sorgente unico e andare di #ifdef per compensare le
differenze tra Linux e Windows (non sono tante).
 j> Scusate ma sotto linux con gli .so è stato *ovviamente* tutto più
 j> facile...
L'ovviamente e' molto relativo.
Bye
-- 
There is no ignorance; There is knowledge
http://www.maccasoft.com

 identica a quella Linux, tranne che per poche semplici eccezioni ?
Tipo la socket() che sotto Unix restituisce un file descriptor e sotto
Windows un SOCKET (strano aggeggio che ovviamente non vale -1 in caso
di errore della chiamata)?
A me sembra che i casini cominicino da prima di subito (visto che c'e'
da chiamare anche WSAStartup() prima di socket()) e che per gestire le
semplici eccezioni di fa prima a riscrivere tutto che a gestire gli
#ifdef in un unico file sorgente (ovviamente il tutto _IMHO_).
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Ciao, Angelo!
Il giorno 11/05/2004 alle ore 11:58 hai scritto:
 AP> Tipo la socket() che sotto Unix restituisce un file descriptor e sotto
 AP> Windows un SOCKET
In Linux usi write, in Windows usi send, un #ifdef ti risolve il problema.
 AP> (strano aggeggio che ovviamente non vale -1 in caso di errore della
 AP> chiamata)?
Basta #define INVALID_SOCKET -1 in Linux e puoi usare la stessa sintassi.
 AP> A me sembra che i casini cominicino da prima di subito (visto che c'e'
 AP> da chiamare anche WSAStartup() prima di socket()) e che per gestire le
#ifdef WIN32
WSAStartup(...)
#endif
Problema risolto.
 AP> semplici eccezioni di fa prima a riscrivere tutto che a gestire gli
 AP> #ifdef in un unico file sorgente (ovviamente il tutto _IMHO_).
Ti assicuro che le differenze non sono cosi' abissali e basta un minimo
sforzo per ottenere sorgenti perfettamente compilabili in entrambi gli
ambienti.
Bye
-- 
There is no emotion; There is peace
http://www.maccasoft.com

 
Hai tre soluzioni:
- la classe base è completamente astratta e allora implementi solo 
funzioni virtuali pure e basta il .h
- la classe base fornisce un'implementazione delle funzioni e allora 
la compili in un .lib o in una terza DLL.
Sinceramente non capisco che vantaggio ci sia a usare una DLL in 
questo caso, visto che le due versioni non possono girare 
contemporaneamente (sono per S.O.) diversi e che non ha senso 
compilare una DLL che usa funzioni unix su Windows e viceversa.
E non capisco nemmeno perchè tu debba utilizzare classi derivate 
diverse per i due S.O.
Personalmente implementerei una sola classe e gestirei le differenze 
con degli #ifdef, in modo da lasciare un unico sorgente su cui 
applicare le modifiche e i bugfix.
Se le funzioni di questa classe non sono condivise tra diverse 
applicazioni (e dal tuo messaggio mi pare di capire che sia così), 
non credo valga la pena di realizzare una libreria dinamica.
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 
IMHO lasciare tutto in un unico sorgente con qualche #ifdef e qualche 
#define ti consente di poter aggiungere nuove funzioni e, soprattutto, 
fissare bug senza dover duplicare il codice (e magari "aggiustare" le 
differenze.
Sarei d'accordo con te se si trattasse di funzioni per cui tra win e 
unix non esiste un'API simile (ad esempio la gestione dei thread e dei 
processi, o della GUI), ma per i socket un approccio "mono-codice" ha, 
secondo me, vantaggi notevoli, soprattutto a lungo termine.


 news:c7q5iv$j6t$
1...@news.newsland.it
: 
[ CUT ] 
Allora, 
il problema sorge per una rete neuronica distribuita, implementata da
un'applicazione multipiattaforma: i nodi satellite sono client che mandano
dei dati al server che li elabora per comunicare con un agente simbolico.
Ora, io non so nè server nè client su che tipo di SO girano, nel senso che
devo almeno farli girare su Linux e Win.
Vorrei quindi creare un sistema a plugin ( già fatto con degli shared
object in linux ) , ora però il problema è fare lo stesso in windows.
Per quanto riguarda le direttive del precompilatore le uso già come in
parte avete detto voi per esportare i simboli da utilizzare per la
creazione della DLL in windows.
Non è possibile pensare di dovere ricompilare per nessun tipo di
cambiamento ( l'applicazione è un prototipo ), deve essere possibile
estenderla senza ricompilare. Ecco perchè la classe base virtuale pura e i
plugin che la implementano.
Il problema però è con le DLL di windows.


Ciao, j0k3r!
Il giorno 11/05/2004 alle ore 17:06 hai scritto:
 j> Ora, io non so nè server nè client su che tipo di SO girano, nel senso
 j> che devo almeno farli girare su Linux e Win.
E non e' che ci sia molto altro... (certo c'e' Mac...). A maggior ragione,
essendo multipiattaforma, dovresti cercare di non spargere il codice a
destra e a sinistra. Un sorgente socket.c che implementa tutte le funzioni
socket di cui hai bisogno e' molto piu' facile da mantenere che due o piu'
file a seconda del sistema operativo.
Realizzarlo in Java ? Il non-plus-ultra per applicativi multipiattaforma.
 j> Vorrei quindi creare un sistema a plugin ( già fatto con degli shared
 j> object in linux ) , ora però il problema è fare lo stesso in windows.
Come hai realizzato il sistema in Linux ? Posta pure un pezzo di codice che
chiama un plugin.
 j> Non è possibile pensare di dovere ricompilare per nessun tipo di
 j> cambiamento ( l'applicazione è un prototipo ), deve essere possibile
 j> estenderla senza ricompilare.
Il che e' abbastanza improbabile. Comunque con le DLL non devi ricompilare
tutto il programma ma solo la DLL interessata dai cambiamenti. Solo se cambi
i parametri alle funzioni o ne aggiungi di nuovi devi ricompilare tutto
(anche in Linux sara' cosi', no ?).
 j>  Ecco perchè la classe base virtuale pura e i plugin che la
 j> implementano.
Ripeto: ti vai ad impantanare.
 j> Il problema però è con le DLL di windows.
Le DLL non sono un problema, il problema e' capire che una DLL e un .so di
Linux non sono poi cosi' differenti.


 
Non mi sembra un problema solo di DLL.


 hardware diverse da x86 (perlomeno non quello che gira su Windows).
no? diavolo, qualcuno dovrą spiegare a Windows CE che non esiste
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.2.2. C, C++ and ASM developers
                               and beta testers are welcome!

 
Ok, preposizione mal formulata che non è sfuggita alla 
"bacchettatrice" del ng (anche se ho l'impressione che tu non abbia 
letto bene il resto del messaggio).
Riformulo il mio pensiero, sperando di essere più preciso (ed evitare 
altre bacchettate).
Conosco Windows CE e so che utilizza il PE per architetture diverse 
da x86.
Quello che intendevo dire (e che speravo fosse chiaro nel contesto 
del messaggio) è che _lo stesso_ eseguibile (in formato PE) che gira 
su Windows (inteso come Windows 95/08/ME/NT/2000/XP) potrà girare 
così com'è al massimo su altre architetture hardware compatibili con 
l'x86* e quindi non capivo perchè il nostro amico si facesse problemi 
a dover compilare versioni diverse (linux e win, nel suo caso) del 
programma e delle librerie dinamiche.
Su Windows CE, tra l'altro, era "apparso", nella versione 3.0 un 
formato di eseguibile portabile (CLR mi pare si chiamasse) che è però 
sparito in CE 4.0/.NET.
A meno di non mettere nel PE (sempre sia possibile) tutte le diverse 
versioni... ma, dovendo supportare anche linux, la cosa mi sembra 
inutilmente complicata.
*e non su Windows CE, nemmeno su piattaforma x86.
