Newsgroup: it.comp.programmare.win32
Titolo: Interfacciare un programma c++ in win

Ciao a tutti,
io scivo dei codici che eseguo con un compilatore c++;
vorrei sapere come faccio ad interfacciare graficamente in windows questi
programmi scritti da me.
Grazie a tutti
Ciao
Luca

 ha scritto nel messaggio
news:ptCUc.116890$OR2.6...@news3.tin.it...

Ciao, ora sei nel NG appropriato.
La differenza sostanziale fra un software per Windows ed un programma in
standard C++ (che pur gira sotto Windows ma in una shell di caratteri) non
sta tanto nell'evidente finestra grafica, nei menu e nei controlli (testo,
bottoni, etc.) bensì nel modo in cui il flusso del programma è gestito.
Nel programma standard C++ il flusso delle operazioni segue le tue
indicazioni fedelmente, mentre un programma per Windows ha determinati
momenti (in cui devi compiere operazioni specifiche) ed il resto del flusso
del programma è sostanzialmente guidato da eventi (messaggi fra le varie
componenti software).
Questa è la prima cosa da capire.
Poiché la programmazione Win32 in ambiente GUI è tutt'altro che semplice,
esistono ottimi libri sullo sviluppo uno è ad esempio "Programmare Windows"
di Charles Petzold e numerosi tutorial in rete, anche se meno esaustivi dei
libri di solito.
Un sito dove puoi vedere alcuni, semplici, programmi in Win32 è
http://www.relisoft.com/win32/
 , ma ti renderai conto che è un modo di
programmare piuttosto macchinoso, per quanto efficiente.
Molti programmatori, la maggior parte, preferiscono pagare qualcosa in
termini di efficienza (ma non è sempre così) e affidarsi all'uso di
framework (che sono dei wrapper alle funzioni API Win32).
I più famosi sono per Windows sono MFC (di propietà di Microsoft, sta per
Microsoft Foundation Classes) , VCL & CLX (di Borland, quest'ultimo
multipiattaforma) e sta crescendo bene anche wxWindows (licenza GPL,
multipiattaforma "simile" come costruzione a MFC).
MFC è distribuita con Visual Studio, VCL con il Borland C++ Builder (CLX con
le versioni professional e entrprise se non error) e wxWindows funziona bene
sia con Visual C++, che con il Borland e meglio ancora con il Dev-C++
compiler.
La stesura di codice con questi framework (ma ce ne sono altri) è fortemente
semplificata (e in C++, mentre le API di Windows furono scritte in C e
assembly), soprattutto è semplice con VCL dato che il Borland C++ builder è
effettivamente un ambiente di sviluppo RAID (dove puoi costruire finestre e
controlli con il solo mouse).
La migliore guida per le MFC penso che sia la Microsoft MSDN, per quanto
riguarda VCL bisogna acquistare il Borland e dentro c'è un ottimo help in
linea (che oltre alla VCL tratta anche il C++ standard ed il C) mentre per
wxWindows, il sito di riferimento è 
http://www.wxwindows.org
 .
