Newsgroup: it.comp.programmare.win32
Titolo: Visual C++ 6 - madonna che schifo

Ho installato questo ambiente di sviluppo.
A primo impatto, se paragonato anche alla versione 3 di C++ Builder, direi 
che fa proprio schifo.
Ma esiste un Object Inspector?
Mi dite come posso fare un'applicazione di prova, anche una banalità come 
creare una form, mettere un pulsante ed un etichetta che cambia il suo testo 
al click del pulsante.
A quanto dicono il VC++ è più diffuso del C++ Builder, ma c'e' un motivo 
reale che non sia lo strapotere Microsoft?
Grazie 

 reale che non sia lo strapotere Microsoft?
credo che la qualità del compilatore sia migliore; ma se non altro MFC e
ATL non sono implementati in Object Pascal :D
vorrei infine farti notare che hai installato una versione antidiluviana,
e non essendo questa nemmeno più acquistabile da Microsoft cercherò di
evitare di pensare come tu te la sia procurata. :)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 evitare di pensare come tu te la sia procurata. :)
Libera la fantasia... ^_^ 

 Forms; li ho detti in ordine di difficoltà, a decrescere :P
Il secondo metodo in pratica consinste nello scrivere manualmente tutto il 
codice che di solito genera l'object inspector?
Tipo l'uso di AWT/Swing in Java facendo uso di un solo editor (tipo 
Notepad)?
Ciao 

ATL non sono implementati in Object Pascal :D
Dopo le critiche agli Unix, sono pronto a sentire l'altra "genialata"
su Object Pascal (preciso, esattamente come nel caso degli Unix, che
uso Delphi da circa 10 anni ;-)

Builder si lamentavano del fatto che la VCL fosse scritta in Object Pascal.
Be', io sono un programmatore C++ e non mi lamento del fatto che la
VCL sia scritta in Object Pascal. Ho usato C++ Builder per qualche
anno per lo sviluppo di applicazioni nel campo del CTI e prima che
venisse gettato alle ortiche come prodotto da mamma Borland
(purtroppo) e non ho riscontrato problemi dovuti al fatto che la
libreria di base per il RAD, fosse scritta in OP.
Probabilmente quei programmatori che si "lamentano", dovrebbero prima
preoccuparsi di conoscere il C++ sufficientemente bene da riuscire a
rimpiazzare la VCL con qualcosa di meglio, non credi? ;-)

 rimpiazzare la VCL con qualcosa di meglio, non credi? ;-)
Ah ma io mica mi lamento del fatto che la VCL sia scritta in OP, soltanto 
ricordo che a molti non andava bene.
Ciao 

 Notepad)?
per Java esiste Visual Editor :P


 Builder si lamentavano del fatto che la VCL fosse scritta in Object Pascal.
è un'obiezione accademica più che altro: sarebbe stato più pulito lavorare
di linking a quel punto :P


Se si usano le mfc praticamente si lavora in modo quasi uguale al builder, 
peccato che le mfc siano ora obsolete...
A parte questo mi domando: perchè installare un compilatore senza sapere 
come funziona o averne un manuale!?

peccato che le mfc siano ora obsolete...
Non è esattamente la stessa cosa.

 peccato che le mfc siano ora obsolete...
sono tutt'altro che obsolete, e sono ancora attive come sviluppo.


 sono tutt'altro che obsolete, e sono ancora attive come sviluppo.
Se per obsolete si intende che sono ancora supportate, allora non sono 
del tutto obsolete, ma se si intende che oggi sarebbe meglio progettarle 
diversamente, allora sono nettamente obsolete.
Per esempio, da un po' di tempo, nella libreria standard del C++ sono 
stati inseriti i tipi "std::vector" e "std::string", mentre MFC usa 
ancora "CArray" e "CString".
MFC ha inventato un dynamic cast e un meccanismo di gestione delle 
eccezioni basati su macro, che non fanno uso dei meccanismi standard 
"dynamic_cast", "try", "catch" e "throw".
La lettura e la scrittura del valore di un campo di una maschera usa un 
meccanismo allucinante, basato sulla routine DoDataExchange che 
sincronizza i valori dei controlli con i valori delle variabili 
associate ad essi.
I nomi di molte funzioni sono spesso copiati dall'API di Windows. Per 
esempio, per nascondere una finestra, invece di fare, come sarebbe logico:
   window.hide();
oppure
   window.show(false);
si fa:
   window.ShowWindow(SW_HIDE);
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

    window.ShowWindow(SW_HIDE);
