Newsgroup: it.comp.lang.c++
Titolo: Multipiattaforma

Salve,
sto creando un programma che utilizza le OpenGL, e deve essere 
multipiattaforma.
Adesso, oltre agli ovvi problemi che si presenteranno (ho la vaga 
impressione che mi vedrete spesso) ho un altro interrogativo: sotto 
windows utilizzerò il sistema di finestre di cui si usufruisce con le 
api standard (CreateWindow & co.).
Queste saranno le prime ad essere utilizzate, ma dovrò sviluppare 
ovviamente l'equivalente parte di codice per Linux, ed allora utilizzerò 
  le QT o le GTK, sarà una scelta successiva.
Ad esempio, se durante il lavoro c'è bisogno di una tipica MessageBox() 
ho bisogno che venga fatta utilizzando la libreria lecita.
Ora, partendo da una classe base generica, es.: 'Gui', potrei scrivere 
tutto il codice che mi serve in due classi ('WinGui' e 'LinuxGui') 
derivate da Gui e ritardare il binding per rilevare il sistema operativo 
su cui sto girando.
Però:
1) Il codice per Linux verrà in un secondo momento.
2) Non vorrei apportare modifiche del codice originario.
Avevo pensato all'aggiunta di una *.dll con la classe che mi serve (es.: 
LinuxGui) in una predefinita directory per far sì che il sistema in fase 
di inizializzazione trovasse le classi aggiunte.
Ora vi starete chiedendo: perchè non sviluppare tutto insieme, 
oltretutto rispetto al progetto globale quello dell'interfaccia è poca 
cosa.
Vero.
A me però questo meccanismo serve per un motivo fondamentale: vorrei che 
sotto linux l'utente potesse scegliere il sistema da utilizzare (GTK 
oppure QT) e SICURAMENTE non verranno sviluppati tutti all'inizio, e 
quindi mi servirebbe che il sistema partisse con quello di default (ad 
esempio QT) e che nel menù dell'applicazione fosse DINAMICAMENTE 
aggiunta la voce "Utilizza GTK" se il sistema si accorge dell'aggiunta 
della dll con il codice contenente la fantomatica classe "GTKGui".
So che sono stato un pò contorto ma come tutte le fasi iniziali di un 
progetto ho l'universo in testa (e sta girando parecchio).
P.s.: credo che sia qualcosa di diverso da una patch o da un plug-in, 
perchè il mio metodo consiste SOLO nella copia di una dll in una 
directory, senza alcuna installazione; ovviamente ( e probabilmente ) 
potrei sbagliarmi.
Grazie per ogni eventuale suggerimento e per la pazienza di leggere un 
post lungo ;)

 Salve,
[megasnip]
Aggiungo a quanto detto prima che potrebbe rendersi necessaria la 
possibilità dell'utilizzo delle DirectX, e qundi anche quelle le 
inserirei tramite una o più classi derivate messe in una dll, cosa che 
sarebbe ovviamente lecita solo per windows, ma tant'è....
Grazie...

   le QT o le GTK, sarà una scelta successiva.
Perchè non fai subito tutto in GTK+? Esistono anche per Win, hanno una
licenza migliore delle QT (sotto Win), ed almeno il codice lo scrivi
una volta sola...
E poi... Perchè fai programmi per Win?? ;-) Ciao!
-- 
Andrea Bergia - studente              Linux Registred User #281550
"The one thing we're all waiting for, is peace on Earth and an end to
war,
it's a miracle we need, the miracle, the miracle, 
Peace on earth and end to war today,
That time will come one day you'll see when we can all be friends"

 E poi... Perchč fai programmi per Win?? ;-) Ciao!
Per esigenze indipendenti dalle mie scelte...e comunque piů cose si 
sanno meglio č ! ;)

 multipiattaforma.
OT, ma dai una seria occhiata a wxWindows:
http://www.wxWindows.org
-- 
   |   \    \  | ___|_  |_  | ianezz a casa sua... :-)
   |  _ \  | \ | _|    /   /  Visita il LinuxTrent a
  _|_/  _\_|  _|____|___|___| 
http://www.linuxtrent.it

 
http://www.wxWindows.org
No, non ci siamo...a me interessa il meccanismo per realizzare il tutto.
Che poi siano finestre o estensioni DX è irrilevante.

 Che poi siano finestre o estensioni DX è irrilevante.
