[C++] Programmi con finestre, le uniche soluzioni sono API o Frameworks?

[EnergyVortex]

Ciao a tutti, premetto che non so perchè ma non mi funziona la ricerca del forum.
Sto studiando il C++ all'università e sono arrivato a creare qualche programmino con una qualche utilità.
Ho letto sul testo grazie al quale cerco di approfondire le mie conoscenze (il Deitel) che il C++ è un linguaggio orientato agli oggetti molto potente ed anche cercando su google ho trovato parecchie persone che ne parlano bene.
Il punto è che le informazioni che ho trovato sono molto vecchie (anni) e vorrei avere un vostro giudizio su questo linguaggio e vorrei sapere se effettivamente con il C++ è consigliabile programmare o se oggigiorno si usa altro.
In particolare vorrei sapere come fare per creare dei programmi con delle finsetre in windows: su google ho letto che si usano le API o i Framework, sono le uniche due soluzioni o posso risolvere utilizzando visual studio 2008?
Grazie a tutti in anticipo

[wingman87]

Usando VisualStudio 2008 useresti il framework .NET se non vado errato quindi saresti a posto.
Non mi esprimo sul C++ in quanto l'ho studiato da poco e ancora non ci ho scritto nulla.

[EnergyVortex]

Ma le utilizzerei in modo automatico? Cioè senza capire quello che effetivamente sto facendo o devo studiarmi prima per bene i framework?
Poi leggevo in rete ed ho letto che alcuni utilizzano il delphi per programmare e lo trovano davvero molto semplice ed efficace , altri invece lo trovano troppo semplice perchè è un derivato del BASIC.
Grazie per la risposta

[fero86]

Originariamente inviato da EnergyVortex

Ho letto sul testo grazie al quale cerco di approfondire le mie conoscenze (il Deitel) che il C++ è un linguaggio orientato agli oggetti molto potente

si fa per dire. il C++ é un linguaggio multiparadigma: procedurale, a oggetti e, nell'ultima versione, anche funzionale; ma dal momento che il programmatore ha appunto il potere di mischiare tutti e tre i paradigmi é difficile che a codice ultimato si possa dire ad una prima occhiata: "aaah, che bel programma orientato agli oggetti!!"

Il punto è che le informazioni che ho trovato sono molto vecchie (anni) e vorrei avere un vostro giudizio su questo linguaggio e vorrei sapere se effettivamente con il C++ è consigliabile programmare o se oggigiorno si usa altro.

devi superare quest'ottica; quella giusta é: the right tool for the right job. ad ogni linguaggio di programmazione, cosi come a qualunque altro strumento di lavoro, si addicono un insieme di lavori. in due parole: dipende da quello che devi fare, e questa é una frase che si legge molto spesso su questo e altri forum.

il C++ in genere é un'ottima scelta quando il software che devi realizzare deve fare uso massiccio di API, ma naturalmente possono esserci anche altri contesti.

In particolare vorrei sapere come fare per creare dei programmi con delle finsetre in windows: su google ho letto che si usano le API o i Framework, sono le uniche due soluzioni o posso risolvere utilizzando visual studio 2008?

non é che Visual Studio magicamente ti fa fare i programmi con le finestre: se in Visual Studio crei un programma con la GUI é perché direttamente o indirettamente hai usato le API o qualche framework. non confondere peró il termine "framework" generico col "Framework .NET": in C++ non puoi creare codice IL per .NET; ci sta semmai C++/CLI ma é un linguaggio che, oserei dire, non c'entra nulla.

tornando al termine "framework" generico, ne esistono diversi e comunque tutti non fanno altro che implementare una logica di alto livello e facile da usare che si basa sulle API; io questi framework preferisco chiamarli "librerie" o "toolkit" grafici. con Visual Studio vengono fornite due librerie, MFC e ATL; di norma si usa la prima, la seconda é orientata allo sviluppo COM/OLE/ActiveX. inoltre all'interno di Microsoft é stata sviluppata una'altra libreria, non ufficiale, che si chiama WTL, si basa su ATL e mira ad essere un'alternativa lightweight ad MFC. WTL non viene fornita col Windows SDK, si scarica a parte dal sito suo e richiede ATL.

