Newsgroup: it.comp.lang.c++
Titolo: [OT] .NET, MS, e il C++ - dal Thread [Parere] - lungo

Spezzo il thread perche' ormai non ha piu' niente a che fare con
quello originale. Preciso che anche se ho messo il tag di Off Topic
non considero questo thread Off Topic piu' di tanto. 
Si sta parlando del futuro infondo, e nessuno sa se sara' un futuro
C++
++++
Bypasso la polemica su TCP e XML perche' mi rendo conto di avere fatto
il classico errore di confusione tra protocollo di formattazione e
procollo di comunicazione. Dal mio punto di vista non sono poi cosi'
diversi (tutt'altro), ma mi rendo di quale sia la prassi comune su
questo argomento.
++++
Mi sembrano che ci siano ottimi motivi perche'  C#, .NET e compagnia
bella, siano un sostanziale fiasco. Io prevedo una salutare uscita dai
circoli dei linguaggi di moda del C++. Che a quel punto potra'
diventare (dopo il Cobol) uno dei linguaggi piu' gettonati. 
1) Chi si fida della Microsoft? Mi sembra che la Cisco sia seconda
come capitalizzazone di borsa, dopo la MS. Non mi sembra che sia il
comune sentire che Cisco alteri gli standard per avere vantaggi
competitivi sugli avversari. Che lo faccia MS invece non e' una
novita'. Non voglio citare la storia delle licenze MFC e della morte
conseguente del Borland C++, ma potrei.
2) Standard e' un atteggiamento mentale. Vorrei ricordare la polemica
sul Kerberos di win2000. Applicare interpretazioni "esageratamente"
proprietarie pur di rendere i loro prodotti non standard anche in
presenza di "uno standard" e' piu' che possibile con MS. E' una norma.
3) La guerra persa dei linguaggi di script. E' vero, il C++ ha perso
la "guerra" per diventare il linguaggio "d'elezione" del WEB. Fino a
ieri pensavo che il vero problema fosse che nessuno avesse mai pensato
a sviluppare un C++ interpretato. Per me avrebbe contribuito ad
abbattere i costi di sviluppo. Poi e' arrivato il VC++ 6, non
rispettoso degli attuali standard e' vero, ma dotato del comodissimo
"edit and continue". Molto meglio del p-code quando funziona.
Diciamoci la verita', il C++ e' un linguaggio difficile. Come parte di
un problema piu' grande mi sono ritrovato (tra le varie cose) a
sviluppatore un gestore di vettori. Pensavo che lo avrei sviluppato in
5 minuti, bevendomi pure il caffe', invece ci ho messo 3 giorni. In
alcuni punti il codice ha assunto una espressivita' formale
assolutamente incredibile. Ma per uno che leggesse quel codice, che
non avesse molta esperienza di C++ e libreria standard, credo ci
vorrebbe almeno un mese per capire. Dovrebbe comprendere prima tutta
la gerarchia di classi, e solo allora, il codice sarebbe espressivo.
Forse, sono sempre nell'ipotesi di avere fatto un buon lavoro.
Non ho mai visto in vita mia un buon navigatore grafico di classi
(quello del VC++ lo cosidero' cosi' inutile che non lo guardo mai), e
il fatto che ne senta il bisogno non e' un buon segno del linguaggio.
Non solo il linguaggio e' difficile (accettabile), ma anche una
qualsiasi buona libreria scritta in C++ necessita' di tempi di
apprendimento alti.  Meno accettabile sotto certi punti di vista, ma
il C++ e' cosi'. L'espressivita' NON scontata a priori ha il suo
(alto) prezzo.
Un confronto tra la Cripto++ scritta in C++, e la CriptoLib scritta in
C, mi sembra interessante. Se il mio compito e' solo quella di
criptare uno schifosissimo file uso la libreria C. Meno roba da
includere, meno roba da capire.
La guerra "contro" gli script per il "predominio" del web era persa in
partenza. Il che non toglie che personalmente io non insulti il Perl
ogni volta che ne vedo un sorgente Perl, e che abbia giurato di non
imparare mai linguaggi cosi' "poco" espressivo. Ma un tempo mi stavano
antipatici i DB, mentre oggi li considero fondamentali, sopratutto in
fase di analisi, perche' ti obbligano a pensare senza false
"scorciatoie". Magari domani diventero' un sostenitore dei linguaggi
criptici.
4) La MS "sOpporta" il C++. Fatemi il piacere di non venirmi a
raccontare le frescaccie che racconta il reparto marketink MS. Nessuno
pretendeva che l'STL del VC++(allora si chiamava cosi') fosse da
subito esende da difetti. Certo che la MS con i suoi malefici service
pack poteva anche mettere lo switch magico che permettesse di usare un
libreria C++ meno bacata e' piu' standard. Se questo andava a scapito
della compatibilita' allora doveva essere lasciata allo sviluppatore
la decisione finale. Tenete conto che per il C++ il malefico switch
nel VC esiste, salvo scoprire che gli header dell SDK non permettono
di usarlo. Pero', se uno prova usare il povero e Open Source (e pure
gratis) Minimalist Window GNU scopre che si puo' essere standard se
solo si usano header un poco piu' corretti. Che la MS pigli per il
culo? Il sospetto e' forte.
5) Il supporto di MSDN allla libreria C++ e' nullo. Stiamo parlando di
un prodotto che vende milioni di copie, e che e' obsoleto dopo 4 mesi.
Il supporto sul C++ e' patetico. Come pensare che non sia voluto. Di
$$$ ne guadagnano con MSDN, e non credo di essere l'unico a sentire il
bisogno di buona documentazione. Alla fine ho scoperto i libri della
McGraw Hill, guarda caso scritti dai componenti dello standard. Ancora
oggi pero' non ho trovato un libro che contenga una trattazione
"decente" degli stream, o con una trattazione anche indecente dei
locale.
Gli stream C++ non mi piacciono un gran che (preferisco la printf alla
cout) pero' sento molto la mancanza di buona documentazione sulla
localizzazione. 
++++
Per essere OT sono stato anche troppo lungo.
-- 
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

