Newsgroup: it.comp.programmare.win32
Titolo: MFC, DAO, ADO... che succederà?

Salve a tutto il ng,
    volevo scambiare qualche parere sul futuro delle tecniche di
programmazione in ambiente win32. Mi spiego:
con l'avvento della piattaforma .NET, di C# e di tutti i nuovi linguaggi
"managed", del CL e così via, che ne sarà delle MFC? Che ne sarà delle altre
tecnologie per l'implementazione di componenti, per l'accesso ai dati... che
ne sarà di ADO, DAO, ATL, COM...
    Insomma, volendo scrivere applicazioni stand-alone (o principalmente
tali), con forti vincoli prestazionali (grafica, programmi di calcolo...)
verso cosa bisogna indirizzarsi senza correre il rischio di "diventare
bravi" in una tecnologia obsoleta o destinata a diventarlo a breve?
    Mi rendo conto che i web services e le applicazioni internet-oriented
sono la "fetta grossa" di oggi e meritano tutta l'attenzione, ma non vi pare
che ci sia anche dell'altro che generalmente si fa co i pc?
    Grazie per aver letto fin qui e... buon natale a tutti.

 ne sarà di ADO, DAO, ATL, COM...
Secondo il mio modesto parere, per considerazioni varie che abbiamo fatto
anche noi:
1) se vuoi scrivere codice non facilmente decompilabile, continua ad usare i
linguaggi tradizionali compilati in codice nativo
2) .NET mi sembra bella in teoria, ma aspettiamo che venga usata; se è come
tutti gli altri prodotti MS, ne vedremo delle belle...
3) prestazioni e facilità di scrittura dei programmi sono inversamente
proporzionali
4) le cose non cambieranno in tempi brevi, comunque vada con .NET, vista la
mole di codice esistente
5) rassegnati: se vuoi fare il programmatore (lo sconsiglio a chiunque) le
tue conoscenze "tecniche" invecchieranno molto rapidamente, investi in
"algoritmi"
6) sono stufo di investire continuamente il mio tempo in apprendimento su
come funzionano gli strumenti, voglio USARE gli strumenti per fare qualcosa;
quindi aspetterò fino all'ultimo momento per passare ad una nuova
tecnologia, per quanto bella sia!
Uno sfogo dopo una giornata di parolacce:
windows2000serverfaveramenteSCHIFO!!!!!!!!!!!!!!!!!!!!!!!!
Ha una gestione della memoria che fa pena!
Ciao
GG

 ne sarà di ADO, DAO, ATL, COM...
Per quanto riguarda questi ultimi, ho paura che saranno soppiantati
rapidamente da .NET. Per quanto riguarda MFC, penso che continueranno ad
essere usate ancora per qualche tempo (anni). Un gesto velleitario che
la Microsoft potrebbe fare per "suggerire" ai programmatori quali
strumenti usare, e` quello di eliminare il supporto per MFC (o
addirittura per la chiamata alle API) all'interno dei prossimi Visual
C++; prima di fare una cosa del genere pero` dovra` essere piu` che
*certa* che la stragrande maggioranza dei programmatori la seguiranno, e
viste le ottime alternative di Borland (che fanno concorrenza diretta a
MFC) non credo che questo succedera` a breve.
--
Lorenzo

C++;
Che tolgano la possibilità di richiamare la API mi sembra impossibile,
anche perché poi loro come si compilano Windows?
-- 
Marco Barisione (ICQ 84277092)

anche perché poi loro come si compilano Windows?
Potrebbero tranquillamente non distribuire i .h/.lib usati da loro
all'interno :)

 ha scritto nel messaggio
news:du7k2u8fnq734grqh...@4ax.com...

Con BCB :)
Ciao
--
Davide
--
The Secret of Tabboz Island
http://it.geocities.com/tabbozisland
*** Il forum c'è!! C'è il forum!! ***
http://it.geocities.com/tabbozisland/forum.htm

Quindi secondo voi non è un cattivo investimento ti tempo e denaro comprare
OGGI il Petzold x l'API di win32 ed il Prosise per il VC++ 6.0 e le MFC?



Secondo me una conoscenza di base di Win32 sarà sempre utile, sia che
si programmi in C++, in MFC o Visual Basic, in ambiente .net o
Borland.
Su MFC non mi esprimo non usandole.
Ciao 
Stefano "HappyMan" 
--
IABLA Sezione Lago Maggiore (NO)
Web 
http://happyman.n3.net
 [Foto salseri/e & I.A.B.L.A. Ring]
Email: 
happyman...@libero.it
 [Togliere nospam per scrivermi]


secondo il mio modesto parere cosi' facendo rimarrebbero molto pochi coloro
che comprerebbero VC++ o addirittura windows, visto che os migliori esistono
anche gia'... vedi linux il quale distribuisce pure i sorgenti, chiunque si
tufferebbe su questo tipo di opportunita'...



sono _d'accordissimo_ con te! :)
pero' sopra si parlava di un modo di "oscurare" le api...e mi e'
venuto in mente quello - ma, ripeto, secondo sbaglierebbero se lo
facessero, come tu giustamente hai osservato!!