oltre a queste librerie esistono anche toolkit non Microsoft che tipicamente oltre a permetterti di sviluppare applicazioni grafiche per Windows ti permettono di farlo anche per altri sistemi, come Linux, scrivendo un solo codice portabile e generalmente senza compilazioni condizionali. uno di questi toolkit é wxWidgets, opensource. un altro é GTK+. un altro ancora che sta andando molto é Qt di Trolltech. se vuoi puntare sul FOSS scegli wxWidgets perché GTK+ é scritto in C e quindi ti fará venire mal di testa o poco piu.

per quanto riguarda invece le API: la stragrande maggioranza delle volte dovrai evitarle: sono di livello basso e per di piu quelle di Windows tengono molto alla compatibilitá col C, che significa che sono pallose da usare (devi sempre stare a riempire strutture, controllare valori di ritorno e gestire errori, per il minimo risultato devi scrivere dozzine di righe di codice); é proprio per semplificare l'uso delle API che nascono librerie come MFC, ATL e WTL; se devi programmare solo per Windows usa quelle, altrimenti usa wxWidgets o Qt.

[fero86]

Originariamente inviato da EnergyVortex

Poi leggevo in rete ed ho letto che alcuni utilizzano il delphi per programmare e lo trovano davvero molto semplice ed efficace , altri invece lo trovano troppo semplice perchè è un derivato del BASIC.

FALSISSIMO, Delphi usa un linguaggio che si chiama Object Pascal e che é un derivato del Pascal (ma va?), non del BASIC; e che non mi si venga a dire che il Pascal é un derivato del BASIC perché non c'entra veramente una sega.

comunque non vedo perché aggiungere altra carne al fuoco: l'Object Pascal di Delphi é un linguaggio che si colloca ad un livello molto simile al C++ (termine "livello" inteso come nelle espressioni "basso livello" e "alto livello"), in piu i vari wizard rendono Visual Studio comodo praticamente quanto Delphi. se hai cominciato a studiare C++ prosegui con quello e le applicazioni grafiche per Windows creale in Visual Studio; come vantaggi avrai che conoscerai un linguaggio molto piu usato dell'Object Pascal e userai software Microsoft e quindi presumibilmente integrato meglio col sistema sottostante.

[Torav]

Io darei un'occhiata anche alle QT. Sono scritte in c++, sono portabili e hanno un ottimo editor (QTDesigner)

[fero86]

Originariamente inviato da fero86

un altro ancora che sta andando molto é Qt di Trolltech.

Originariamente inviato da Torav

Io darei un'occhiata anche alle QT. Sono scritte in c++, sono portabili e hanno un ottimo editor (QTDesigner)

appunto, vedi?
il caro Torav avrá scorso a malapena e rapidamente la tua richiesta e il mio ultimo post e non ha proferito ne' A ne' B, subito dritto a Qt. Qt sta andando molto

[Torav]

Originariamente inviato da fero86

appunto, vedi?
il caro Torav avrá scorso a malapena e rapidamente la tua richiesta e il mio ultimo post e non ha proferito ne' A ne' B, subito dritto a Qt. Qt sta andando molto

DOH! Ammetto il mio errore ma chiedo alla corte di considerare l'ora a cui ho risposto
Il fatto è che le sto cominciando ad usare anche io (anche se con python) ma confesso la mia colpa di non aver letto a fondo le risposte

[cionci]

Originariamente inviato da fero86

se vuoi puntare sul FOSS scegli wxWidgets perché GTK+ é scritto in C e quindi ti fará venire mal di testa o poco piu.

Molto meglio le Qt delle wxWidgets. Hanno una migliore documentazione, miglior supporto (sono di Nokia) e molti, ma molti meno bug.

Secondo me su Windows per C++ ci sono solo due strade:
- C++ managed e .Net
- C++ normale e Qt