documentazione sulla localizzazione. 
Anche io trovo la formattazione printf estremamente piu'
leggibile. Secondo me ci si sarebbe potuti sforzare di piu'
verso l'usabilita' scendendo a qualche compromesso...
Oltrettutto gli stream C++ sono una di quelle parti in cui
lo standard avrebbe dovuto dire secondo me molte meno cose...
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

lo standard avrebbe dovuto dire secondo me molte meno cose...
Per me gli stream C++ sono il retaggio di un esibizionismo inutile.
E tra l'altro non li trovo neppure fatti tanto bene. Tenendo conto che
si parla della libreria standard per me si fallirono a capire bene gli
obiettivi di semplicita' e concretezza.
Ammiro molto invece container e affini.
Un altro errore (per me) della libreria standard e' il container
deque, esageratamente specifico per consideralo buono da metterlo
nello standard. 
Mi sarebbe piaciuto tanto piuttosto un gestore di espressioni regolari
nella libreria. Ce ne e' una free (ancora una volta inutilmente
complicata), ma era meglio qualcosa di "standard".
E per dirla tutta la strtok ereditata dal C e' una pessima funzione.


 localizzazione.
Il riferimento "standard" e' "Standard C++ IOStreams and Locales" di
Angelika Langer & Klaus Kreft. Qualcosa dice anche Nico Josuttis in "The
C++ Standard Library".
Ciao,
Nicola

 lo standard avrebbe dovuto dire secondo me molte meno cose...
Di meno su certi aspetti e di piu' su altri. E' un po' ridicolo fingere
di supportare sistemi che potrebbero non avere file system e poi
realizzare una libreria di I/O cosi' complessa.
E' un po' come fingere che compilatore/linker facciano una singola
passata e poi aspettarsi che la One Definition Rule sia garantita per le
specializzazioni dei template...
Ciao,
Nicola

 complicata), ma era meglio qualcosa di "standard".
L'obbiettivo di Boost e' raccogliere librerie che possano essere
proposte al comitato per la prossima edizione dello standard. E poiche'
tra i suoi promotori ci sono parecchi membri del comitato stesso, mi
sembrano una scommessa accettabile.
 
Ciao,
Nicola

E per dirla tutta la strtok ereditata dal C e' una pessima funzione.
E' una delle poche funzioni C che non ho mai usato
in vita mia :))))


Come dicevo ad Andrea, su 
www.boost.org
 c'e' una libreria per questo.
Che codice richiederebbe fare quello di cui parlavo ?


 Che codice richiederebbe fare quello di cui parlavo ?
Dicevo solo che Boost contiene una libreria per le espressioni regolari.
Ciao,
Nicola

 e' abbastanza "povero".
Soprattutto, a differenza sia delle classi C++ che delle tabelle di un
DB, non emerge granche' una struttura, proprio per l'omogeneita' tra
strutture dati e programmi. Pero' per scrivere programmi che manipolano
programmi...
 
Ciao,
Nicola