Quindi, se vuoi sapere come fare per vedere i tuoi programmi sulla GUI, devi
innanzitutto decidere quale strada intendi seguire (tra quelle che ti ho
indicato io ed altre che magari altri t'indicheranno) e poi approfondirla.
Te l'avevo detto che il discorso non era semplice...
Comunque io uso wxWindows e mi trovo benissimo, ho anche il Borland C++
Builder e VCL è veramente comodo (a mio a vviso il modo più semplice per
programmare Windows in C++), però preferisco sempre wxWindows (che mi pare
che anche Borland alla fine abbia sposato).
saluti,
Paolo Ferraresi.

 e meglio ancora con il Dev-C++ compiler.
Ne manca uno molto impoortante, IMHO, ovvero tutte le
windows.form del framework .NET
http://www.windowsforms.net/
-- 
Gerolamo

 Ne manca uno molto impoortante, IMHO, ovvero tutte le
Vero. Io me lo scordo perché non mi piace .net ma è una realtà.
Hai fatto bene a puntualizzare.
ciao.

 Vero. Io me lo scordo perché non mi piace .net ma è una realtà.
Per curiosità, perchè non ti piace?
Io non è che abbia questa grande esperienza con la programmazione
Windows, ma con C# e Sharpdevelop mi sto trovando abbastanza
bene...
-- 
Gerolamo



Posso intervenire ? :-)
Microsoft per .Net ha fatto un notevole lavoro di riordino in ottica OOP
delle proprie API (non è concettualmente corretto ma lo dico per
semplificare, alla base di .Net su Windows ci sono comunque le Win32), io
che lavoro in VB.Net lo trovo comodo e veloce, ma per mia esperienza .Net
soffre di un grandissimo tallone d'Achille: le prestazioni e richiesta di
risorse.
Far girare un programma .Net su una macchina non adeguatamente aggiornata è
un suicidio, io come sviluppatore/sistemista che dai propri clienti vede
ancora macchine con un PII a 233 MHz, 64 MB con Windows 98 penso che questo
sia un grosso problema, tanto da farmi scegliere ancora VB6 (o il C++)
quando il parco macchine del cliente è una incognita.
PS.
Nel tempo libero sto portando avanti lo sviluppo di un minuscolo framework
in C++ che incapsula in ottica OOP i controlli di Windows, sul sito in
firma trovare l'url. Manca quasi completamente di manuale ma con gli esempi
si può comunque utilizzarlo. Richiede l'inclusione di due soli files
(windev.h e windev.cpp) nei vostri progetti.
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) 
despammed.com

 (windev.h e windev.cpp) nei vostri progetti.
Ho visitato il tuo sito, ed è molto interessante: mi piace curiosare nei
siti di altri programmatori, oltrettutto spesso si trovano degli ottimi
programmi, :-) e tra poco svilupperò anche io il mio sitarello.
Ma tornando al tuo framework, non capisco una cosa: perché bisogna
includere anche windev.cpp? Di solito un programma in C++ è strutturato in
maniera tale che tutti gli #include includono solo headers.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 maniera tale che tutti gli #include includono solo headers.
Thx :-)
Dunque devi includere windev.cpp perchè li dentro è sviluppato tutto il
framework, mentre in windev.h ci sono le dichiarazioni delle classi.
Nel caso di un programma composto da diversi file .cpp li metti tutti nel
progetto, crei un unico header che include tutti quelli che sono richiamati
altrove. Il file windev.zip scaricabile dal mio sito dovrebbe essere
esaustivo :-)
Ciao


 altrove.
Io di solito faccio diversamente: ad ogni file .cpp che creo, gli associo
un file .h #includendolo dal .cpp; poi tutti i files (sia cpp sia h) li
includo nel progetto da compilare, in modo tale che vengano schiaffati
tutti al compilatore; il compilatore incomincia a mangiarsi tutti i files,
e genera un file .obj per ogni accoppiata cpp/h, quindi penso che se io
scaricassi il tuo fw e includessi il .h dove voglio, ma lasciassi a se
stante il .cpp, dovrebbe funzionare (ovviamente il .cpp dovrebbe comunque
essere incluso tra i file da compilare).


 risorse.
Infatti!
Se avessero realizzato un bel framework di classi pulito stile .Net, ma 
per C++, secondo me avrebbero fatto un gran cosa!! 
Ciao,
Dan

 per C++, secondo me avrebbero fatto un gran cosa!! 
Sottoscrivo al 200%
Ciao


 essere incluso tra i file da compilare).
Beh prova :-)


 bene...
Che ti trovi bene, ne sono convinto...
Ti hanno risposto altri e hanno detto tutti cose che condivido...
Io programmavo in assembly già nel 1983 (6502) e ho lavorato su (alcuni)
computer che non facevano neanche 100.000 istruzioni al secondo... 20 anni
prima dei primi pentium e ci giravano pure dei gran bei programmi (ricordi
per caso Zilog Z80, 6502, Motorola 68000...68030, poi l'Intel 8086 e il
resto è cosa nota...).
Oggi abbiamo CPU da svariati GIPS.
La morale della favola è che il fatto d'avere computer con svariati GIPS
(per me) non è un buon motivo per scrivere codice poco efficiente (che
magari è il più bel software del mondo, questo è un'altro discorso...).
Ho abbandonato del tutto l'assembly nel 1990 (programmavo su di un Motorola
68030) e sono passato al C perché è un linguaggio efficientissimo e
potentissimo, il C++ è ancora più potente e rimane ancora molto efficiente
(conoscendolo bene) e per questo oggi il 99% di quello che realizzo è in C++
ed è in assoluto il mio linguaggio preferito.
Per questo motivo non mi piace: non sopporto un framework così pesante (sono
piuttosto per spendere qualcosa in più e chiamare le API di Windows, oppure,
al massimo usare altri framework "leggeri").
Ciao.
Paolo.

 con MFC, senza tutte quelle macro :-) 