Le altre strade, cioè WTL ed MFC, imho sono sconsigliabili.
Le MFC sono obsolete (lo erano 10 anni fa) e sono troppo legate alle API di Windows. Molti dei metodi delle classi MFC non sono altro che adattamenti uno ad uno delle API. Inoltre devi comunque gestirti i messaggi che rendono di una complessità assurda anche semplicemente cambiare lo sfondo di una label.
WTL sono più semplici delle MFC e meno verboso, ma anche qui c'è sempre da fare la gestione dei messaggi (anche se in minor quantità rispetto alle MFC) e da usare decine di macro. Inoltre le WTL sono un framework molto limitato, infatti coprono solamente la parte della GUI. Cosa che ti obbligherà a ricorrere alle API anche per le cose più semplici.

C++ managed è il C++ per la piattaforma .Net. I vantaggi di usare la piattaforma .Net sono tanti. A partire da una maggior produttività e da una minore verbosità rispetto a WTL e MFC. Certo bisogna ricorrere a compromessi perché il C++ managed è un C++ un po' stravolto.

Le Qt sono, secondo me, il migliore framework per C++ unmanaged su Windows. Il SDK include l'ottimo IDE QtCreator che ti permette di sviluppare in modo visuale la GUI. Il sistema slot-signal è lineare e semplice da implementare. L'IDE permette inoltre di nascondere il passaggio di precompilazione fatto per il framework, uno dei dettagli delle Qt che potevano dare fastidio un tempo.
Ti assicuro che la produttività è comparabile a quella di .Net, al contrario di MFC e WTL. Ti meraviglierai di quante cose si possono fare scrivendo una semplice riga di codice o, addirittura, senza nemmeno scriverne una
Il framework non è limitato come quello di WTL, infatti si possono gestire molti aspetti non legati alla GUI direttamente con le Qt.

[Teo@Unix]

Originariamente inviato da cionci

Molto meglio le Qt delle wxWidgets. Hanno una migliore documentazione, miglior supporto (sono di Nokia) e molti, ma molti meno bug.

Confermo.
Dopo solo un mese dal primo avvio di Qt creator sono riuscito a realizzare alcune GUI funzionali.

[EnergyVortex]

Inizio ringraziandovi tutti per le risposte davvero ben documentate.
ieri avevo scaricato Wx-DevC++ , ora proverò Qt creator e vi farò sapere.
Se avete qualche link a qualche tutorial o guida per quest'ultimo mi fate un gran piacere!
Grazie ancora!

[cionci]

Originariamente inviato da EnergyVortex

ieri avevo scaricato Wx-DevC++

Cestina subito senza se e senza ma Quell'ide fa pena.

Per il libro:
http://www.qtrac.eu/C++-GUI-Programm...t-4-1st-ed.zip
Non è aggiornato alle ultime release di Qt e non tiene conto del lavoro svolto da QtCreator, ma è gratuito.

[fero86]

Originariamente inviato da cionci

Secondo me su Windows per C++ ci sono solo due strade:
- C++ managed e .Net
- C++ normale e Qt

in tal caso lascia solo la seconda perché non so tu ma io il Managed C++ non lo considero C++, mi sembra veramente troppo diverso. comunque non sono molto d'accordo sul discorso di Qt (vedi sotto).

Le MFC sono obsolete (lo erano 10 anni fa)

io osserverei che sono ancora sotto sviluppo: adesso che é uscito Windows 7 hanno messo le classi per usare il ribbon. le MFC sono ancora vive e la cosa non si puó ignorare secondo me. e comunque via, possono ancora essere utili (vedi il seguito).

e sono troppo legate alle API di Windows. Molti dei metodi delle classi MFC non sono altro che adattamenti uno ad uno delle API.

risaputo, infatti io MFC le consiglio solamente se si é estremamente sicuri che il proprio programma non dovrá mai essere portato su altri sistemi. per quanto riguarda il legame stretto che MFC ha con le API, non vedo che problema ci sia: di certo é un pregio in termini di performance che un metodo sia implementato inline come semplice chiamata ad una API, e i metodi di MFC io non li trovo difficili da usare perché comunque eliminano le noie dell'uso delle API (vedi ad esempio la gestione delle stringhe: in Win32 si alloca tutto a mano, in MFC fanno tutto le varie CString) lasciando solo il divertimento. e poi sono object-oriented: laddove una API ha ad es. il parametro HWND per idetificare la finestra su cui opera, il corrispondente metodo MFC usa this.

