Newsgroup: it.comp.programmare.win32
Titolo: Programmazione Win32

Salve a tutti, scrivo per ottenere qualche suggerimento su come accostarmi 
al mondo della programmazione windows con C++...sinceramente sono 
appassionato di programmazione C e  C++ procedurale, di algoritmi; mi 
interesserebbe affrontare anche questo tipo di programmazione sicuramente 
più complessa.
Ho fatto qualche ricerca in google, ma con scarsi risultati. C'è qualcuno 
che saprebbe consigliare ad un neofita di programmazione win32 con C++ delle 
buone fonti per iniziare a stabilire delle buone basi con questo linguaggio?
In effetti mi è venuta la curiosità perchè una volta mi è capitato di  dare 
un'occhiatina al sorgente di un programma p2p (DC++) che è scritto 
interamente in Visual C++, e da allora vorrei imparare il linguaggio per 
cominciare anche a fare delle modifiche al sorgente, ma per ora è ancora 
arabo....
Ringrazio tutti, Vincent 

 buone fonti per iniziare a stabilire delle buone basi con questo linguaggio?
Sia il C che il C++ standard non forniscono strumenti di programmazione 
grafica.
Devi appoggiarti all'API di Windows o a librerie non standard.
Ci sono decine di librerie per programmare in C o in C++ per Windows, 
alcune proprietarie, come MFC, altre open source.
Per esempio, guarda qui:
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 un'occhiatina al sorgente di un programma p2p 
eMule+ e' scritto in C++ con MFC. ...ma se non hai basi di 
programmazione MFC e' un po' difficile comprenderne i listati :) anche 
perche' li' si usano tecniche avanzate tipo definire controlli custom, etc.
In alternativa ad MFC, esiste una libreria C++ che fa un uso molto 
intenso dei template C++. Si chiama WTL (Windows Template Library). 
Pero', a differenza di MFC, non e' supportata ufficialmente da 
Microsoft. Inoltre, MFC offre anche un vero e proprio framework 
(document-view) e altre caratteristiche che WTL non offre.
Il vantaggio di WTL e' che non devi linkarti a DLL esterne, anche se le 
DLL di MFC sono ormai presenti su ogni PC con Windows :)
Se poi ti interessano librerie multipiattaforma, esistono wxWindows, 
GTK+, QT... pero' questo *non* vuol dire programmare per Windows :) nel 
senso che con quelle librerie ignori del tutto le tecnologie specifiche 
di tale piattaforma (Windows).
Ciao

Grazie mille! Cercherň di seguire i tuoi preziosi consigli!
A presto! 

Il mio consiglio e':
Ottimo consiglio .
Sono perfettamente d'accordo .

 di tale piattaforma (Windows).
E Perche'? Usando wxWindows hai la portabilita' su un mucchio di
piattaforme gratis. Se chiami direttamente le funzioni Win32 perdi
quello che hai avuto gratis, ma nessuno ti impedisce di farlo.
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Angelo Paolitto wrote:
 >
 >> Se poi ti interessano librerie multipiattaforma, esistono wxWindows, 
GTK+, QT... pero' questo *non* vuol dire programmare per Windows :) nel 
senso che con quelle librerie ignori del tutto le tecnologie specifiche 
di tale piattaforma (Windows).
 >
 > E Perche'?
Si possono realizzare applicazioni che girano sotto Windows in tanti 
modi diversi: dal C/C++, al Visual Basic, a Java, a Python, etc.
Programmare la piattaforma Windows vuol dire, secondo me, "parlare" col 
sistema operativo "direttamente", e cio' lo fai in Win32 SDK, cioe' 
parli nativamente con le API di Windows.
La portabilita' ha i suoi vantaggi, nonche' i suoi svantaggi.
Dipende da cio' che devi fare.
Se ti interessa fare un'applicazione con una GUI semplice, con i soliti 
controlli edit-box, list-box, etc. tutto va bene.
Ma se ad esempio vuoi definirti un controllo custom che ti renderizzi 
degli oggetti 3D usando le Direct3D, quello lo puoi fare programmando 
COM, ActiveX, oltre che le DirectX. Nessuna di queste tecnologie e', per 
definizione, multipiattaforma: e' tutta roba Windows. Non credo che 
esistano driver DirectX per Linux :)
Tanto per dirne un'altra, la piattaforma Windows offre una modalita' 
molto spinta per customizzare i list-control, chiamata "custom draw" 
(che non e' l'"owner draw"!). Si puo' accedere a cio' sia con Win32 SDK 
che con MFC.
Ma non credo che con librerie multipiattaforma ci si possa spingere a 
tale livello. Se non altro perche' queste modalita' avanzate di 
programmazione presuppongono la gestione di strutture dati *specifiche* 
della piattaforma Windows.
Una libreria X che si dica multipiattaforma non puo' fornirmi un 
supporto per OLE/ActiveX, altrimenti come ci si comporta con piattaforme 
come GNU/Linux che non supportano tali tecnologie Windows-specific?
Perderebbe la sua caratteristica di essere multipiattaforma.
Inoltre, ogni libreria multipiattaforma, per definizione, sara' piu' 
inefficiente (poco o molto, a seconda dei casi) rispetto alla 
programmazione diretta della piattaforma specifica, perche' una libreria 
multipiattaforma introduce degli "strati" software aggiuntivi, per 
astrarre dalla piattaforma su cui effettivamente l'applicazione gira 
(con conseguente overhead in termini di memoria richiesta e tempi di 
esecuzione).
Ciao
K

 esecuzione).
Bah... Tra MFC e wxWindows sarei proprio curioso di scoprire chi
introduce piu' strati di software...


 introduce piu' strati di software...
Non conosco wxWindows nei dettagli, ma MFC e' stata proprio progettata 
come un sottile strato di software attorno al Win32 SDK, e facilmente 
integrabile col Win32 SDK.
Per MFC si sono fatte scelte che alcuni "accademici" potrebbero anche 
contestare (tipo un certo uso delle macro) proprio per evitare ad 
esempio di aggiungere v-table con puntatori funzioni virtuali inutili a 
diverse classi, aumentando l'overhead.
K

Angelo Paolitto wrote:
 > [CUT]
Comunque beninteso non ho niente contro le librerie multipiattaforma, ma 
  io sinceramente preferisco sfruttare a pieno cio' che una piattaforma 
puo' offrire.
Se poi l'architettura del proprio software e' ben progettata (es.: 
separazione tra business logic e GUI), fare il porting risulta semplice 
ed indolore.
(Nelle classi business logic non userei certo CList o CString di MFC, ma 
std::list o std::string standard del C++!).
Se poi voglio fare delle applicazioni che voglio lanciare comodamente su 
Windows, Linux etc. allora vado su Java che non richiede neanche la 
ricompilazione :)
K

 diverse classi, aumentando l'overhead.
L'unica cosa su cui posso fare un confronto tra i due sono gli handler
degli eventi.
Su wxWindows hanno tutti la struttura
void classe::metodo(oggettoEvento&);
su MFC
il gestore della perdita del focus ha una struttura, quello di erase
un'altra, ecc, ecc...
Decisamente piu' semplice l'approccio wxWindows.


 Decisamente piu' semplice l'approccio wxWindows.
Forse perche' MFC e', appunto, molto aderente al sottostante Win32 SDK, 
e quindi tende a rispettarne la "struttura".
Ciao
K