Newsgroup: it.comp.lang.c++
Titolo: C++ (questo è l'ultimo, lo prometto!)

Sto per aggiungere al linguaggio C++ il supporto /nativo/ per la 
programmazione per contratto e per le unità di test (ispirato 
all'extreme programming).
Note:
1) Non verranno aggiunte né macro né librerie, ma proprio nuove parole 
chiave al linguaggio.
2) Il codice sarà compatibile con qualsiasi compilatore C++ standard (ma 
le nuove funzionalità saranno ignorate).
3) Per usufruire delle nuove funzionalità sarà necessario aggiungere un 
preprocessore (di cui rilascerò il codice sorgente) alla catena di 
compilazione.
  - Volete qualche altra funzionalità in particolare?
Ovviamente non deve stravolgere il C++, ma sopperire ad una vera 
mancanza oppure rendere più veloce la scrittura del codice sorgente.
Per es. potreste sentire la necessità della parola chiave "with". Per 
alcune funzionalità non potrò più rispettare il punto 2, però sarà 
sempre possibile produrre codice C++ corretto usando il preprocessore. 
Non sarà molto diverso dal codice che avreste scritto a mano.
Con questo voglio dire che potrete sempre tornare a programmare come 
prima e rinunciare alle nuove funzionalità.
Trovate un esempio di queste funzionalità qui:
http://www.digitalmars.com/d/dbc.html
http://www.digitalmars.com/d/cppdbc.html
Ovviamente la mia implementazione sarà diversa.
Kiuhnm

 Ovviamente la mia implementazione sarà diversa.
Ovviamente.

 Ovviamente.
Mi riferisco all'implementazione dell'idea della programmazione per 
contratto. Per es. potrei usare diverse parole chiave e fare scelte diverse.
Comunque ho dato un'occhiata al C# e ho visto che assomiglia 
pericolosamente al linguaggio D. Chi ha copiato chi?
In questi giorni ho letto molte cose riguardo Eiffel, Java, C#, ecc...
Li ho scartati tutti dal primo all'ultimo: gli autori di compilatori ed 
IDE fanno di continuo affermazioni che vengono sempre smentite dai test.
Ho trovato documenti molto interessanti che si concentrano sull'uso 
intensivo di tecniche RAII rendendo veramente improbabili leak di 
memoria e problemi correlati. L'unica differenza è che i linguaggi di 
alto livello ti costringono a usare certe funzionalità, mentre il C++ ha 
bisogno di disciplina. Non penso che il GC sia così indispensabile.
Inoltre mi sto documentando sulla libreria Boost che offre funzionalità 
veramente interessanti, specialmente per quanto riguarda il 
metaprogramming e il lambda calcolo.
Kiuhnm

 all'extreme programming).
Questo l'hai già visto?
 
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1613.pdf
Max

 In questi giorni ho letto molte cose riguardo Eiffel, Java, C#, ecc...
Per caso ti sei fatto qualche opinione anche su C++/CLI?
Max

 chiave al linguaggio.
È chiaramente questione di opinioni personali, ma io trovo pessimo
questo approccio.
Dato che, come ho letto in un altro tuo messaggio, ti stai documentando
molto in questi giorni ti consiglio, per comprendere il perché della mia
opinione, la lettura di questo:
http://www.eptacom.net
 -> Pubblicazioni -> C++ Language -> C++, Java,
C#: qualche considerazione 
link diretto: 
http://www.eptacom.net/pubblicazioni/pub_it/iso_12.html
vai al capitolo "Application design is language design".
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Per caso ti sei fatto qualche opinione anche su C++/CLI?
Non ci ho perso troppo tempo perché non voglio (e non posso) lavorare 
con codice managed, ma è parere di molti che il C++/CLI diventa utile 
solo quando si ha un sacco di codice già scritto in C++ e si vuole 
iniziare ad usare codice managed senza dover riscrivere tutto. In caso 
contrario, è consigliabile passare direttamente al C#.
Il problema è che il codice managed, non importa con qualche linguaggio 
venga generato, è sempre non nativo quindi interpretato e/o compilato 
just-in-time. Direi che il C++ resta ancora l'unica scelta per scrivere 
software di sistema (driver, ecc...) e codice efficiente (3d engines, 
ecc...).
Probabilmente l'unico modo è fare una prova. Su internet si legge di 
tutto...
Kiuhnm

Max M. ha scritto:

Penso che questo sia utile anche a te:
http://www.eptacom.net/pubblicazioni/pub_it/iso_12.html
Kiuhnm

 vai al capitolo "Application design is language design".
