Visual C++ 6 - madonna che schifo
Noixe
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
mrnt
> 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?
hai una visione piuttosto limitata dal fatto che prima usavi un RAD e ti
pareva religione. non è che se a un IDE manca l'Object Inspector allora fa
schifo... tuttavia posso dirti che a partire dalla versione 2003 di Visual
Studio è stata introdotta anche in Visual C++ una procedura RAD per la
creazione di interfacce, che però si basa su Windows Forms. altrimenti un
editor RAD esiste solamente per le dialog box ed è piuttosto limitato: non
è "espandibile", ovvero gli manca la possibilità come in BCB di aggiungere
nuovi componenti in quanto usa solo quelli nativi di Win32, ed inoltre non
è presente nell'edizione Express.
> 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.
esistono sostanzialmente 3 modi: API Win32 nude e crude, MFC/ATL, Windows
Forms; li ho detti in ordine di difficoltà, a decrescere :P
> A quanto dicono il VC++ è più diffuso del C++ Builder, ma c'e' un motivo
> 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
Noixe
> credo che la qualità del compilatore sia migliore; ma se non altro MFC e
> ATL non sono implementati in Object Pascal :D
Ah, ora che ricordo molti programmatori di C++ che facevano uso del C++
Builder si lamentavano del fatto che la VCL fosse scritta in Object Pascal.
> 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. :)
Libera la fantasia... ^_^
Noixe
> esistono sostanzialmente 3 modi: API Win32 nude e crude, MFC/ATL, Windows
> 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
Andrea Laforgia
>hai una visione piuttosto limitata dal fatto che prima usavi un RAD e ti
>pareva religione. non è che se a un IDE manca l'Object Inspector allora fa
>schifo...
"Fa schifo" rispetto a uno RAD :-P
>[...]ma se non altro MFC e
>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 ;-)
Andrea Laforgia
wrote:
>Ah, ora che ricordo molti programmatori di C++ che facevano uso del C++
>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? ;-)
Noixe
> 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? ;-)
Ah ma io mica mi lamento del fatto che la VCL sia scritta in OP, soltanto
ricordo che a molti non andava bene.
Ciao
mrnt
> Il secondo metodo in pratica consinste nello scrivere manualmente tutto il
> codice che di solito genera l'object inspector?
no: il ClassWizard, l'AppWizard, e lo stesso Resource Editor sono in grado
di scrivere parecchio codice MFC, addirittura con supporto OLE.
> Tipo l'uso di AWT/Swing in Java facendo uso di un solo editor (tipo
> Notepad)?
per Java esiste Visual Editor :P
mrnt
> Ah, ora che ricordo molti programmatori di C++ che facevano uso del C++
> 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
4N
peccato che le mfc siano ora obsolete...
A parte questo mi domando: perchè installare un compilatore senza sapere
come funziona o averne un manuale!?
Andrea Laforgia
>Se si usano le mfc praticamente si lavora in modo quasi uguale al builder,
>peccato che le mfc siano ora obsolete...
Non è esattamente la stessa cosa.
mrnt
> Se si usano le mfc praticamente si lavora in modo quasi uguale al builder,
> peccato che le mfc siano ora obsolete...
sono tutt'altro che obsolete, e sono ancora attive come sviluppo.
Carlo Milanesi
> 4N ha scritto:
>
>> Se si usano le mfc praticamente si lavora in modo quasi uguale al builder,
>> peccato che le mfc siano ora obsolete...
>
> 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
mrnt
> 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 obsolete si intende esattamente ciò che significa in italiano la
parola obsoleto: poco usato, non in uso (letteralmente, non solito), con
la sfumatura accettiva di "antiquato". che le MFC siano antiquate sotto
molti punti di vista è sicuramente vero ma, pur non avendo statistiche
alla mano, che siano poco usate non lo ritengo probabile.
tuttavia concordo che se le MFC venissero riscritte oggi ex-novo (ed
ipotizzando che Microsoft lo faccia senza fargli subire l'influenza di
NET) sarebbero abbastanza diverse. concordo su quanto detto circa 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".
anche se venissero riscritte le MFC probabilmente continuerebbero ad usare
__try ed __except, piuttosto che try e catch, allo scopo di uniformarsi al
meccanismo di SEH del sistema operativo.
> 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);
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.
Andrea Laforgia
> anche se venissero riscritte le MFC probabilmente continuerebbero ad usare
> __try ed __except, piuttosto che try e catch, allo scopo di uniformarsi al
> meccanismo di SEH del sistema operativo.
Dai, questa l'hai buttata lì ;-)
Al meccansimo di structured exception handling del sistema operativo ci si
può adeguare anche non usando __try ed __except, ma il try/catch standard.
Non vedo cosa lo vieti.
> due chiamate al prezzo di una
Non ho capito, me lo rispieghi?
mrnt
> Al meccansimo di structured exception handling del sistema operativo ci si
> può adeguare anche non usando __try ed __except, ma il try/catch standard.
> Non vedo cosa lo vieti.
il meccanismo che regola il funzionamento di try/catch non è legato al
sistema operativo ne' tantomeno è determinato dallo standard del C++,
quindi la sua implementazione resta a discrezione di chi scrive il
compilatore. come risultato i due meccanismi possono interferire tra di
loro a causa delle implementazioni di certi compilatori che wrappano il
try/catch sul __try/__except, come nel caso di Borland C++. l'uso di un
try basato su __try può interferire con __try bloccando eccezioni SEH che
si intende in realtà propagare. un'ipotetica implementazione di MFC non
accorta di questo problema riduce la sua portabilità su altri compilatori,
o peggio ancora produce effetti diversi su compilatori diversi. ma per
fortuna a progettare le MFC non sei tu. :)
> > due chiamate al prezzo di una
> 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.
Andrea Laforgia
>il meccanismo che regola il funzionamento di try/catch non è legato al
>sistema operativo
In linea di principio no, ma è possibilissimo che una particolare
implementazione si interfacci a basso livello con il sistema
operativo. Se il sistema operativo prevede una gestione implicita
delle eccezioni, un compilatore specifico può anche basarsi su esso.
Come già detto, nessuno lo vieta.
>un'ipotetica implementazione di MFC non
>accorta di questo problema riduce la sua portabilità su altri compilatori,
Parlare di MFC e di portabilità nella stessa frase è un pochino
azzardato, non credi?
>o peggio ancora produce effetti diversi su compilatori diversi. ma per
>fortuna a progettare le MFC non sei tu. :)
Mah, guarda, non essere il progettista delle MFC è più motivo
d'orgoglio che di rammarico. E poi tu sai forse come io progetto le
mie classi? finora nessuno s'è mai lamentato ;-)
>eppure mi sembrava piuttosto facile. approccio OO ragionevole:
Vediamo.
>VOID CWnd::Hide()
>{
> ::ShowWindow(m_hWnd, SW_HIDE);
>}
>
>o peggio ancora:
>
>VOID CWnd::Show(BOOL fShow)
Peggio ?
A me sembra un approccio ottimale: interfaccia intuitiva, semplice,
lineare.
>{
> 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.
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.
mrnt
> In linea di principio no, ma è possibilissimo che una particolare
> implementazione si interfacci a basso livello con il sistema
> operativo. Se il sistema operativo prevede una gestione implicita
> delle eccezioni, un compilatore specifico può anche basarsi su esso.
non su icpw32 :PPP
> Parlare di MFC e di portabilità nella stessa frase è un pochino
> azzardato, non credi?
stiamo parlando di portabilità tra compilatori, non tra piattaforme: MFC
compila anche sul compilatore Borland, cosa che non sarebbe riuscito a
fare se l'avessi progettato tu.
> E poi tu sai forse come io progetto le
> mie classi? finora nessuno s'è mai lamentato ;-)
nessun programmatore o nessun cliente?
> Peggio ?
si: introduce necessariamente un inutile if implementativo, che al massimo
puoi sostituire con l'operatore ternario. a voler essere pignoli if e
operatore ternario dal punto di vista dell'ottimizzazione fanno peggio che
la chiamata di troppo: costringono la CPU a far intervenire il branch
predictor per salvare il prefetch delle istruzioni.
> 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)
ovviamente non nel caso del tuo design preferito, cioè quello della
Show(BOOL).
> inline void CWnd::show(bool fShow = true) {
come, non lo sai che bool è deprecato? :)
in un array di bool 3 locazioni su 4 sono disallineate, ed inoltre i
processori lavorano meglio con dati della dimensione esatta del loro data
bus (vedere definizione di BOOL).
> ::ShowWindow(m_hWnd, fShow ? SW_SHOWNORMAL : SW_HIDE);
perché SW_SHOWNORMAL e non SW_SHOW?
> 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).
Andrea Laforgia
>> In linea di principio no, ma è possibilissimo che una particolare
>> implementazione si interfacci a basso livello con il sistema
>> operativo. Se il sistema operativo prevede una gestione implicita
>> delle eccezioni, un compilatore specifico può anche basarsi su esso.
>
>non su icpw32 :PPP
Sì, anche su icpw32 ed è inutile che ci metti le faccine.
Windows, per tua informazione, è solo un sistema operativo e nessuno
vieta agli implementatori di un compilatore specifico di adoperarsi
per integrare il loro prodotto o meno con il sistema.
>> Parlare di MFC e di portabilità nella stessa frase è un pochino
>> azzardato, non credi?
>
>stiamo parlando di portabilità tra compilatori, non tra piattaforme: MFC
>compila anche sul compilatore Borland,
Non confondere. E' il codice che *USA* le MFC che viene compilato,
perché il compilatore Borland (*quale* poi ? immagino ti stia
riferendo al C++ Builder) supporta le MFC.
>cosa che non sarebbe riuscito a
>fare se l'avessi progettato tu.
Continui a esprimere questi giudizi idioti. Continuerà per molto?
Vai sul personale perché non hai di meglio da fare?
Ora mi stai incuriosendo: queste tue certezze da dove verrbbero fuori?
>> E poi tu sai forse come io progetto le
>> mie classi? finora nessuno s'è mai lamentato ;-)
>
>nessun programmatore o nessun cliente?
Non sto qui a giudicare la mia esperienza e la soddisfazione dei
clienti per i quali lavoro con uno che non sa neanche di che cosa sta
parlando e che dimostra, nelle sue esternazioni, di non avere una
conoscenza approfondita degli argomenti.
>si: introduce necessariamente un inutile if implementativo, che al massimo
>puoi sostituire con l'operatore ternario. a voler essere pignoli if e
>operatore ternario dal punto di vista dell'ottimizzazione fanno peggio che
>la chiamata di troppo: costringono la CPU a far intervenire il branch
>predictor per salvare il prefetch delle istruzioni.
Un "if" in più che riporti il modello a un miglior principio
object-oriented è di gran lunga preferibile che l'ottimizzazione
preventiva a scapito dell'interfaccia della classe.
>> 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)
>
>ovviamente non nel caso del tuo design preferito, cioè quello della
>Show(BOOL).
Rileggi, perché ancora non hai capito: se non usi l'inline è ovvio che
le chiamate diventano due, se usi l'inline è *PROBABILE* che la
chiamata diventi una (non certo, perché è solo un suggerimento per il
compilatore), ma se usi inline da una parte, devi usarla dall'altra,
altrimenti sei semplicemente disonesto.
>> inline void CWnd::show(bool fShow = true) {
>
>come, non lo sai che bool è deprecato? :)
Nella tua testa forse e in quella dei tuoi amichetti progettisti delle
MFC, non secondo l'ultimo standard ISO/IEC del C++.
>in un array di bool 3 locazioni su 4 sono disallineate, ed inoltre i
>processori lavorano meglio con dati della dimensione esatta del loro data
>bus (vedere definizione di BOOL).
Evita di dire cazzate, per cortesia. BOOL è l'ennesima stronzata
Microsoft fuori standard. Il C++ prevede il tipo bool che è benissimo
mappabile, a livello implementativo del compilatore specifico, su ciò
che più aggrada al processore e alla tua testolina.
>perché SW_SHOWNORMAL e non SW_SHOW?
Ma che domande fai??
E' il principio alla base dell'esempio che conta! non il flag
specifico!.
>quelli che tu chiami dettagli implementativi non si nascondono aggratis:
La programmazione e la progettazione orientata agli oggetti si basano
su dei presupposti fondamentali che tu evidentemente non conosci e
quindi non ti imbarcare in discussioni su come vadano o meno racchiusi
i dettagli implementativi perché (si vede), sei evidentemente a
digiuno. Se si vuol scrivere una libreria di classi, bisogna saperlo
fare e che ti piaccia o meno, quello fatto con le MFC nel caso
specifico, è un evidente errore progettuale.
>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
Una classe wrapper deve nascondere i dettagli sottostanti ed avere
un'interfaccia intuitiva. Non mi serve a una cippa una classe che
espone un metodo inline che ha la stessa firma di una funzione di
libreria: a questo punto uso direttamente la funzione.
>senza temere di farcire il
>codice di if (mi riferisco alla Show, in questo caso la Hide non faceva
>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.
?manu*
> 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.
Andrea Laforgia
<pao...@NO.math.unifi.SPAM.it> wrote:
>In particolare se il substrato è già ben progettato e ben documentato, è
>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.
mrnt
e suonano eccessivamente aggressive, come fossero frasi preparate che non
vedi l'ora di rifilarmi, visti i recenti accolli per portarmi in zona
flame. (il che mi fa sorgere la domanda: si può sapere che cazzo vuoi?)
di volgarità ne avrò scritte anche io, sicuramente, ma non ricordo di
averle mai rivolte alla tua persona. non fa piacere leggere e rispondere a
uno che ti si rivolge così, e di dimostrare di saper "vincere" una
flamewar me ne frega poco. quindi alla prossima tua risposta potrei
decidere di non rispondere a mia volta. considerala pure una stravolgente
"vittoria" e segnatela nel tuo tabellone dei flames: chi risparmierà ATP
nello scrivere sono io.
Andrea Laforgia ha scritto:
> Sì, anche su icpw32 ed è inutile che ci metti le faccine.
> Windows, per tua informazione, è solo un sistema operativo e nessuno
> vieta agli implementatori di un compilatore specifico di adoperarsi
> per integrare il loro prodotto o meno con il sistema.
se ti riferisci ad un'implementazione di try/catch basata su SEH credevo
che non l'avresti ammesso, visto che va a tuo sfavore nella discussione:
significherebbe che i due meccanismi interferiscono e non possono essere
usati assieme in determinate situazioni.
> Non confondere. E' il codice che *USA* le MFC che viene compilato,
> perché il compilatore Borland (*quale* poi ? immagino ti stia
> riferendo al C++ Builder) supporta le MFC.
si, mi riferisco al C++ Builder (non so se fosse possibile usare MFC anche
in Borland C++), ma non è importante.
il codice che mischia l'exception handling di C++ con lo structured
exception handling di Win32 è codice che riduce la sua portabilità su
compilatori diversi, perché produce risultati diversi (presumibilmente
errati) in quei compilatori dove i due meccanismi interferiscono tra di
loro a causa dell'implementazione dell'exception handling.
posto questo la mia osservazione iniziale consisteva nel dire che ritenevo
improbabile una implementazione di MFC che includesse C++ exception
handling perché potrebbe avere la necessità di mischiare i due costrutti.
> Un "if" in più che riporti il modello a un miglior principio
> object-oriented è di gran lunga preferibile che l'ottimizzazione
> preventiva a scapito dell'interfaccia della classe.
è la solita storia circa il fatto che il tempo-uomo valga molto di più del
tempo-macchina: la conosco e la approvo pienamente, non sto qui ad
osannare MFC come bellezza assoluta e perfezione.
> Rileggi, perché ancora non hai capito: se non usi l'inline è ovvio che
> le chiamate diventano due, se usi l'inline è *PROBABILE* che la
> chiamata diventi una (non certo, perché è solo un suggerimento per il
> compilatore), ma se usi inline da una parte, devi usarla dall'altra,
> altrimenti sei semplicemente disonesto.
l'usare o meno nel codice la keyword inline è una scelta che dipende molto
dalla dimensione e velocità del codice nella funzione in questione: un
solo if è sufficiente a scegliere di non usarla. progettare un framework
dal design diverso dallo strato di software sottostante significa
introdurre comportamenti. i comportamenti più significativi si traducono
in costrutti, e i costrutti pregiudicano significativamente la scelta
dell'implementazione inline. paragonando un tipico approccio bello ed
object oriented all'approccio di MFC non è disonesto omettere
l'implementazione inline nell'approccio bello ed OO perché tale approccio
introduce comportamenti e tipicamente non prevede l'implementazione
inline. da cui il discorso:
> 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.
l'aspetto positivo di MFC che tendo ad evidenziare sottostando alle tue
volgarità è dunque l'ottimizzazione resa possibile dalla fedele
riproduzione dello strato sottostante. potremmo semplicemente dire che a
conti fatti alcune parti di MFC sono inesistenti. da cui invece il tuo
discorso:
> Non mi serve a una cippa una classe che espone un metodo inline che ha la
> stessa firma di una funzione di libreria: a questo punto uso direttamente
> la funzione.
Hide() è uno dei rari casi che validano la tua affermazione, perché Hide
permette una maggiore brevità di scrittura ma non introduce comportamenti.
ai fini funzionali è inutile, e un framework inutile ai fini funzionali
dubito che esista se non altro per autostima del team.
Show(BOOL) invece è quanto invalida la tua affermazione: posto che io
preferisco il design Show/Hide senza parametri piuttosto che Show(BOOL)
col valore di default al parametro, Show(BOOL) è un caso di metodo che
migliora il design e introduce un comportamento (non lo è, ma facciamo
finta visto che potremmo trovare una milionata di esempi migliori). in tal
caso, che del metodo inline ShowWindow privato di un parametro tu non te
ne faccia niente non è vero, proprio perché questi è inline. non dico che
tu debba religiosamente scegliere il metodo inline: ma intanto devi
scegliere, mentre nel caso precedente la scelta era banale poiché
un'implementazione inline di Hide era sicuramente preferibile a quella
inline di ShowWindow.
> Nella tua testa forse e in quella dei tuoi amichetti progettisti delle
> MFC, non secondo l'ultimo standard ISO/IEC del C++.
non è ovviamente lo standard a deprecare il tipo bool che esso stesso
prevede, anche perché non è lo standard a definirne le dimensioni.
> Evita di dire cazzate, per cortesia. BOOL è l'ennesima stronzata
> Microsoft fuori standard. Il C++ prevede il tipo bool che è benissimo
> mappabile, a livello implementativo del compilatore specifico, su ciò
> che più aggrada al processore e alla tua testolina.
l'uso di tale tipo è sconsigliato sui compilatori che ne definiscono la
dimensione a 1 byte quando le dimensioni di allineamento della piattaforma
ammontano a 4. è sconsigliato su molti compilatori per Win32, tra cui il
CL di Microsoft.
vecchie versioni di tale compilatore ponevano accortamente sizeof(bool) a
4, ma la cosa è cambiata suppongo per ragioni di compatibilità con altri
compilatori che invece già lo ponevano a 1. ciò ha reso necessario la
definizione di BOOL non come bool ma come int o qualcosa del genere. il
fatto che in Win32 si usi una nomenclatura ben precisa che astrae dal
linguaggio è un'ottima strategia che permette a Microsoft di risolvere
situazioni come questa, anche se tu la trovi l'"ennesima stronzata fuori
standard": se Win32 usasse bool Microsoft avrebbe avuto un bel problema
nel cambiare la dimensione di quel tipo.
mi immagino la scena di quando è stato fatto tale cambiamento: il classico
programmatore antimicrosoftiano che però è costretto ad usare VC++ per
lavoro sta facendo la sua cagata di programma che ritiene un capolavoro;
il programmatore è un anticonvenzionale e lotta per Linux e per le sue
idee, combatte idealmente il monopolio di "mamma M$" (scritto abbreviato e
col dollaro) scrivendo il commento "// #exclude <windows.h>" accanto
all'include ed usando giustappunto bool in quanto gli standard non di
Microsoft, come il C++, gli piacciono di più di quelli di Microsoft. il
programmatore si trasferisce, per necessità ma con disgusto, sulla
versione nuova fiammante di VC++ e nota il cambiamento nonché i problemi
di compatibilità con le sue DLL. prima si lamenta che Microsoft è la
solita stronza che non capisce un cazzo di retrocompatibilità, e poi ci da
giù pesantemente di Trova-Sostituisci. infine va da bravo a scusarsi col
cliente che un botto di DLL vanno sostituite. ma che goduria, ma come mi
sollazzano gli antimicrosoftiani. scusa la digressione.
> [cut su una parte circa la quale credo di essermi spiegato abbastanza in
> precedenza]
> quello fatto con le MFC nel caso specifico, è un evidente errore
> 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.
mrnt
> 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.
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.
Carlo Milanesi
> Andrea Laforgia ha scritto:
>
>> 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.
>
> 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.
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.
?manu*
> l'uso di tale tipo [bool] è sconsigliato sui compilatori che ne definiscono la
> dimensione a 1 byte quando le dimensioni di allineamento della piattaforma
> ammontano a 4. è sconsigliato su molti compilatori per Win32, tra cui il
> CL di Microsoft.
Mi sembra strano che ci siano dei compilatori che definiscono bool con
una dimensione diversa dall'int. Mi fa pensare che sia un errore di
progettazione del compilatore.
> mi immagino la scena di quando è stato fatto tale cambiamento: il classico
> programmatore antimicrosoftiano che però è costretto ad usare VC++ per
> lavoro sta facendo la sua cagata di programma che ritiene un capolavoro;
> il programmatore è un anticonvenzionale e lotta per Linux e per le sue
> idee, combatte idealmente il monopolio di "mamma M$" (scritto abbreviato e
> col dollaro) scrivendo il commento "// #exclude <windows.h>" accanto
> all'include ed usando giustappunto bool in quanto gli standard non di
> 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.
mrnt
> Mi sembra strano che ci siano dei compilatori che definiscono bool con
> una dimensione diversa dall'int. Mi fa pensare che sia un errore di
> progettazione del compilatore.
ma se lo fa pure il gcc... quello di Linux :) (appena controllato)
> 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.
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.
mrnt
> 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?
ragionamento impeccabile: una piccola parte di MFC si può tranquillamente
definire inutile. ma almeno non fa un soldo di danno.
tuttavia va precisato che non tutti quei famosi metodi vengono
implementati come inline e con la sola chiamata API: alcuni fanno anche
dei controlli e lanciano eccezioni, perciò una loro utilità ce l'hanno.
inoltre molti dei metodi inline non chiamano semplicemente l'API, ma
asseriscono per esempio con:
ASSERT(::IsWindow(this->m_hWnd));
e questo è molto utile e rappresenta già qualcosa di più che usare le
semplici API.
> Una libreria quindi dovrebbe fornire un incapsulamento che, nella
> 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.
?manu*
> ?manu* ha scritto:
>>Mi sembra strano che ci siano dei compilatori che definiscono bool con
>>una dimensione diversa dall'int. Mi fa pensare che sia un errore di
>>progettazione del compilatore.
>
> ma se lo fa pure il gcc... quello di Linux :) (appena controllato)
Ugh! Come non detto...
E.