Sfrutto questo thread per riprendere alcune considerazioni sul confronto
tra C++ e C#/Java (per la gioia di Andrea Ferro :-).
- La virtual machine
Java nasce su una virtual machine nell'idea che sarebbe diventato molto
comune collegarsi ad un sito Web e scaricare/eseguire applet anche
complesse per svolgere la propria attivita'. In realta' questo non e'
successo e l'utilizzo piu' comune di Java e' sotto forma di servlet o
tutt'al piu' di Enterprise Java Bean. L'esigenza di trasportare
fisicamente codice eseguibile tra macchine eterogenee e' molto limitata.
A che serve quindi la Virtual Machine? Non sarebbe sufficiente
specificare con sufficiente dettaglio un'API (ad es. int = 32 bit, ma
non necessariamente LSB o MSB) cross piattaforma ed un'ABI
(name-mangling, object model, ecc.) per ogni piattaforma?
Perche' forzare la convergenza ad una piattaforma astratta rinunciando a
sfruttare appieno i processori sottostanti, quando quello che serve e'
poter compilare il proprio codice ovunque e poterlo linkare col prodotto
di qualsiasi compilatore?
- Espressivita' contro Semplicita'
Sia Java che C# nascono coll'intento di eliminare i costrutti del C++
coi quali e' facile "farsi del male". Peccato che cosi' facendo si siano
persi strumenti particolarmente validi, primi fra tutti i distruttori e
l'allocazione di variabili complesse sullo stack. Si e' cosi' eliminato
un problema noto, ovvero i puntatori, per il quale esistevano gia' molte
tecniche di riduzione del rischio (deallocare nel distruttore, usare
smart pointer, usare Purify e strumenti simili, ecc.) per introdurne
altri piu' sottili.
Senza contare che a mio avviso il problema del costo del software si
gioca sulla qualita' del disegno e su questo niente impedisce al
programmatore C#/Java di fare altrettante porcherie di quello C++; anzi,
forse quest'ultimo e' piu' portato a fare attenzione, perche' sa di
viaggiare senza paracadute.
Tra l'altro aver eliminato i template impone a chi programma in C#/Java
di scrivere molto piu' codice oppure di ritardare a runtime scelte che
si possono compiere a compile time, incrementando il rischio di
abbassare la qualita' del software e di rompere codice funzionante.
Bisogna riconoscere che Java ha almeno una funzionalita' in piu' del
C++, ovvero un meccanismo di RTTI serio. E' vero pero' che per molti
problemi pratici si riesce a sopperire con qualche settimana di lavoro.
- Un unico fornitore o molti
Un altro aspetto delicato, che attualmente e' vero per Java e che mi
aspetto varra' anche per C#, e' che quasi tutte le librerie provengono
da un unico fornitore. Il fatto che siano disponibili gratuitamente e'
un grosso aiuto per chi sviluppa, ma risulta improbabile che qualcuno
produca implementazioni alternative di librerie mediocri. Ad esempio ho
sentito notevoli critiche nei confronti di Swing; chi mai si lancera' a
realizzare un altra GUI per Java? E con quale probabilita' di successo,
indipendentemente dalla qualita' tecnica?
E' vero che lo standard C++ non contiene librerie che risolvono problemi
"applicativi", ma esistono parecchie librerie sia commerciali che Open
Source: si puo' scegliere.
Anche a livello di architettura generale si sta imponendo per Java un'
unica scelta, quella degli EJB con application server. Ma risolve
davvero tutti i problemi? Quasi non oso porre una domanda accessoria:
siamo davvero convinti che i browser siano un'interfaccia pratica per
*qualsiasi* tipo di applicazione?
Ciao,
Nicola

