[C++] Documentazione su sviluppo con librerie e framework (MFC, ecc.)

[giuseppe500]

CIao.
Vorrei che mi consigliaste un libro sul visual c++ , framework mfc che spiegasse le tecniche di programmazione windows piu' che i pattern oop(per quelli mi hanno gia consigliato altri libri su questo forum).

[pallinopinco]

Detto tra noi, a meno di esigenze molto particolari, non ha molto senso studiare le MFC nel 2007, esistono framework più moderni e più supportati.

Comunque buoni libri sull'argomento sono "Programming Windows With MFC" di Jeff Prosise e "Inside C++" di Kruglinski et al.

[giuseppe500]

questo è un dubbio che mi porto avanti dalla versione beta di c#:
il framework .net "gira" soto una virtual machine , a mo del suo precursore java ,il fatto che sia interpretato non l'ho mai capito erchè cedere cosi' tanto in termini di velocità se non deve essere portabile?
ho letto di mono , ma non l'ho mai provato , e poi non è proprio per niente portato avanti da microsoft,anzi....
quindi :è possibile compilare il .net in codice nativo?
se si come?
se no perchè questi controsensi, dato che un applicazione win32 in c++ va 4/5 volte piu' veloce?
grazie.

[pallinopinco]

se no perchè questi controsensi, dato che un applicazione win32 in c++ va 4/5 volte piu' veloce?

Come hai effettuato queste misurazioni? A quale tipologia di applicazioni ti riferisci? La tua stima non include i tempi della compilazione JIT, vero?

[alka]

Originariamente inviato da giuseppe500
il framework .net "gira" soto una virtual machine , a mo del suo precursore java ,il fatto che sia interpretato non l'ho mai capito erchè cedere cosi' tanto in termini di velocità se non deve essere portabile?

E' necessario avere un runtime se ci si vuole far carico del rilascio della memoria, regolare l'accesso agli assembly, applicare restrizioni di sicurezza sul codice e altro ancora.

Originariamente inviato da giuseppe500
quindi :è possibile compilare il .net in codice nativo?

No, il CLR del .NET Framework esegue codice intermedio (IL).

Originariamente inviato da giuseppe500
se no perchè questi controsensi, dato che un applicazione win32 in c++ va 4/5 volte piu' veloce?

Per quanto le applicazioni Win32 siano tendenzialmente più performanti, ciò non toglie che il CLR consenta di usufruire di una gamma di servizi. La rapidità di esecuzione non è l'unico fattore di cui si deve tenere conto nello sviluppo di progetti, e proprio per questo la scelta (.NET sì o no) dev'essere ponderata in base a ciò che si deve realizzare.

Comunque, siamo abbastanza OT e di questo argomento si è già dibattutto all'infinito in passato.

[pallinopinco]

No, il CLR del .NET Framework esegue codice intermedio (IL).

Vero, però esiste la possibilità di generare immagini native con appositi strumenti contenuti nel .NET Framework SDK.

[alka]

Originariamente inviato da pallinopinco
Vero, però esiste la possibilità di generare immagini native con appositi strumenti contenuti nel .NET Framework SDK.

Sì, anche se - mantenendo un aggancio con le motivazioni poste, cioè la questione performance - la generazione di immagini native non garantisce necessariamente prestazioni superiori, in quanto si tiene conto dello stato della macchina al momento della generazione del codice, e non è quindi possibile (da parte del CLR) applicare alcuna ottimizzazione "al volo", cosa che dovrebbe avvenire (secondo le specifiche) nell'ambito di una normale esecuzione di un'applicazione .NET.

Ciao!

[pallinopinco]

Sì, anche se - mantenendo un aggancio con le motivazioni poste, cioè la questione performance - la generazione di immagini native non garantisce necessariamente prestazioni superiori, in quanto si tiene conto dello stato della macchina al momento della generazione del codice, e non è quindi possibile (da parte del CLR) applicare alcuna ottimizzazione "al volo", cosa che dovrebbe avvenire (secondo le specifiche) nell'ambito di una normale esecuzione di un'applicazione .NET.

Beh, il codice nativo generato risulta ottimizzato per la specifica configurazione hardware, se non si apportano cambiamenti significativi si hanno comunque dei vantaggi (o almeno non si perde nulla rispetto alle prestazioni del "bytecode"). Detto questo, a parte contesti ed esigenze particolari, suggerisco di affidarsi alla compilazione JIT.

In ogni caso la mia non era una risposta alla questione sulle prestazioni, piuttosto alla possibilità di compilare in codice nativo.

Stiamo perdendo il topic della discussione... Potremmo riprendere il filo discutendo l'opportunità di studiarsi framework alternativi a MFC: VCL, wxWidgets, Windows Forms, QT e via discorrendo.