Perchè esistono già le MFC anche se non piacciono, e se proprio non 
piacciono si può dare un occhiata alle terze parti, un set di classi non 
è un problema su cui fossilizzarsi. Come non c'è ragione di 
fossilizzarsi nel cercare l'eleganza OOP "formale" e a tutti i costi, le 
macro delle MFC hanno un loro senso di esistere.

 "scopiazzando" alcune cose carine del .Net
La risposta è semplice: lo hanno fatto :-)
È ancora in alpha e si chiama WinFX e sarà il nuovo subsytem di Longhorn, il
prossimo client (e poi server) Windows.
WinFX ha una tonnellata di nuove classi che non si basano più sulle Win32
che vengono abbandonate (conservate per compatibilità ma non più
progredite).
WinFX sarà accessibile solo dal mondo managed.
Lo schema delle nuove classi di WinFX si possono assaggiare in anteprima
qui:
http://longhorn.msdn.microsoft.com/
Ovviamente è una alpha quindi passibile di notevoli mutamenti così come è
già accaduto per Indigo da Ottobre scorso ad oggi.
Lo stesso C++ così come lo conosciamo ora verrà adeguato a supportare quelle
feature che non erano richieste quando era stato progettato. Il nuovo
C++/CLI (candidato ad essere standardizzato ISO) semplificherà notevolmente
l'attuale C++ managed extension (che verrà dismesso e potrà essere migrato
con un tool) ed ha la 'benedizione' di personaggi come Sutter e Slippman
(che lavorano anche in Microsoft) e dello stesso Stroustrup che, a detta di
Sutter (responsabile della commissione ISO di C++), è uno dei principali
supporter del nuovo standard C++/CLI.
In fondo al sistema operativo, a livello kernel, almeno per il momento le
cose rimangono molto simili a prima. Siamo in diversi a scommettere che ne
vedremo delle belle anche in kernel mode in futuro. D'altra parte Longhorn è
solo l'inizio ...
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://www.ugidotnet.org/2082.blog

 alcuni tipi di applicazioni lo richiedono a gran voce.
Che l'evoluzione di COM abbia portato ad una serie di problemi (quello che
viene definito "dll hell") è sotto gli occhi di tutti, ma è anche vero che
con un po' di sforzo in più tali problemi si possono/potevano evitare (i
miei programmi in VB6 girano dovunque e non sono mai stati incasinati da
problemi di dll e ocx).
La necessità di tempi rapidi di sviluppo è stata una esigenza per la quale
è stato sacrificato tutto il resto. 
Secondo me il framework .Net ha una grandissima validità per il mondo web,
ma per le applicazioni windows form non vedo questa grande rivoluzione.
Anche ciò che viene fatto da 
ado.net
 si poteva fare (e io lo faccio in C++
e Win32) con odbc,rdo e ado senza troppi problemi.


 progredite).
Si lo sapevo, e la cosa in tutta onestà mi terrorizza.
Già con il passaggio dalle varie versioni di Windows (basate sempre su
Win32) abbiamo avuto i nostri bei problemi a far girare applicazioni che su
una versione precedente andavano bene e su quella nuova invece no,
figuriamoci su un sistema che è basato su un subsystem graphico nuovo e che
è "compatibile" con le Win32...
Io purtroppo sono molto (troppo) pragmatico: .Net mi piace, Longhorn mi
piacerà (probabilmente) ancora di più, ma la scelta di quale ambiente di
sviluppo usare sarà sempre basata sulla velocità di diffusione di questi
nuovi sistemi/ambienti presso gli utenti finali (attualmente, almeno per i
miei clienti, molto bassa).


 (attualmente, almeno per i miei clienti, molto bassa).