Per il resto c'e' Python :-)
Conoscerlo :-(


costruiti attorno alle regexp.
Sicuro.


realizzare una libreria di I/O cosi' complessa.
Non si parte dal presupposto che esistano i thread, ma si parte dal
presupposto che esista un F.S. Anzi si parte dal presupposto che
esista una "console" su cui sbattere il cout e cerr, e una "tastiera"
da cui prendere eventuali input con cin.
Effettivamente la scelta e' molto arbitraria.
Scommetto che la macchinetta delle merendine aziendale ha dentro di se
un sistema che e' programmato, ma di certo non ci sono F.S. o vere
console.
Anche se ho provato a scrivere "Hello Word" con le patatine al mais
(che mi piacciono tanto n.d.p.)


 da cui prendere eventuali input con cin.
In realta' lo standard C++ non prevede nemmeno l'esistenza di console e
tastiera...
 
Ciao,
Nicola

 Conoscerlo :-(
Non ci vuole molto, per cominciare basta leggersi il tutorial
disponibile su 
www.python.org
; se poi si riuscisse ad aprire il
newsgroup in italiano, si potrebbe facilmente ottenere il contributo di
Alex Martelli. E non dico altro :-)
Ciao,
Nicola

}
Alcuni tipi di problemi si modellizzano bene cosi' (ad esempio secondo
me molti gestionali ricadono bene in questo schema). In altri casi
ci sono a mio parere approcci molto migliori.
Anzi... ora che vedo il "private: Data m_d" non capisco piu' bene
cosa intendi... :/
Io per i gestionali intendevo classi di mantenimento informazione
sostanzialemente "stupide" (a parte i controlli di integrita'
referenziale e poco piu') e di manipolatori esterni che agiscono
su queste classi.


 del software" :) ... secondo me hai comprato i libri sbagliati
Io del termine sono abbastanza convinto, salvo che il termine da solo
non implica che le cose che sono scritte nei libri siano applicabili, lo
siano sempre, lo siano comunque o lo siano dovunque.
 
Ciao,
Nicola


Se non sbaglio ti sei fatto un paio di giorni di influenza, recentemente. Due
giorni full time. Più o meno quello che ti servirebbe per studiare Python (non
per diventare esperto, ma per capire il linguaggio e la relativa filosofia).
Poi naturalmente viene la parte difficile: studiarsi la libreria. Ma li non ti
so dire nulla (almeno non fino alla MIA prossima influenza ;-)
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 Alex Martelli. E non dico altro :-)
Infatti. Ma dipende dal modo in cui tu impari un linguaggio. Ci sono persone che
si trovano meglio con un tutorial passo-passo ricco di esempi e di esercizi. Io
mi trovo meglio con una descrizione tecnica. Non fino al punto da dire che avrei
potuto imparare il C++ leggendo lo standard, ma certamente il miglior testo C++
per uno come me prima dello standard era quello di Stroustrup-Ellis che funse
"starting document" del comitato. Qualcuno ricorda il vecchissimo compilatore
microsoft C (credo versione 5.qualche cosa) sotto DOS? Ricordate il "language
reference"? Ecco: con quello ho imparato il C.
Tutto questo per dire che mi sono pentito di aver letto il tutorial (peraltro
ottimo) e a-posteriori sarebbe stato per me molto più efficiente leggere
direttamente la "specifica" del linguaggio (stesso sito).
E lo stesso vale per Java. Sto leggendo la "specifica" tratta dal sito sun e mi
pento di aver "perso" tempo leggendomi "thinking in java". Il che non toglie
nulla al valore dei testi "tutorial". Dico solo che io mi trovo meglio con una
definizione "formale" che con una "romanzata".
Non so se mi spiego.
(eccezione: la sintassi di Perl!!!!!!!!!!!)


 *qualsiasi* tipo di applicazione?
Non qualsiasi. Ma da quando ho sentito parlare di applicazioni CAD/CAM che giran
o via internet con i browser ....




Ne discutevo in mensa con un collega. Gli dicevo che il concetto di
cin e cout e' esageratamente forte. Che senso hanno quei due oggetti
su una macchina del caffe' (per il resto magari programmata in C++)?
Lui controbatteva che potresti considerare un cout che non fa nulla,
ma poi io gli fatto notare che il tuo programma non avesse effetti,
non riusciresti nemmeno a distinguere se va o e' fermo. Per
definizione un programma deve avere effetti "riscontrabili".
In realta' tu puoi avere un intero sistema il cui concetto di stream
e' fuori luogo, e quindi in cui una fetta della libreria standard
risulta priva di senso. In quest'ottica potevano anche prevedere il
concetto di thread a livello di linguaggio.
++++
Questo vale anche per il C. Che cosa e' un FILE sulla macchina del
caffe'? Non penso proprio che ci sia un F.S. li dentro. Al limite ci
saranno i miei soldi, ma e' un'altra storia.