Era così interessante che ho letto tutta la pagina.
In questi giorni sto proprio studiando il libro "C++ in Action" che 
forse conosci.
In definitiva l'articolo dice:
a) attenzione a modificare il linguaggio (potrei citare "pensare 
globalmente, agire localmente" :-) );
b) se proprio si deve, aggiungere una funzionalità di basso livello che 
permetta di realizzare la funzionalità ad alto livello (e molte altre) 
tramite una libreria.
Però mettiti nei miei panni:
a) non ho molto tempo a mia disposizione;
b) il mio approccio funzionerà bene per le mie esigenze;
c) il codice sarà back-compatibile (quindi si compilerà anche in assenza 
del mio preprocessore);
d) le attuali librerie che implementano il DbC non sono soddisfacenti 
quindi non posso sperare di migliorare il lavoro di chi ha più 
esperienza di me (e comunque v. ancora punto a);
e) le parole chiave saranno ben definite e i controlli ben isolati dal 
resto del codice quindi, qualora dovessero aggiungere ufficialmente il 
supporto per il DbC, potrò scrivere senza fatica un software di conversione.
Kiuhnm

   
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1613.pdf
No, grazie per la segnalazione! Mi tuffo nella lettura e ti faccio sapere.
Kiuhnm

   
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1613.pdf
Meglio questo:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1866.html
Kiuhnm
P.S. Grande sito.

 questo approccio.
Ho letto la pubblicazione segnalatami da Max M. e, come puoi vedere, si 
è giunti alla conclusione che il DbC debba essere supportato 
direttamente dal linguaggio, quindi la mia soluzione del preprocessore è 
l'unica possibile, in attesa che (non penso prima del 2009) venga 
modificato il linguaggio.
L'autore della pubblicazione dice:
"My personal experience is (1) that many C++ programmers like the idea
of DbC, (2) that it is possible to get some of the benefits (but far 
from all)
without language support, and (3) that most C++ programmers abandon
DbC again because it is too inelegant, relies too much on macros, and is too
weak without language support."
Kiuhnm

 all'extreme programming).
Dal momento che pari essere un lettore piuttosto avido prima di
lanciarti nell'implementare strumenti ad hoc potrebbe valer la pena di
spulciare i messaggi che James Kanze scrive su comp.lang.c++.moderated.
E' un convinto sostenitore del Design by Contract ed anche una persona
molto esperta. Tempo addietro seguiva anche questo newsgroup, ma forse
si e' stufato... Purtroppo non ho specifici thread da proporti.
Potresti anche gettare un sassolino in c.l.c++.m., tipo "Che soluzioni
conoscete per fare DbC in C++?".
Ciao,
Nicola

 conoscete per fare DbC in C++?".
Gli esperti (in macro/metaprogramming) di tutto il mondo hanno già 
presentato varie librerie per C++ e nessuna è soddisfacente. Inoltre si 
è già arrivati alla terza revisione di una proposta per inserire il DbC 
direttamente nel linguaggio. Non credo proprio di trovare su un ng 
quello che cerco. L'autore sarebbe proprio bastardo a non aver 
rilasciato un tale gioiello al mondo. E poi perché dovrebbe dare la sua 
libreria proprio a me? :)
Comunque ho cercato con google-gruppi e non ho visto niente d'interessante.
Kiuhnm


Il motivo del mio suggerimento e' che, a giudicare dalle cose che
scrive, J.K. pratica il DbC in C++ *senza* librerie o strumenti
esterni.
Ciao,
Nicola

 esterni.
E quindi rinuncia all'eleganza e a tutte le comodità che derivano da un 
supporto diretto. Il DbC è un "syntactic sugar" quindi il preprocessore 
serve solo a renderlo elegante come se il supporto fosse nativo, non a 
renderlo possibile. E' sempre possibile.
Quando sarà aggiunto direttamente al linguaggio, sarà però anche un 
ottimo strumento di ottimizzazione. Se per es. hai un ciclo e tra le 
precondizioni è indicato che l'indice è un multiplo di 4, il compilatore 
potrà eseguire l'unrolling del ciclo senza aggiungere alcun controllo. I 
vantaggi sono molteplici.
Kiuhnm

 b) il mio approccio funzionerà bene per le mie esigenze;
[...]
Per carità, la mia voleva essere, anche se un po' brusca, una critica
costruttiva, cioé farti notare quello che secondo me (e non solo) è
l'approccio migliore, poi chiaramente ognuno ha le sue esigenze.


 direttamente dal linguaggio
Pescio nel suo articolo non dice di non estendere il linguaggio, ma di
farlo in un modo "furbo".


 farlo in un modo "furbo".
E cioè?
La proposta ufficiale che ti ho segnalato propone semplicemente di 
aggiungere le parole chiave necessarie, così come hanno fatto tutti gli 
altri linguaggi. Tra l'altro sto implementando il preprocessore seguendo 
proprio le direttive del documento ufficiale.
Kiuhnm

 Ovviamente la mia implementazione sarà diversa.
Guardate qua:
http://www.aechmea.de/html/german/Produkt01_e.htm
Questi hanno avuto la mia stessa idea, ma hanno pensato di farci dei 
soldi :)
Kiuhnm