La mia opinione è diversa perchè la transizione sarà più appetibile e credo
che gli utenti lo vorranno fortemente.
La transizione Win16->Win32 è stata invisibile per molti utenti perchè a
tutti gli effetti le differenze sono nulle agli occhi dell'utente inesperto.
Non sarà così per Longhorn dove le applicazioni basate su Avalon attireranno
molto gli utenti finali, anche se di ufficio, perchè la UI è quella che
vende. Chi lo proverà dovrebbe rimanere abbagliato anche da WinFS che
elimina il concetto di file e folder, concetto che agli utenti nuovi non è
mai stato familiare e immediato. Ma credo che prima di sollevare discussioni
inutili su questo faremo meglio a provare una alpha o beta release tra
qualche tempo.
Ciao


 linguaggio preferito.
Anche per me il C++ è un ottimo linguaggio (pur se troppo complesso)
e probabilmente quello che conosco meglio.
Ma la mia preferenza è data dall'espressività, dalla libertà di scelta
del paradigma di programmazione, dalla quantità di implementazioni,
e da altri fattori di gusto che comunque vengono prima della pura
efficienza (che per altro ina alcuni ambiti è fondamentale assieme
al più stretto determinismo temporale, ma questi sono altri discorsi...)
Comunque grazie per lo scambio di opinioni
ciaociao
-- 
Gerolamo

In data Fri, 20 Aug 2004 10:13:30 +0200, Raffaele Rialdi ha scritto:
[cut]
Grazie delle info, molti dettagli li ignoravo :-)


> Grazie delle info, molti dettagli li ignoravo :-)
Prego :-)


 ciaociao
Ciao e buon lavoro!
Grazie anche a te per questi scambi di opinione, per me sono importanti e mi
fa piacere.
ri-ciao.

 Spero di averti chiarito la mia personale opinione.
Si
E in realtà sono fondamentalmente d'accordo con te.
Poi, come dici tu, è questione di gusti.
ciaociao!
p.s.
prima o poi troverò il tempo di provare serialmente wxWindows...
p.s.
...e di usare il Python per lavoro. Ma questo non c'entra. :-)
-- 
Gerolamo

 al di sotto. 
Infatti!!

 ma per le applicazioni windows form non vedo questa grande rivoluzione.
Premetto che in .Net non ho ancora fatto nulla di serio, penso che 
nemmeno farò nulla di cui non tragga diretto vantaggio dal programmare 
in ambiente managed (più o meno lo stesso ragionamento che faccio con 
java).

 Quello che non mi è chiaro è cosa c'entra .Net in questo discorso. 
Microsoft ha realizzato una stupenda reimplementazione delle Win32 in
ottica OOP con il framework .Net, fornendo nello stesso tempo un ottimo
ambiente di sviluppo (pesante come pochi però) peccato che questo lavoro
sia destinato ad un uso "managed", con tutti i difetti elencati in altri
post. 
Se il framework .Net fosse stato realizzato in modo tale da poter generare
exe puri, senza una macchina virtuale in mezzo (che da sola quando parte si
ciuccia una decina di mega), sarei stato un entusiasta.


 consigliare un occhiata a librerie di terze parti anche free.
Dotnet a parte, in C++ unmanaged è da diversi anni che uso WTL (di
Microsoft) e mi sono sempre trovato benissimo.
WTL non è supportato ufficialmente da Microsoft ma esiste una vasta
community che la supporta e Microsoft stessa non nasconde (ufficiosamente)
di voler continuare ad evolvere i propri tool in modo che WTL continui a
poter essere usata.
http://sourceforge.net/projects/wtl
Oggi ritengo che non abbia più senso viste la disponibilità di dotnet.


 Oggi ritengo che non abbia più senso viste la disponibilità di dotnet.