WTL sono più semplici delle MFC e meno verboso, ma anche qui c'è sempre da fare la gestione dei messaggi (anche se in minor quantità rispetto alle MFC) e da usare decine di macro.

WTL non le ho mai usate, ma un giorno o l'altro qualcuno mi dovrá spiegare quale cavolo é il problema nell'uso delle macro

Inoltre le WTL sono un framework molto limitato, infatti coprono solamente la parte della GUI. Cosa che ti obbligherà a ricorrere alle API anche per le cose più semplici.

per forza, il resto é implementato da ATL. non devi ricorrere alle API, devi ricorrere ad ATL.

Le Qt sono, secondo me, il migliore framework per C++ unmanaged su Windows.

ricorda comunque che é una dipendenza, perc ui te lo devi portare appresso. per fare le cose semplici (e per diminuire la dimensione di deployment) sarebbe meglio affidarsi esclusivamente al software giá incluso con Windows, quindi MFC, ATL e il runtime C/C++ di Visual Studio.

Ti meraviglierai di quante cose si possono fare scrivendo una semplice riga di codice o, addirittura, senza nemmeno scriverne una

se é per questo fin dalla versione 6 di Visual C++ (non so le precedenti) potevi programmare WordPad solo a forza di wizard, veramente senza scrivere una riga di codice

Originariamente inviato da Teo@Unix

Confermo.
Dopo solo un mese dal primo avvio di Qt creator sono riuscito a realizzare alcune GUI funzionali.

guarda, non so per te ma per me un mese é un'eternitá
uno dei miei primi programmi scritti in C# era una utility per tenere traccia dei miei esami universitari; la GUI l'ho creata con Windows Forms e ci ho messo mezza giornata senza mai aver usato Windows Forms.

con MFC e i wizard di Visual Studio non sarei arrivato a questi livelli, magari avrei dovuto smanazzarci tre giornate anziché una, ma di certo non un mese...

[cionci]

Originariamente inviato da fero86

io osserverei che sono ancora sotto sviluppo: adesso che é uscito Windows 7 hanno messo le classi per usare il ribbon. le MFC sono ancora vive e la cosa non si puó ignorare secondo me. e comunque via, possono ancora essere utili (vedi il seguito).

Non per questo significa che la loro struttura non sia vecchia.

Originariamente inviato da fero86

risaputo, infatti io MFC le consiglio solamente se si é estremamente sicuri che il proprio programma non dovrá mai essere portato su altri sistemi. per quanto riguarda il legame stretto che MFC ha con le API, non vedo che problema ci sia: di certo é un pregio in termini di performance che un metodo sia implementato inline come semplice chiamata ad una API, e i metodi di MFC io non li trovo difficili da usare perché comunque eliminano le noie dell'uso delle API (vedi ad esempio la gestione delle stringhe: in Win32 si alloca tutto a mano, in MFC fanno tutto le varie CString) lasciando solo il divertimento. e poi sono object-oriented: laddove una API ha ad es. il parametro HWND per idetificare la finestra su cui opera, il corrispondente metodo MFC usa this.

Non è questione di portabilità. Semplicemente le API sono troppo di basso livello. Qualsiasi cosa avanzata da fare in MFC è un autentico PATIMENTO, arrivando ad un livello tale per cui il rapporto fra chiamata API e chiamata MFC è 1 a 1. Che senso ha una cosa del genere ? Pensa solo alla gestione dei DC e dei pennelli. Roba davvero assurda.

Originariamente inviato da fero86

ricorda comunque che é una dipendenza, perc ui te lo devi portare appresso. per fare le cose semplici (e per diminuire la dimensione di deployment) sarebbe meglio affidarsi esclusivamente al software giá incluso con Windows, quindi MFC, ATL e il runtime C/C++ di Visual Studio.

Hai problemi di spazio su disco ? Per 7-10 MB in più ?

Originariamente inviato da fero86