questo non lo trovo del tutto negativo in quanto permette
l'implementazione di moltissimi "metodi" in forma inline che di fatto si
traducono in semplici chiamate API piuttosto che in chiamate a metodi
(veri e propri) che chiamano a loro volta le API. si realizzano insomma
due chiamate al prezzo di una e si mantiene tutto sommato una certa ottica
OO, in quanto il parametro HWND viene wrappato da un oggetto.


 due chiamate al prezzo di una
Non ho capito, me lo rispieghi?


 Non ho capito, me lo rispieghi?
eppure mi sembrava piuttosto facile. approccio OO ragionevole:
VOID CWnd::Hide()
{
	::ShowWindow(m_hWnd, SW_HIDE);
}
o peggio ancora:
VOID CWnd::Show(BOOL fShow)
{
	if (fShow)
	{
		/* problema secondario: qui ci metto SW_SHOWNORMAL
		o SW_SHOW ? */
		::ShowWindow(m_hWnd, SW_SHOWNORMAL);
	}
	else
	{
		::ShowWindow(m_hWnd, SW_HIDE);
	}
}
fanno due chiamate (quella a Hide/Show e quella a ShowWindow). approccio
alla MFC:
INLINE VOID CWnd::ShowWindow(int nCmdShow)
{
	::ShowWindow(m_hWnd, nCmdShow);
}
fa una chiamata sola, e scompaiono anche l'if e il problema secondario.


fa una chiamata sola, e scompaiono anche l'if e il problema secondario.
Ritenta, sarai più fortuntato. Innanzitutto l'inline non l'hai
riportato anche per i metodi di cui sopra (il che ridurrebbe la
chiamata alla sola ::ShowWindow comunque) e che l'interfaccia sia
pessima e molto meno OO di quello che sembra perché espone i dettagli
implementativi come il flag SW_SHOWNORMAL e SW_HIDE verso l'utente.
Una corretta implementazione è, invece:
inline void CWnd::show(bool fShow = true) {
    ::ShowWindow(m_hWnd, fShow ? SW_SHOWNORMAL : SW_HIDE);
}
L'utente non deve sapere nulla di specifico: true o nessun parametro
mostra la finestra, false invece nasconde la finestra.

 true o nessun parametro mostra la finestra,
e se era minimizzata la mostra minimizzata o la alza?
quelli che tu chiami dettagli implementativi non si nascondono aggratis:
l'esempio di questo caso è banale e non importa molto, ma il principio
conta perché una differenza simile può rivelarsi sottilmente importante
(tiè, pure l'ossimoro).
detto questo, il punto del discorso è che se in linea di principio MFC
riproduce fedelmente l'aspetto delle API sottostanti c'è di buono che può
sentirsi libero di implementare tutto in inline senza temere di farcire il
codice di if (mi riferisco alla Show, in questo caso la Hide non faceva
nessun danno).


nessun danno). 
Ma la smetti di dire stronzate? quale codice infarcito di if? 
Scalare gli specchi non ti fa fare una bella figura.
Non vuoi il metodo show() che distingua? vuoi che mostri e basta?
bene, ti regalo un metodo hide(). Ora procurati un buon testo di
design orientato agli oggetti e poi torna a discutere.

 eppure mi sembrava piuttosto facile. approccio OO ragionevole:
Mi pare che in molte situazioni ci siano due possibili approcci allo 
sviluppo di una interfaccia. Posso o scegliere di mantenere 
l'interfaccia il più simile possibile allo strato sottostante oppure 
cercare di progettare l'interfaccia più intuitiva possibile per l'utente 
soprastante. Penso che la scelta giusta dipenda dalla situazione.
In particolare se il substrato è già ben progettato e ben documentato, è 
preferibile mantenersi il più possibile vicino ad esso, per non dover 
introdurre nuove convenzioni (anche nel caso in cui queste renderebbero 
forse più semplice l'interfaccia). Se invece, ad esempio, voglio poter 
cambiare il substrato, allora ovviamente la seconda scelta è migliore.
La differenza tra queste scelte si apprezza facilmente confrontando 
codice OpenGL con codice DirectX. Mi pare di capire che le MFC come le 
DirectX utilizzino il primo approccio. Tra le motivazioni forse c'è 
anche quella di scoraggiare il codice portabile su diversi OS.
E.

preferibile mantenersi il più possibile vicino ad esso
Mantenere l'interfaccia vicina ai dettagli implementativi significa
accoppiare troppo il mondo esterno con il mondo interno e a che
pro?... significa che, cambiando i dettagli, cambia anche
l'interfaccia e quindi il mondo esterno deve adeguarsi.
Questo non è molto in linea con l'OOP.

 progettuale.
gli ideatori di MFC potrebbero avere il doppio della tua esperienza nonché
della tua intelligenza. motivi a te sconosciuti (e anche a me per la
verità, vista l'età di quel framework) avranno dettato loro la necessità
di aderire molto al software sottostante sacrificando il design. tuttavia
non lo ritengo un buon motivo per sparare a zero sul loro lavoro: per te
piuttosto il motivo dev'essere che sparare ti sembra più facile che
prendere la mira.


 Questo non è molto in linea con l'OOP.
non è questione di OOP: astrarre dallo strato sottostante è un'opzione, e
la scelta dell'una o dell'altra opzione è dettata da necessità specifiche.
la programmazione orientata agli oggetti è un paradigma che non definisce
criteri di eleganza e di strutturazione efficiente, ma definisce strumenti
(come l'ereditarietà, l'incapsulamento, il polimorfismo) che possono o non
possono, secondo le necessità specifiche di cui sopra, essere usati a tali
scopi.


 scopi.
Secondo me, e non solo, avendo gia' una libreria perfettamente 
funzionante, risulta utile costruirne una di livello superiore solo se 
si raggiunge un livello di astrazione maggiore. Siccome si ha gia' a 
disposizione l'API di Windows, l'adozione di MFC presuppone che si vuole 
programmare a un livello di astrazione superiore, anche a costo di 
pagare uno 0,5% di costo prestazionale o di avere qualche limitazione 
nell'uso tipico. Se si vuole avere la stessa flessibilità e la stessa 
efficienza dell'API, si usa l'API, no?
Una libreria quindi dovrebbe fornire un incapsulamento che, nella 
maggior parte dei casi, permetta di semplificare il codice. Nei casi in 
cui si vuole accedere a funzioni di livello piu' basso, la libreria 
dovrebbe consentire l'uso diretto dell'API. Per esempio, in Visual Basic 
l'interfaccia di programmazione e' di regola molto semplice, ma volendo 
fare operazioni non consentite dall'interfaccia di base, si puo' 
dichiarare un funzione dell'API, richiedere l'handle di una finestra o 
di un device context, e richiamare direttamente la funzione dell'API di 
Windows.
Una notizia cursiosa che pochi sanno, e' che la Microsoft nel 1990, 
quando non aveva ancora rilasciato nessun compilatore C++, stava 
sviluppando una libreria GUI per il compilatore C++ che stava 
sviluppando. Tale libreria avrebbe consentito di scrivere un programma 
ad un livello di astrazione tale da poter compilare un'applicazione sia 
per il sistema operativo Windows 3 che per il sistema operativo OS/2 PM 1.2.
Nell'autunno del 1990, la Microsoft ha deciso di non supportare piu' 
OS/2 PM, al punto che tale sistema operativo, che qualche mese prima 
veniva proposto come il sistema operativo del futuro, e' diventato un 
concorrente da battere e ostacolare in ogni modo.
A tale scopo, ha completamente rivisto la sua libreria affinche' fosse 
*meno* portabile, cioe' in modo da rendere molto difficile un suo 
porting per OS/2 PM. Questo ha comportato, tra l'altro, lo slittamento 
del rilascio del primo compilatore C++ Microsoft.


 Microsoft, come il C++, gli piacciono di più di quelli di Microsoft. 
E' molto diverso lo sviluppo di codice pensato per girare solo sotto 
Windows da codice che si vuole portare su diversi OS. Non puoi 
confrontare le due situazioni e dare un giudizio indifferenziato. A mio 
parere pero', chi ha un po' di autonomia nei progetti, farebbe bene a 
non legarsi ad un singolo OS o addirittura ad un singolo compilatore... 
potrebbe averne un vantaggio in futuro.
E.

 potrebbe averne un vantaggio in futuro.
l'esempio chiaramente non prevedeva che la cagata programma dovesse essere
portato su un altro sistema operativo: se il programmatore fesso era
tenuto ad usare BOOL era ovvio che stesse usando MFC o addirittura Win32
nudo e crudo, quindi programma del tutto non portabile.


 maggior parte dei casi, permetta di semplificare il codice.
ora non ci montiamo la testa: MFC mediamente introduce numerosissime
semplificazioni rispetto al codice Win32 puro, non è tutto API inline.


 ma se lo fa pure il gcc... quello di Linux :) (appena controllato)
Ugh! Come non detto...
E.