Mah, non sono d'accordo. Per me l'ideale sarebbe se Microsoft facesse 
una bella implementazione delle classi .NET pulita in C++ nativo 
(wrappando le Win32), e per C++ nativo (senza roba "managed").
...anche se mi pare di capire che non se ne parla, dato che loro stanno 
investendo molto su C# e .NET.
:(
Ciao
Dan

 :(
Stanno investendo prima di tutto su .NET ma non solo C# ... non
dimentichiamo C++.
Le comunità di sviluppatori non hanno mai digerito (giustamente, anche io le
detesto) le managed extension di C++ e per questo sta per uscire con il fw
2.0 il nuovo linguaggio C++/CLI:
- espande il linguaggio C++ e sarà standardizzato ISO
- usa indifferentemente la parte managed e unmanaged in modo trasparente
- ha la benedizione di Stroustrup e in Microsoft ci lavora gente come Herb
Sutter (responsabile della ISO committee dell ISO C++), Stan Lippman (non ha
bisogno di presentazioni) e Brandon Bray.
- avrà template *e* generics
- avrà allocatori di memoria classici *e* managed
- avrà l'implementazione *automatica* del pattern dispose
... e tante altre belle cose...


 Win32 sono molto datate e soffrono di molte scollature 
E' vero...

 H<qualcosa> :-) e struct con dwSize :)
Tranquillo, continueremo a vederle ancora per molto, prima che Longhorn
sostituisca il parco macchina esistente...:-)


 sostituisca il parco macchina esistente...:-)
:-))
...in effetti, poi alla fine conta l'hardware installato (che fa da 
vincolo per il software che puo' girarci su!)
Dan

 vincolo per il software che puo' girarci su!)
Beh l'attuale alfa di Longhorn č un po' pesantina ma tutta la grafica 3d č
gratis visto tutte le attuali schede grafiche hanno gli acceleratori ma
nessuno (giochi a parte) li usa.
E poi parliamo di un OS che girerą su PC del 2006/2007  ;-)


 E poi parliamo di un OS che girerà su PC del 2006/2007  ;-)
Correzione, avremo WinFx anche per su XP e W2K3:
http://www.microsoft.com/presspass/press/2004/Aug04/08-27Target2006PR.asp
... e questo servirà a scalzare Win32 più velocemente ...


 - espande il linguaggio C++ e sarà standardizzato ISO
[...]
ma soprattutto: sarà nel prossimo framework Visual C++ gratuito? se sì, 
quando? senno', sarà tanto bellino, ma io non compro Visual Studio solo 
per _un_ compilatore
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.2.4. C, C++ and ASM developers
                               and beta testers are welcome!

 Studio solo per _un_ compilatore
Da un po' di tempo il compilatore C++ è gratuito con il famoso kit:
http://msdn.microsoft.com/visualc/vctoolkit2003/
A meno di colpi di scena, che personalmente ritengo estremamente
improbabili, lo sarà anche la prossima versione che includerà il nuovo
C++/CLI.
Inoltre sono già state annunciate le versioni Express di tutti i prodotti
visuali, quindi con un vero ambiente di sviluppo che puoi già provare in
beta:
http://lab.msdn.microsoft.com/express/visualc/default.aspx
Queste versioni sono orientate allo sviluppo amatoriale/studentesco e quindi
ad un costo veramente esiguo (adesso è in beta e quindi non si sa ancora di
preciso).
Per quanto riguarda Vs.net dipende da quello che ci vuoi fare. Se sviluppi
per professione ti assicuro che serve tutto quanto.
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele

 Se sviluppi per professione ti assicuro che serve tutto quanto.
fidati che non mi serve. Sarebbe molto bello se, ma non mi serve


 c'č quello vero. E l'ambiente non mi serve
Carina quella del farlocco, io uso 
vs.net
 e quindi non saprei.
Che cosa ci sarebbe di farlocco nel compilatore del kit?


 Che cosa ci sarebbe di farlocco nel compilatore del kit?
Il compilatore farlocco ("Standard Compiler") è quello che non supporta 
/O e famiglia


 supporta /O e famiglia
Ripeto che non l'ho mai provato, ma a questo link (nelle Q&A) viene detto
che i compilatori sono identici:
http://msdn.microsoft.com/visualc/vctoolkit2003/
Possibile che tu abbia provato un kit molto più vecchio?