Cosi` su due piedi mi verrebbe da pensare a questo:
1) Un po' di classi astratte che implementano l'interfaccia comune dei 
macro-oggetti della GUI (i.e. una per finestra?), e relative 
implementazioni.
2) Per ogni toolkit, una factory (singleton) degli oggetti di cui sopra. 
Ciascuna factory ovviamente deve deriva da una base comune (virtuale pura).
3) Per ogni toolkit, una specializzazione delle classi del punto (1).
4) Impacchetti (2) e (3) in librerie shared, una per ogni toolkit.
5) Una factory (meta-factory) con un metodo che si piglia un parametro 
(es. il tipo di toolkit da usare, piu` un valore per il default), che 
provvede a istanziare e restituirti la factory che chiedi (solo quelle 
per cui ha senso per la piattaforma per cui stai compilando, quindi con 
compilazione condizionata, ovviamente)
Il codice di istanziazione nella meta-factory per uno specifico toolkit 
e` un po' losco e ovviamente dipendente dalla piattaforma: deve riuscire 
a caricare la libreria shared giusta e ad invocare l'istanziatore della 
factory (forse ti servira` una funzione extern "C" d'appoggio per fare 
questo). Su Linux e simili vedi dlopen(3) e dlsym(3), su Windows non so.
Se non ho sbagliato, il codice generico potrebbe quindi usare la 
meta-factory per avere quando vuole la factory per un certo toolkit in 
grado di creare gli oggetti della tua GUI.
Se hai seguito uno stile MVC stretto (tenendo in (1) effettivamente solo 
le view), non dovresti aver piu` problemi di tanto a cambiare toolkit 
(factory) a runtime.
Se poi ho detto frescacce, me lo dite, eh? :-)
Peraltro rimango dell'opinione che l'uso di un solo toolkit 
cross-piattaforma semplifica il design e permette di concentrarsi meglio 
sui problemi piu` seri (vedi Mozilla, OpenOffice e Audacity come esempi 
di progetti C++ che han scelto questa strada), ma poi ognuno faccia come 
preferisce.



E' sicuramente più 'elegante' e logico utilizzare un tool cros-platform, 
ma pensando al problema mi era sorto il dubbio di come si potesse fare...
Oltretutto, la natura del mio dubbio risiede nel fatto che se io voglio 
utilizzare poi in seguito le DirectX, come posso fare ????
Esempio: ipotizziamo di avere scritto una classe base:
genericAPI
da cui derivo OpenGLAPI che realizza un sistema di rendering utilizzando 
tali liberire; poi un bel giorno mi sveglio, quando il programma è 
finito e funzionante, e scrivo la classe DirectXAPI: se non prevedo un 
sistema di 'immissione' dall'esterno del nuovo codice devo ricompilare....
Era per quello che avevo pensato ad una dll che il sistema deve rilevare 
in fase di inizializzazione.

 multipiattaforma.
Scusa se non ho letto tutto il tuo msg ma e' troppo lungo....
Spero di non dire qualche cosa sensa senso....
Perche' non  sviluppi tutto con SDL?
http://www.libsdl.org/index.php
Tommy

 Tommy
Fa niente non ti preoccupare.
Posso cogliere l'occasione per diventare un pizzico OT ??? Dai dai dai !!!
Allora, molto spesso, alla domanda "Come faccio ad utilizzare DX sotto 
Win e GL sotto linuccio" si ottiene una risposta come la tua, 
assolutamente LOGICA, ma che non tiene d'occhio un *piccolo* 
particolare: DX e OpenGL sono le UNICHE librerie da utilizzare per fare 
qualcosa di 'presentabile'.
Chiarisco perchè già sento brusii.... ;)
Allora, premetto che ho sempre rivolto l'attenzione alla programmazione 
grafica con lo scopo di comprenderne le caratteristiche importanti, 
quelle che non trovi scritte e che non t'insegnano (intendo dire che non 
ho mai messo su qualcosa di completo ma le mie applicazioni grafiche le 
ho scribacchiate, quindi sono venuto a conoscenza di una piccola parte 
di tutte le problematiche che una cosa del genere racchiude in sè); in 
particolare a Marzo mi sono laureato e questo mi ha permesso di 
cominciare a lavorare nel campo.
Utilizzo Maya e qualche suo plug-in, in particolare indirizzo gli sforzi 
verso la simulazione di alcune caratteristiche fisiche ( ad esempio 
frane ), quindi da un punto di vista leggermente distante da quello 
della programmazione, anche se di continuo ritocco la fase di design 
(perchè per ora a quello sto) di quello che vorrei fosse un motore grafico.
Se date uno sguardo ai tool cazzuti ( si può dire tool ? ) come Maya o 
3DS noterete che utilizzano TUTTI le opengl, semplicemente perchè come 
sistema per la RESA QUALITATIVA della scena NON sono ancora state 
superate; altresì notereste che BUONA parte di giochi commercializzati 
utilizzano le DX, che nonostante siano progettate in una maniera un pò 
discutibile, quello che devono fare, e cioè permettere la scrittura di 
MOTORI DI RESA (come li chiamano gli 'addetti ai lavori'), e cioè motori 
grafici altamente performanti, lo fanno meglio di qualunque altra 
libreria a parità di sforzo di programmazione (non che siano semplici, 
mi riferisco alla conoscenza che ne può avere un programmatore che le usa).
E' ovvio che tutti potreste rispondere "Ma Quake 3 Arena" è fatto in OpenGL.
Si, ma sapete chi l'ha fatto ?? E' per quello che ho specificato quanto 
detto sullo sforzo di programmazione.
Con questo voglio dire che la scelta di librerie alternative, come le 
SDL, che comunque sono molto valide, non sempre può essere effettuata, 
bisogna tenere presente ciò che si deve fare e che 'visibilità' gli si 
vuole dare.
Di nuovo scusa per la divagazione, ma ho scritto ciò anche per conoscere 
il vostro parere.
P.s.: anch'io adoro linux (mi sembra che sia importante dirlo - chi vuol 
capire...) ;)
Ciao !