Newsgroup: it.comp.lang.c++
Titolo: Sempre su WinC++/VisualC++

Cari niusgruppici,
innanzitutto vi ringrazio per l'interesse dimostrato verso le mie domande 
un po' "provocanti" da tanti di voi, ho cercato di farmi un idea delle 
varie opinioni esistenti. Quello che comunque mi e sembrato di capire e 
che, con o senza l'ausilio dei Wizzardi, le applicazioni svipuppate con 
le MFC sono un po' il corrispondente del Visual Basic: un modo per creare 
applicazioni in fretta e furia senza troppo curarsi di efficienza, 
velocita, possibilita di implementazioni future e altre cose che, a 
parere mio e di tutti i professori dell'universita che mi hanno istruito 
fin'ora, sono praticamente fondamentali per la riuscita di un buon 
applicativo. E evidente che in alcuni casi il fattore tempo prende il 
sopravvento, ma allora non e molto piu rapido ( piu RAD...) sviluppare in 
Visual Basic? E piu facile, intuitivo e veloce e non mi pare che abbia 
tare maggiori delle applicazioni MFC-Based per quanto riguarda poi il 
risultato: insomma, se la velocita di sviluppo deve essere comunque 
pagata in termini di prestazioni vale la pena che lo sviluppo sia davvero 
rapido, cosa che mi pare che con le MFC non sia: insomma il classico 
neofita ( anche se non mi reputo piu tale) e certo piu a suo agio col VB 
piuttosto che con la complicata meccanica delle MFC. Quindi mi orienterei 
verso una programmazione forse piu laboriosa e lunga che faccia uso 
direttamente delle API di Windows senza passare da interfacce si comode, 
ma anche costose, anche se mi chiedo se sia materialmente possibile 
creare applicativi anche di una certa dimensione in questa maniera, 
rigiro la domanda a voi esperti; e a proposito di questo mi chiedo anche 
se il mio applicativo sara poi aggiornabile con facilita con le eventuali 
nuove funzioni incluse in future versioni del Sistema Operativo oppure 
dovro riscrivere tutto il codice? Forse questo aspetto varrebbe la pena 
di usare le MFC che non mi devo occupare di aggiornare e che 
richiederebbero solo una ricostruzione dell'eseguibile. Concludo 
chiedendo se qualcuno conosce dei testi sullo stile di quello di Eckel 
per programmare in Windows in versione non cartacea e possibilmente 
gratuiti, non avendo la possibilita di investire troppo denaro in libri 
da centinaia di migliaia di lire; attualmente possiedo la MSDN che pero 
trovo un po macchinosa da utilizzare per uno che vuole cominciare, un HLP 
file con tutte le api e poco piu.
Grazie a tutti per l'aiuto
				Mush-Herpes
-- 
¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
Aisicchiù #41982464
Per contattarmi via mail eliminate "NOSPAM"
"Evviva la disco music, col tipico ritmo 
incalzante di cassa rullante e charleston."
			Elio e le Storie Tese
¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

 richiederebbero solo una ricostruzione dell'eseguibile. Concludo
Perche' non dovrebbe esserlo ?
L'unico caso in cui ti converrebbe riscrivere quasi completamente il codice
sarebbe nel passaggio da 32bit a 64bit, ma ritengo che tu non debba fartene
una preoccupazione nel breve termine (oltretutto se diventera un bravo
programmatore potrai strutturare gia' in partenza i tuoi programmi in modo
che siano il piu' possibile 64bit-ready).
Il confronto non dovrebbe essere tra VC++ (con annessi e connessi) e VB in
senso stretto, ma tra due diverse 'filosofie' di progettazione delle
applicazioni. Una volta che scegli di partire con C++ (non necessariamente
VC++) e di utilizzarlo per sviluppare applicazioni Object-Oriented ti trovi
a dover studiare tali e tante problematiche (anche solo per collegarti ad un
database relazionale) che per sviluppare la *prima* applicazione decente
potresti anche metterci a..i. In VB e' tutto piu' semplice, bim bum bam, un
controllo qui un controllo la' e hai un'applicazione collegata ad un DB
relazionale con query, reports e quant'altro.
Dipende da te, la scelta.
MM

 file con tutte le api e poco piu.
Sui CD trovi anche una valanga di esempi, documentazione aggiuntiva, ecc.
Sulla macchinosità sono d'accordo. Senza voler aprire polemiche, trovo che
MS non faccia molto bene i suoi IDE.
--
Alessandro Monti

 ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
Ho sviluppato piu' di un programma usando MFC, e le possibilta' sono
enormemente piu'
ampie che utilizzando VisualBasic (senza chiamare le Win32API da VB).
Secondo me pero' MFC e' una libreria pensata piu' per i Wizard che per
l'utente,
e i Wizard sono programmazione magica-mediovale, non accettabili nell'era
della ragione.
Ho iniziato a sviluppare una libreria a classi (c++) in sostituzione di MFC
(piu' semplice e controllabile, senza CDocument/CView e altre complicazioni
simili).
Funziona molto bene per quanto riguarda l'uso tradizionale di Win32.
Trovo i principali problemi nell'uso dei controlli ActiveX e nel creare
oggetti OLE inseribili
in contenitori OLE quali Word, Excel, etc.
Mentre l'uso di librerie COM tipo DAO o ADO e' abbastanza semplificato dalla
direttiva #import.
Penso che un programma sviluppato con API Win32, se realizzato con un minimo
di etica,
continuera' a funzionare anche su versioni future di Windows senza dover
essere modificato.
Il problema e' se gli utenti del programma non lo considereranno vecchio e
obsoleto,
come capita purtroppo oggi a molti programmi Win16.
Per quanto riguarda l'help, si puo' configurare il programma per leggere
MSDN
in modo da escludere tutte le sezioni non volute.
Oppure insieme ai C++ Borland (dalla versione 4.5) o ai C-Builder Borland
c'e' un file .HLP
che descrive le Win32 API, ma secondo me MSDN e' piu' sicuro.

come capita purtroppo oggi a molti programmi Win16.
Ti do una buona notizia: Windows 98 e' l'ultimo sistema operativo di
Microsoft che supporta le applicazioni a 16 bit...
Ciao!
Luca Menegotto