difetto nel codice object oriented come nel codice procedurale.
Un momento !
Se io nella libreria che voglio studiare vedo
class A: public B
io gia' non so quali sono le funzioni pubbliche di A. Devo andare a
guardarmi B, e magari alcune sono sovrascritte e cambiano di
"significato". 
In una libreria che faccia uso neanche tanto massicciamente della
derivazione, e' facile arrivare a non capirci niente. In C non esiste
niente di simile.
O c'e' (e non c'e') un bel tool che mi fa vedere in modo grafico le
"relazioni" tra le classi (derivazione, contenimento, uso
estemporaneo), e la "vera" interfaccia di una classe, oppure non c'e'
alternativa a studiare l'intera libreria di sorgenti prima di potere
capire qualche dettaglio.
Per me fare librerie C++ "potenti" e leggibili e' difficilissimo.
++++
Tutto cio' mi ricorda i functional object del C++. A volte (spesso)
tiro un accidenti agli help (uso quello SGI, MSDN, e quando non li
fanno fuori (cioe' mai) i libri bibbia), e mi faccio la mia classe usa
e getta.
Se devo applicare 3 functional object in serie per ottenere cio' che
voglio, di solito smetto di capire cosa fa quella riga di codice. Creo
una classe nuova e via, anche se nella mia ottica vuol dire
"complicare" inutilmente il progetto complessivo.


};
Nell'ultimo caso incominci a parlare di soluzione, il che in fase di
analisi e' per me deleterio.
La fusione di due ipotetiche classi A B C in D E ha dei significati
"impliciti" a cui fai fatica a sottrarti. Se invece penso in tabelle,
io "vedo" i dati come dati puri. Al massimo tendo ad organizzarli per
significato, mentre con le classi non posso fare a meno di
organizzarli per uso.
Il fatto e' che sono troppo avanti !!
++++
Ho bisogno di mantenermi il piu' possibile tutte le strade aperte.
Spesso cambio le interfaccie "fondamentali" anche dopo l'analisi e il
design. A volte per motivi "pratici", ma altri per motivi filosofici a
cui sono giunto scrivendo il codice reale.
Con le classi, o UML, mi sembra di "decidere" ad uno stadio troppo
prematuro.


cosa intendi... :/
Uso la sintassi polacca per le variabili dichiarate dentro le funzioni
m_xx  per le varibili di una classe
g_xx per le variabili globali
l_xx per le variabili dichiarate dentro un namespace anonimo.
E' una convenzione mia in cui mi trovo bene


E' una convenzione mia in cui mi trovo bene
Premetto che a me sembra una convenzione assurda (ma c'e' gente
che considera sensata anche la notazione ungherese... contenti
loro contenti tutti). Pero' io intendevo che non capisco l'avere
una classe di soli dati e un'altra classe che ne incapsula una
istanza...
Quella che personalmente ho trovato una soluzione sensata in alcuni
contesti (ad esempio i gestionali) e' quella di avere dati "stupidi"
che sanno badare solo alla loro integrita' e avere delle operazioni
su questi dati fatte "dall'esterno" e non metodi della classe.


giorni full time. Più o meno quello che ti servirebbe per studiare Python
Ho preferito leggermi dei Manga che avevo comprato, e che non avevo
ancora letto per i solito problema di tornare a casa dal lavoro
"mentalmente" distrutto.
Poi avevo deciso di leggere per questioni di lavoro un libro sull' IA,
ma non sono sopravissuto al sonno mortale.


istanza...
Trovo che l' <imposizione> del OO di avere dati e procedure che li
manipolino strettamente accoppiati non sia piu' di mio interesse.
Sempre di piu' mi ritrovo ad avere dati da una parte, e oggetti che li
manipolano.
Quello che non hai capito nel mio ragionamento e' di solito le <mie>
classi manipolano una parte dei dati. Che questi insiemi di dati non
sono ad intersezione nulla. Che i raggruppamenti dei dati variano nel
tempo di <vita> del programma.
Qualcosa del genere
Fase 1 --> il dato A va insieme al dato B ed e' usato dalla classe X
Fase 2 --> il dato A va insieme al dato C ed e' usato dalla classe Y
++++
L'architettura di solito e' complicata, ma non necessariamente lo e'
l'uso del baraccone stesso. D'altra parte non e' che con il classico
forte annidamento gerarchico le cose siano poi cosi' semplici.


 girano via internet con i browser ....
A naso o ci sono dietro esigenze specifiche o e' una fesseria.
Ciao,
Nicola

 prematuro.
No, se non dai per scontato che quello che scrivi in UML "deve" gia'
essere codice definitivo.
Ciao,
Nicola

 su una macchina del caffe' (per il resto magari programmata in C++)?
In effetti lo standard prevede la differenza tra implementazione
"hosted", ovvero basata su un sistema operativo tradizionale, o
"freestanding", dove il supporto runtime puo' essere molto piu'
limitato.
Ciao,
Nicola

 "complicare" inutilmente il progetto complessivo.
E' piu' che altro una questione di farci l'abitudine, anche se devo
ammettere che quando ficco il naso nel codice delle librerie Boost tendo
a spaventarmi :-)
Ciao,
Nicola

 affronta male.