se é per questo fin dalla versione 6 di Visual C++ (non so le precedenti) potevi programmare WordPad solo a forza di wizard, veramente senza scrivere una riga di codice

Sì, il wordpad...e basta. Qualsiasi altra cosa, anche semplicemente cambiare il colore di sfondo di un controllo, è un macello.

[tomminno]

Originariamente inviato da fero86

io osserverei che sono ancora sotto sviluppo: adesso che é uscito Windows 7 hanno messo le classi per usare il ribbon. le MFC sono ancora vive e la cosa non si puó ignorare secondo me. e comunque via, possono ancora essere utili (vedi il seguito).

MFC sono un aborto. Chiunque si sia trovato costretto a lavorarci può confermarlo.
Prova a fare un layout degno di questo nome con le MFC: far si che non si scompagini tutto quando ingrandisci la finestra è un incubo.
Anche le wxWidgets nonostante abbiano una certa somiglianza con le MFC sono molto più semplici da usare.
In ogni caso niente a che vedere con le QT, come semplicità d'uso e potenza espressiva della libreria (tra le tante: i fogli di stile e l'animation framework)

risaputo, infatti io MFC le consiglio solamente se si é estremamente sicuri che il proprio programma non dovrá mai essere portato su altri sistemi. per quanto riguarda il legame stretto che MFC ha con le API, non vedo che problema ci sia: di certo é un pregio in termini di performance che un metodo sia implementato inline come semplice chiamata ad una API, e i metodi di MFC io non li trovo difficili da usare perché comunque eliminano le noie dell'uso delle API (vedi ad esempio la gestione delle stringhe: in Win32 si alloca tutto a mano, in MFC fanno tutto le varie CString) lasciando solo il divertimento. e poi sono object-oriented: laddove una API ha ad es. il parametro HWND per idetificare la finestra su cui opera, il corrispondente metodo MFC usa this.

Non vedo il motivo, anche per un software che girerà sempre e solo sotto windows, di non usare strumenti più potenti anche a parità di linguaggio.

ricorda comunque che é una dipendenza, perc ui te lo devi portare appresso. per fare le cose semplici (e per diminuire la dimensione di deployment) sarebbe meglio affidarsi esclusivamente al software giá incluso con Windows, quindi MFC, ATL e il runtime C/C++ di Visual Studio.

Sicuro che troverai sul sistema di destinazione la versione corretta di MFC?
Il runtime di visual studio (quale versione?) poi non mi risulta installato di default.
In ogni caso c'è sempre il link statico a disposizione.
Non capisco perchè nessuno si scandalizzi per un programma che per fare le peggio minchiate occupa non meno di 30MB di memoria (dove la misura è il Gigabyte), ma se un software ha un eseguibile di 10MB (dove la misura è il TeraByte) debba essere un problema.
E non parliamo della duplicazione del caricamento delle librerie perchè l'occupazione di memoria di un programma C++ linkato staticamente è comunque una frazione di uno .NET.
Oltretutto ti svincoli da quello che potrebbe fare l'utente (o altri programmi) sulla macchina, in quanto il tuo software è fondamentalmente autonomo, se non dalle librerie effettivamente di default di windows (non disinstallabili o comunque decisamente non corruttibili senza rendere il sistema inusabile).

se é per questo fin dalla versione 6 di Visual C++ (non so le precedenti) potevi programmare WordPad solo a forza di wizard, veramente senza scrivere una riga di codice

Oddio si fa prima a scrivere il codice che ad usare gli wizard per generare l'intero programma.

guarda, non so per te ma per me un mese é un'eternitá
uno dei miei primi programmi scritti in C# era una utility per tenere traccia dei miei esami universitari; la GUI l'ho creata con Windows Forms e ci ho messo mezza giornata senza mai aver usato Windows Forms.

Se per questo se li scrivevi su un file txt nome esame:voto facevi anche prima.

con MFC e i wizard di Visual Studio non sarei arrivato a questi livelli, magari avrei dovuto smanazzarci tre giornate anziché una, ma di certo non un mese...

Non credo che sia poi tanta la differenza in tempi di sviluppo usando qualcosa come QTCreator (o il plugin qt per Visual Studio).