Esatto. E in questo il fatto che le librerie Java siano gratuite mentre quelle
.NET non lo siano e' un punto a vantaggio di .NET (senza che questo debba essere
una critica a Open Source: e' solo una considerazione commerciale).


 una critica a Open Source: e' solo una considerazione commerciale).
In presenza di un punto di riferimento troppo forte, come Sun ed i suoi
partner per Java e Microsoft per .NET, sono d'accordo con te.
Ciao,
Nicola


:-D Questa non č niente male!

 una tecnica basilare.
Prima che Dijkstra scrivesse quello che probabilmente e' l'articolo com maggior
risonanza nella storia del SW Development, indovina cosa era una tecnica
basilare! Lo so che in C++ il distruttore e' usato per questo motivo. Ma mi
domando se la tecnica e' corretta. Nota che il distruttore non esiste in
moltissimi linguaggi (incluso smalltalk che e' certamente mainstream per sistemi
grossi) e che a livello di design le funzionalità di cleanup (salvo quelle di
cleanup della memoria) dovrebbero essere previste esplicitamente
indipendentemente dal fatto che vengano eseguite o meno dal distruttore.
Ci devo pensare.


limitato.
ma allora perchč non si č deciso di standardizzare alcuni tra gli
elementi piů importanti ad oggi, come GUI, thread, socket? Si sarebbe
potuto fare la stessa distinzione, e il codice C++ sarebbe portabile
in una percentuale molto vicina al 100%
Anto
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

 in una percentuale molto vicina al 100%
Perche' non sono cose che ci sono su alcuni sistemi e non su altri e quindi si
può semplicemente dire che sono opzionali ma se ci sono vanno fatte in un dato
modo. Sono funzionalità complesse e che sono fatte in modo diverso sui vari
sistemi. Abbastanza diverso da rendere difficile realizzarle in maniera
portabile e nello stesso tempo "a basso livello" come per il resto del C++.


 in una percentuale molto vicina al 100%
Per prima cosa perche' non sono problemi di linguaggio, ma di ambiente
operativo; in secondo luogo perche' per nessuna di queste esiste uno
standard di fatto ed il comitato non avrebbe avuto modo ne di
individuare criteri accettabili per una scelta particolare, ne di
imporre la scelta compiuta. Gia' non si riesce ad avere compilatori
conformi cosi'...
Quello che pero' potrebbero cercare di fare e' specificare un
comportamento minimo garantito in caso di thread, per quanto non credo
sia facile.
Ciao,
Nicola

basilare! Lo so che in C++ il distruttore e' usato per questo motivo. Ma mi
a cosa ti riferisci?
grazie Anto


conformi cosi'...
però anche nel caso della console (ad esempio) non si scende nel
dettaglio ma si garantiscono un minimo di funzionalità: non possiamo
cancellare lo schermo e modificare i colori, ma possiamo scrivere
sullo schermo: perchè non applicare lo stesso criterio per la GUI?
Magari non potremo scrivere complesse applicazioni MDI ma un minimo di
funzionalità potrebbero essere garantite: che so, una finestra, un
bottone di comando, label, textbox e poche altre: poi quelle
specifiche del O.S. potrebbero essere "incastrate" nello schema dello
standard. Su thread e socket non mi pronuncio in quanto non ho molta
esperienza (diciamo che non ne ho e basta ;-)


dovrebbe essere chiamata prima di arrivare al distruttore?
Dipende da come l'hai aperto.
Esiste un Open? Allora a logica deve esistere un Close.
Fai tutto nel costruttore? Allora usa il distruttore.
Dal punto di vista filosofico non mi piace l'Open. Poi per la mia
attuale classe madre di tutti i progetti (accesso ai DB) avevo questo
problema banale. La connessione puo' fallire, e io non volevo
obbligare l'utilizzatore della libreria ad usare le eccezioni. 
Cosi' sono passato alla coppia Open/Close. Con chiusura di sicurezza
nel distruttore. Quello che noto e' che le persone non si dimenticano
di usare il Close, e che quindi ci potrei mettere un bell'assert nel
distruttore se l'oggetto non e' chiuso.
Purtroppo se lo facessi avrei dei problemi con le persone che
utilizzano le eccezioni. Non potresti mettere cioe' nello stack
l'oggetto, ed essere certo che se succede qualcosa le risorse e la
connessione sara' chiusa.


 connessione sara' chiusa.
Quasi vero. Infatti secondo questa filosofia anche chi usa le eccezioni dovrebbe
assicurarsi di scrivere la close nel posto giusto. Che poi in C++ questo sia
particolarmente macchinoso e' un problema del C++, non della filosofia. In Java
e Python, per esempio, la cosa sarebbe semplice.


 grazie Anto
Edsger W. Dijkstra, "Go To Statement Considered Harmful", Communications of the
ACM, Vol. 11, No. 3, March 1968, pp. 147-148.
L'origine di quello che oramai e' divenuto un pensiero filosofico!


 indipendentemente dal fatto che vengano eseguite o meno dal distruttore.
Gia' pero' oggi le conclusioni di Dijkstra non le mette piu' in dubbio
nessuno: stiamo parlando di un idioma che il C++ mette a disposizione da
sempre, ovvero dell'esperienza congiunta di migliaia di sviluppatori in
piu' di 15 anni.
Ciao,
Nicola

 piu' di 15 anni.
Mica vero. Mai sentito parlare di "'Go To Statement Considered Harmful'
considered harmfull" o articoli simili?
Persino in questo NG ci sono state discussioni in proposito.


Le librerie sono pero' piu' testate del tuo codice.
Il tempo di comprensione e' un fattore che non va sottovalutato.
std::transform (
	container.begin(),
	container.end(),
	std::ostream_iterator<std::string>(std::cout, "\n"), 
	std::mem_funct_ref(&oggetto_contenuto::dammi_stringa) );
non e' codice intuitivo da scrivere o da capire.
Quando scrivo codice non devo dimostrare di essere un fenomeno, ma
pensare che dovra' andare in produzione, ed essere mantenuto da
persone probabilmente meno attrezzate di me.
P.S.
perche' poi <consigliare> "\n" invece di std::endl?


essere codice definitivo.
Non riesco a pensare agli schemi UML, e a non pensare alla soluzione
archietturale finale. Questo perche' l'archietettura del sistema e' il
sempre il primo dei miei problemi.
Mi trovo meglio con degli scarabocchi sul retro di pagine A4 stampate
e riciclate, che con strumenti <seri>.


 perche' poi <consigliare> "\n" invece di std::endl?
Curiosa domanda. Non sapevo che qualcuno lo consigliasse e non ne capisco il
motivo.
Da parte mia, comunque, scrivo "\n" a non scrivo std::endl. Credo che sia per
abitudine. Per risparmio di "battute". Perche' non mi ricordo mai se si scrive
endl, eol, lend, eline o che altro. O perche' trovo che
f << "Ciao" << std::endl;
sia assurdo in confronto a
f << "Ciao\n";


 The instructions said to use Windows 98 or better - so I installed FreeBSD.
Si. Salvo che, opinione assolutamente personale, io trovo che:
f << "Ciao" << std::endl;
sia meno "leggibile" di
f << "Ciao\n";
f.flush();
Ovviamente e' una opinione. Uso << solo per "materiale" che finisce fisicamente
sullo stream. Comandi di gestione dello stream stesso, come la definizione del
numero di decimali da usare nel "rendering" di un valore floating point o lo
switch da decimale a esadecimale o il flush, sono, per me, operazioni
dell'oggetto stream, non dati da mandare sullo stream. Alla stessa stregua di
open e close.
Se ci fossero i relativi "inserter" scriveresti qualche cosa come:
ofstream f;
f << std::open("message.txt") << "Hallo, world!" << std::endl << std::close();


 Andrea Ferro
E' vero; pero' ci sono controindicazioni.  Ad esempio se stai


 e Python, per esempio, la cosa sarebbe semplice.
Questa non l'ho capita. A me pare vero il contrario.
Ciao,
Nicola

 esperienza (diciamo che non ne ho e basta ;-)
Non e' cosi' semplice. In generale le GUI si basano su un meccanismo ad eventi.
Ma non funzionano tutte nella stessa maniera. Questo meccanismo e' il contrario
di quello intrinseco al C++. Ovvero in generale in una GUI il flusso di
controllo resta al sistema che chiama il tuo codice per rispondere a degli
eventi. In C++ invece sei tu che hai il controllo e chiami il sistema. Se C++
deve essere un linguaggio a basso livello adatto a scrivere il sistema in se,
non può imporre la presenza del sistema stesso. Nota che in C++ e nelle sue
librerie non c'e' nulla che imponga la presenza di un OS ma solo la presenza di
un non meglio specificato environment che potrebbe essere tutto HW. L'unica
eccezione e' la freestanding per la quale l'environment non prevede il concetto
di stream (chiamarli file non e' corretto: potrebbero essere tastiere, socket o
altro).
Nota che persino il modello di interazione con la GUI e' libero. Puo' essere
document/view come nel caso delle MFC, puo' essere MVC come avviene in smalltalk
o può essere qualunque altra cosa.
Nota che C++ non prevede in realtà la "console" o "i file" o alre cose simili.
Semplicemente il concetto di stream come meccanismo di IO. Uno stream potrebbe
essere qualunque cosa. Non per nulla puo' essere anche una stringa!


 considered harmfull" o articoli simili?
L'errore e' il fanatismo in se', non cio' che ne e' oggetto.
Ciao,
Nicola

 wrote in message
news:3AB20F94...@divalsim.it...

Partiamo dal presupposto che il costruttore non esegue la "open" e che il
distruttore non esegue la "close". La sequenza e' quindi: costruzione, open,
close, distruzione. Non discutiamo ora del fatto che questa sia la filosofia
giusta o quella sbagliata. Parliamo solo del supporto che il linguaggio da a
tale filosofia.
L'unico vero problema, come diceva il nostro Papero preferito, e' il caso di una
eccezione in codice temporalmente eseguito fra la open e la close. In tal caso
come posso assicurarmi che la close venga fatta come di dovere (e prima del
distruttore)?
In C++ la filosofia e': ti assicuro la chiamata al distruttore, tu metti il
codice li e sei a posto.
In Java e Python la filosofia e': il distruttore non c'e' e se c'e' (finalize)
lo chiamo io quando decido io e non ti assicuro neppure che sia chiamato prima
della fine del processo. Ti do, in cambio, un meccanismo per assicurarti di
poter eseguire il tuo "close" in qualunque situazione (finally).
Se la filosofia di base e' quella in premessa (ovvero che costruttore e
distruttore non si devono occupare di open e close) allora Java e Python sono in
grado di supportarla meglio, mentre C++ praticamente ti obbliga a usare il
distruttore per eseguire la close.
Ripeto: gli argomenti a favore o contro la filosofia suddetta li devo ancora
"ragionare", per cui non ne parlo. Sto ora solo analizzando il supporto dei vari
linguaggi a una o all'altra filosofia.


ok, ancora una volta hai vinto tu ;-)


ACM, Vol. 11, No. 3, March 1968, pp. 147-148.
ehm... forse pretendo troppo, ma considerando che non so se sarei in
grado di leggere un articolo così tosto (come credo che sia) in
inglese e che non saprei dove prenderlo: se non siamo troppo OT mi
puoi fare un rapido riassunto? Senza scendere troppo nei dettagli, ma
da averne una idea generale, visto che ne avevo già sentito parlare
altre volte.
anto


come posso assicurarmi che la close venga fatta come di dovere 
Veramente ci sono altri casi "critici" in cui le due soluzioni non
sono equivalenti. Per esempio nel mio "linguaggio" ho degli oggetti
che sono "visti" dalla parte <core> della libreria. Uno strato
superiore della libreria invece vede sempre e solo dei wrapper agli
oggetti "reali" che fanno le cose. I wrapper hanno dei riferimenti
agli oggetti "reali" al loro interno.
Se avessi delle close chi mai le richiamerebbe? Nella mia architettura
dovrei metterei dei close nei wrapper con il rischio di chiamate
doppie. Io gioco sul fatto che la distruzione di un wrapper non mi
causa la chiamata al distruttore all'oggetto contenuto, per il
semplice motivo che in esso c'e' semplicemente un reference. Il
distruttore agli oggettoni "reali" viene chiamato in automatico alla
distruzione dell'applicazione.
Senza puntatori e distruttori una architettura simile sarebbe stata
impossibile, e a me non piace avere limitazioni di scelta. 


particolarmente macchinoso e' un problema del C++, non della filosofia. 
Che sia macchinoso e' assolutamente falso.
Con qualcosa del tipo
template <typename T>
class SafeException 
{
public:
	typedef void (T::*funct)() ;
	SafeException (const T& t, funct f): m_funct(funct), m_t(&t) {}
	~SafeException (funct f) {m_t.m_funct();}
private:
	funct		m_funct;
	const T&	m_t;
};
riesci praticamente a spostare nel distruttore una close.
class Pippo
{
	Open(...);
	Close();
};
int main (void)
{
	try
	{
		Pippo pippo;
		SafeException pippo_safe(pippo, pippo::Close);
		//codice
	}
	catch(...)
	{


 Master C++: 4.6, higher than 98% of all previous test takers.
Qui hai vinto tu :-)


 altre volte.
Se non sbaglio l'inglese lo mastichi abbastanza da tradurre "Thinking in C++".
Quindi dovresti poter digerire senza problemi anche l'articolo. Anche se e' un
classico non e' poi cosi' tosto come puoi pensare. Provaci:
http://www.acm.org/classics/oct95/
--


Qui hai vinto tu :-)
solo sulla carta, non in pratica...
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688