Newsgroup: it.comp.lang.c++
Titolo: "Modern C++ Design", di A. Alexandrescu

Raccolgo un invito se non sbaglio di Andrea Ferro, nella speranza che
altri seguano.
Andrei Alexandrescu, "Modern C++ Design", Addison Wesley, 2001, ISBN
0-201-70431-5
Questo libro e' gia' diventato uno tra i piu' significativi testi sul
C++ usciti negli ultimi tempi, come dimostrano tra l'altro i numerosi
messaggi che lo riguardano inviati a comp.lang.c++.moderated .
L'argomento del libro e' l'utilizzo avanzato di template per
implementare idiomi e pattern generici. La prima parte presenta alcune
tecniche "di base", come le classi policy, alcune espressioni
condizionali a compile time o le liste di tipi,  utilizzate poi nel
resto del libro.
La seconda parte illustra invece alcuni componenti altamente generici,
come funtori, smart pointer e multimetodi. Sono presenti anche
implementazioni di alcuni pattern tratti da "Design Patterns", come
Singleton, Abstract Factory o Visitor.
Il libro e' certamente di livello avanzato e mantiene un passo piuttosto
rapido, ma lo stile e' decisamente comprensibile: Andrei, che e' un
rumeno trapiantato negli USA solo da pochi anni, scrive in inglese
meglio di molti autori di madre lingua.
L'aspetto piu' positivo e' a mio avviso l'approccio estremamente
pragmatico: il libro presenta soluzioni concrete ed "usabili" a problemi
reali, rendendo avvicinabili a molti tecniche che solo qualche mese fa
sarebbero apparse inaccessibili se non ai guru piu' esperti. Gli aspetti
negativi sono indubbiamente l'alto numero di errori di stampa presenti
nel libro (la mia e' la prima ristampa) e forse la non assoluta
stabilita' della libreria che lo accompagna (disponibile via web).
In ogni caso un libro dal quale non si puo' prescindere, in particolare
per chi e' ancora perplesso riguardo ai template (vero, Andrea G.? :-)
Ciao,
Nicola

 per chi e' ancora perplesso riguardo ai template (vero, Andrea G.? :-)
;-P
--
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

per chi e' ancora perplesso riguardo ai template (vero, Andrea G.? :-)
Riguardo ai template io sono dubbioso sotto tre punti di vista:
 1) Attualmente la tecnologia dei compilatori e' ancora
    abbastanza malferma su questo punto... Riuscire a
    scrivere codice non banale che usa template e portarlo
    su diversi compilatori non e' una cretinata. Io provo
    solamente con tre (VC++, g++ e BCC55) e le sorprese
    sono sempre dietro l'angolo.
    Oltre alla reale uniformita' di interpretazione (a cui
    non siamo affatto ancora giunti) resta anche il problema
    della diagnostica. A oggi quando capita un errore nei
    template i compilatori cominciano a vomitare schermate
    di improperi quasi senza senso.
 2) I template sono delle macro. Belle quanto si vuole. Ma
    sono sempre macro. Io trovo che per scrivere generatori
    di codice complessi sia meglio agire dall'esterno...
    io ad esempio scrivo spesso in PERL dei generatori di
    codice C++: mi trovo bene e riesco a fare cose che
    con i template sono (credo) improponibili (incluso
    ad esempio iterare su tutti i membri di una classe).
    Per le cose semplici invece vanno benissimo.
 3) Ogni tanto vedo esempi che fanno semplicemente
    accaponare la pelle. Vedi uso dei template per
    introdurre le costanti binarie che ho letto in
    un articolo di Pescio (poche volte ho visto
    paciocchi piu' artificiosi e brutti di quello).
    Chiaro che se si vuole scherzare si scherza...
    spero che quello fosse uno scherzo.
    A volte ho l'impressione che di fronte ai limiti
    imposti dalla poverta' descrittiva disponibile nel
    linguaggio di definizione dei template ci si
    cominci ad arrampicare sugli specchi con una serie
    impressionante di "trucchetti" che annichiliscono
    ogni residuo di dignita' di programmazione.
    Questo non e' ovviamente vero in generale... pero'
    in alcuni casi secondo me si vede.
    Ricordo di aver visto anni fa colleghi scrivere le
    cose piu' incredibili usando solo il linguaggio dei
    file .BAT e i comandi standard del DOS. Cose come un
    test automatico sulla disponibilita' di spazio libero
    sufficiente su disco in un .BAT di installazione.
    Il contesto e' diverso... ma secondo me le analogie
    non mancano: quanta energia mentale sprecata per
    voler cavare a tutti i costi aranciata dai sassi!
Comunque lo aggiungero' alla lista ... l'autore sicuramente
ispira fiducia. Per ora abbastanza ancora indietro sulla
tabella di marcia (sono a meta' di "Large Scale C++ Software
Design" e ho gia' in coda un libro di Coplien e l'ultimo
di Scott Meyers).
Ormai sono un socio sostenitore di Amazon :DDDD
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 accessibili cose apparentemente complesse.
Sono d'accordo, anche se a volte Andrei appare un po' "leggero". Come
dicevo, a giudicare dai post la libreria Loki e' meno "rock solid" di
quanto lui sembri affermare. Resta che i concetti che presenta nel libro
sono potentissimi.
Ciao,
Nicola

 Ormai sono un socio sostenitore di Amazon :DDDD
Ti suggerisco 
www.gorilla.it
, allora, che spesso ha prezzi anche
migliori. E poi chi come noi sta dalle parti di Milano, ci puo' pure
andare, e non c'e' recensione che sostituisca lo spulcio. (anche se a
chi compra fisicamente non dovrebbero fare lo stesso prezzo fatto via
internet).
Ciao,
Nicola

ma questa e' un'altra storia).
cosa è "l'introspezione"?
Anto
--
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

cosa è "l'introspezione"?
Poter scrivere un programma che analizza la sua stessa struttura.
In C++ significherebbe avere un RTTI piu' sofisticato che oltre
a fornirti un nome di classe ti permetta anche di elencare quali
sono gli attributi, quali sono i metodi, quali sono le classi da
cui una classe deriva etc. etc.
Inoltre per chiudere il cerchio doverebbe anche essere possibile
accedere "dinamicamente" a queste parti... ovvero dato un puntatore
ad una istanza e nome/tipo di un membro dati o un metodo poter
accedere a quel membro dati o chiamare quel metodo. Questo
significherebbe ad esempio poter scrivere una funzione generica
che dato un puntatore ad un oggetto ne stampi tutti i membri dati.
Il LISP e' ad esempio un linguaggio che si presta bene a queste
cose (addirittura il programma e' in grado di *modificare* se
stesso aggiungendosi dinamicamente nuove funzioni o modificando
quelle esistenti). Con l'introspezione totale cade la barriera
fra il "run-time" e il "compile-time" e tutto diventa uniforme.
Ottimo materiale per gli scrittori di fantascienza ;)


 fra il "run-time" e il "compile-time" e tutto diventa uniforme.
e le prestazioni ? ?
vale la pena?
ciao
xaero

 Ottimo materiale per gli scrittori di fantascienza ;)
......e gli implementatori di jvm......
--
Ivan Molella
__LINUX__ the choice of the  __GNU__ generation

 vale la pena?
Dipende da cosa fai. A volte sono meglio che nel C++.


 cosa è "l'introspezione"?
Suppongo che Nicola si riferisse alla riflessività. Ovvero alla presenza di
metadati accedibili dal programma stesso.
In altre parole alla possibilità di sapere programmaticamente come e'
strutturato il codice (e magari anche modificarlo).
Praticamente nulla in C, Pascal e simili
Scarsa in C++ (RTTI)
Quasi completa in Java
Completa in Smalltalk e suoi derivati
Assoluta in Lisp e derivati dove non esiste differenza fra codice e dati (o
meglio entrambe sono rappresentati allo stesso modo: una lista. La differsnza
sta nell'uso che ne fai).
In CLOS e altri linguaggi moderni puoi non solo manipolare il codice come
fossero dati ma anche ridefinire buona parte dei meccanismi runtime del
linguaggio.


fra il "run-time" e il "compile-time" e tutto diventa uniforme.
ma il LISP č compilato? E come č possibile aggiungere funzioni
dinamicamente? Ogni programma č anche un compilatore :-)?


 fra il "run-time" e il "compile-time" e tutto diventa uniforme.
In questo contesto, piuttosto che compile-time non sarebbe più corretto
design-time? (E' una domanda non una correzione alla tua affermazione :)
Grazie
Luigi

ma il LISP č compilato? 
Credo che il LISP sia (per default) interpretato.
Non sono a conoscenza di compilatori LISP.

 dinamicamente? Ogni programma è anche un compilatore :-)?
Il LISP e' definito come linguaggio interpretato. Questo pero' non esclude il
fatto che possa essere anche compilato. Oppure che possa usare meccanismi che si
pongono in mezzo fra le due combinazioni (inclusi i famosi JIT compilers). E non
e' neppure escluso che si possa avere un programma con parte del codice
compilato e parte interpretato.
Pero' non chiedermi info su eventuali compilatori. Io sto solo dicendo che
dall'esistenza di un compilatore non deriva per forza l'impossibilità di di
aggiungere funzioni dinamicamente.
E poi la tua deduzione, anche se non del tutto valida per il Lisp, non e'
sbagliata. In Smalltalk, per esempio, per default un programma comprende un
compilatore completo (e anche un editor e anche un browser delle classi e anche
un debugger e tante altre cose). Il tutto viene "rimosso" dal programma quando
"impacchetti" il SW finito e funzionante, e solo se il SW stesso non lo usa.
Vedila come un linker al contrario. Un linker C++ parte dal main e linka tutto
quello che da esso e' raggiungibile prendendolo dagli obj e dalle .lib che tu
gli specifichi. In Smalltalk e' il contrario. Il sistema di sviluppo e il tuo
programma sono la stessa cosa e comprendono tutto. Poi al momento di rilasciare
il prodotto ... viene eliminato tutto cio' che il tuo programma non usa.


 wrote in message
news:0e217.8544$D03.2...@news.infostrada.it...

Secondo me la barriera principale che cade e' qualla che separa i dati dal
codice.
Pero' dal punto di vista di un linguaggio compilato esiste una seconda barriera:
compile-time e run-time. Questa barriera divide in due il set di diagnostici che
il compilatore (che non e' altro che l'implementazione del linguaggio) ti puo'
generare. In un sistema interpretato questa barriera non esiste. L'introspezione
totale non fa cadere direttamente questa barriera. Ma dato che di fatto implica
un interprete (o un compilatore incluso nel programma, il che e' lo stesso) di
fatto la fa cadere indirettamente.
La barriera fra run-time e design-time non ha a che fare con il linguaggio e gli
eventuali errori sintattici o semantico. Ha a ce fare con la capacità del
softwareista di individuare problemi di design. Secondo me piu' che fra run-time
e design-time e' una separazione fra design-time e code-time. Includendo quindi
la stesura del codice, la compilazione e il run-time in un unico blocco che pone
come fase distinta da quello del design time (nota: fase distinta non significa
che viene fatta dopo o altre cose simili. Solo che si occupa di un aspetto
leggermente diverso: il codice e la sua struttura invece che il programma visto
come sistema e la sua struttura).


 dinamicamente? Ogni programma č anche un compilatore :-)?
No, semplicemente l'interprete e' una funzione di libreria. Se poi
questo utilizzi un compilatore Just In Time e' da un certo punto di
vista irrilevante.
Tra l'altro con le librerie dinamiche e' possibile scrivere anche
programmi in C/C++ che modifichino se stessi, pur senza uscire dal
linguaggio: basta che generino codice e richiamino compilatore e linker.
Ciao,
Nicola

 e' lo stesso) di fatto la fa cadere indirettamente.
In realta', soprattutto in C++, potrebbe risultare utile avere un
meccanismo introspettivo diviso tra i due lati della barriera: in parte
esplicito, qualcosa come
template <class C> class ClassOf<C> { /* una qualche descrizione */ };
e dall'altra dinamico, tipo 
C c;
ClassInfo * cip = c.getInfo();
Ciao,
Nicola

 ...nel senso che non c'e' niente dal lato compile time.
Si. O piu' precisamente che la diagnostica compile time (syntax errors etc.)
avviene a runtime.


 wrote in message
news:3B456937...@divalsim.it...

Con l'importante differenza che compilatore e linker non fanno parte della
libreria standard e che non e' standard un meccanismo per permettere al codice
generato di accedere ai dati del programma (si puo' fare platform dependent
creando delle DLL da linkare poi dinamicamente).


usa.
[...]
Aaaah... Smalltalk, che bello! è stato il primo linguaggio che ho usato per 
la OOP. Molte volte rimpiango il fatto che non abbia avuto successo.....
Ritornando al discorso, in Smalltalk è proprio possibile autogenerare codice 
che viene ricompilato e usato dal programma. (Ricordo un esempio del Prof. 
che ci dimostrava questo con un pentium 100 e STExpress 8o0 )
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com
.
-- 
Posted from [192.106.52.2] by way of 
law2-f146.hotmail.com
 [216.32.181.146] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 la OOP. Molte volte rimpiango il fatto che non abbia avuto successo.....
Stai scherzando? E' il linguaggio in su cui si e' sviluppata la filosofia XP. Ed
e' il linguaggio piu' usato per applicazioni non realtime di grandi dimensioni
(grandi nel vero senso della parola. Dalle parecchie migliaia di classi in su).


la OOP. Molte volte rimpiango il fatto che non abbia avuto successo.....
Non ha avuto successo ??? 
Oltre ad essere uno dei padri dei moderni linguaggi di
programmazione ad oggetti + diffusi (e gode quindi di un
successo di riflesso) e' usatissimo.
--
CyberWalkie - walkietalkie(at)
libero.it

vale la pena?
Personalmente conosco il PHP, che anch'esso é dotato di funzionalità
simili a quelle che descriveva A.Griffini , ovvero la possibilità di
analizzare la struttura interna di una classe ricavando a run-time le
sue proprietà e le sue funzioni, stabilire da quale classe é derivata,
ecc.ecc..
Tutto ciò non pregiudica affatto le prestazioni.
Le comodità che queste funzionalità ti offrono sono infinite, ma penso
che rimarranno appannaggio dei linguaggi di scripting interpretati, e
non credo che potranno mai essere inserite in linguaggi come il C o il
C++.
 Il Ghenio
-----
ZIO : Fun and games are over with. Anyone who dares
get in my way shall perish.
DIO ci salvi dagli ocx del Viral Basic.
-----

Poter scrivere un programma che analizza la sua stessa struttura.
Qualcosa del genere l'ho vista nei sorgenti di MySQL fatta in C.
Via rete chiami una funzione con dei parametri scrivendo in formato
ascii il nome della funzione, e il valore dei parametri. Poi, al di
la' della rete, c'e' qualcuno che si preoccupa di decodificare, ed
usare il puntatore a funzione corretto, mettendo nello stack i
parametri corretti.
Personalmente la soluzione mi ha lasciato molto perplesso.
-- 
Tieni per te il Papero giusto se vuoi la mia email
Sito Papero 1 -> 
http://utenti.tripod.it/papero
Sito Papero 2 -> 
http://user.7host.com/papero/

 C++.
Le funzionalità che descrivi, ovvero la riflessività statica, possono benissimo
essere inserite in linguaggi come il C o il C++.
Quello che non e' cosi' banale in questi linguaggi e' la possibilità di
MODIFICARE a runtime il codice, come e' facilmente possibile in Lisp e, salvo
possibili problemi di licenza nella distribuzione di alcune implementazioni, in
Smalltalk.


Personalmente la soluzione mi ha lasciato molto perplesso.
Tutta la comunizazione fra oggetti OLE avviene nello stesso modo. Tutto il VB
for applications si basa su questo principio. Word e Excel "parlano" fra loro in
questo modo.
SOAP fa la stessa cosa salvo che la comunicazione fra le due macchine e' basata
non su un record contenente la stringa e il valore dei parametri ma sullo
scambio di un file testo formattato con XML (che contiene le stesse cose). Il
file puo' essere scambiato via HTTP se l'applicazione server e' basata su un
server web, altrimenti via e-mail.
MAPI e le Message Queue di Microsoft presuppongono lo stesso meccanismo.
MS Exchenage e Outlook fanno lo stesso.
COM e Corba e anche le RPC fanno una cosa simile, salvo che invece che la
stringa passano un codice che identifica la funzione.
Insomma: non mi sembra un meccanismo tanto raro e astruso da lasciare molto
perplessi.


Smalltalk.
Non conosco PHP ... ma in PERL e' possibile definire funzioni a
runtime (e a volte la cosa torna comoda proprio per le prestazioni).


perplessi.
Scusa MySQL potresti eseguirmi la funzione C "BloccaDB" con il valore
del parametro 1 pari a 10, e del 2 pari a "ciccio bombo".
Metodo che a te non sembra per niente astruso.
Scusa MySQL potresti bloccarmi la tabella "ciccio bombo" con un blocco
in memoria (parametro 1).
Metodo assolutamente classico per il client / server. Metodo che da
un'eternita' funziona tra i DB Server e i client dei DB stessi.
Perche' cambiarlo con il primo? Ogni volta che guardo MySQL trovo
motivi per non farmelo piacere.
Sara', ma io non capisco perche' in MySQL c'e' anche quel primo
metodo. Non so nemmeno se l'hanno introdotto direttamente in casa
madre, o se e' una genialata "esterna". 
Anche nel concetto di marshaling dei parametri di COM ci sono cose che
considero "astruse" come il passaggio dei parametri per puntatore. Non
era tremendamente piu' semplice dire che i parametri sono sempre
passati per valore?
++++
Anche la presunta necessita' della non distinzione tra dati e codice
del LISP (per me) e' fuorviante in questo contesto. Non e' necessario
per un sistema automodificante, e con la consapevolezza di se.
Dammi un buon DB Server (SQL Server, Oracle, forse PostGress nuovo) e
ti potro' fare "codice" automodificante senza bisogno di confondere
dati (il contenuto delle tabelle) e codice embedded (le stored
procedure e i trigger). Ti daro' un sistema che ha consapevolezza di
se (lo puoi interrogare sul codice delle stored procedure), e che puo'
creare codice al volo (una stored procedure puo' creare e compilare
una nuova stored procedure). Questo malgrado una stored procedure non
sia una tabella e viceversa.
Anzi, c'e' anche la cosa carina che una stored procedure puo'
sopravvivere alla morte dei dati (della tabella) ma il trigger muore
con la morte della tabella associata.
Che il trigger sia una funzione membro, e la stored procedura una
funzione globale? 
In un DB decente esistono anche i namespace, anche se di solito sono a
livello di connessione, e non di modulo di compilazione.
++++
In C++ non sento questo gran bisogno di vedere la singola classe e i
suoi metodi. Mi sembra un approccio sembra troppo low-level. 
 A me SOAP e XML mi sta può stare bene come standard di comunicazione
tra applicativi, ma credo che la cosa dovrebbe fermarsi li'. Un conto
e' "esporre" un servizio, un conto e' esporre una classe stile java.
Cosi' carichi di resposabilita' il designer, oppure crei i presupposti
per l'esistenza di classi nascoste dall'interfaccia che delegano il
lavoro ad altri. Ma in questo caso, di fatto, esporti servizi, e non
certo classi e metodi.
++++
Poi tutto questo esporre non e' certo risolutivo. Office puo' esporre
tutto cio' che vuoi, ma senza documentazione non vai da nessuna parte.
Non riesci cio' a fare richieste a run time nel mondo reale. Cose del
tipo: "chi mi puo' stampare un grafico"?
Cio' e' cio' che promette per esempio Jini. Bho, vedremo.
++++
Bisogna sempre poi intendere cosa significa "compilare codice". In
senso lato non esistono programmi monolitici. Di solito qualche
parametro che modifica in modo minimale il comportamento
dell'applicativo esiste sempre.
++++
Volendo niente ti vieta di scrivere codice esadecimale in una pagina
di memoria, e poi di eseguirlo. E questo in C/C++, e questo oggi. Sul
mio sito c'e' un link a un simpatico programma multipiattaforma che ti
comprime l'eseguibile, e ti cambia lo stub. Quando chiedi di eseguirlo
lo stub decomprime al volo l'eseguibile, e lo lancia.
Non e' questo codice automodificante?
E questo senza bisogno di un run-time stile JVM.
++++
Il punto e': in SmalTalk (e pure in VBScript) ci sta bene, ma in C++
servono realmente queste cose?


anche in JavaScript, function è un Object, e puoi creare una
funzione a runtime con:
var myfunc = new function("codice");
myfunc(...);
--
ciao
xaero
"Andrea Griffini" ha scritto nel messaggio...


 Cio' e' cio' che promette per esempio Jini. Bho, vedremo.
Dietro a tutto questo c'e' un problema cognitivo fondamentale: In un
programma "tradizionale" usi dei simboli; in un programma
"introspettivo" usi degli altri simboli per descrivere i simboli
precedenti; puoi creare in questo modo un numero infinito di
metalivelli, ma non raggiungerai mai l'esplicitazione dei significati
che stanno dietro a tutti questi simboli.
In soldoni puoi esplicitare tutte le interfacce che vuoi, ma se non sai
cosa fanno, non ti servono a nulla.
Ciao,
Nicola

 (grandi nel vero senso della parola. Dalle parecchie migliaia di classi in su).
Sara', ma il progetto su cui sto lavorando da un paio d'anni sostituisce
un'applicazione SmallTalk con una in C++, e nessuno rimpiange la
precedente, soprattutto per i problemi di prestazioni e di testabilita'
della precedente.
Ciao,
Nicola

 prestazioni).
Diciamo che in generale in tutti i sistemi interpretati (o compilati a runtime
da un JIT che opera direttamente sul sorgente) e' facile permettere la creazione
di nuovo codice a runtime.
In generale nei sistemi in cui il codice e' compilato o semicompilato (in p-code
che poi viene interpretato o compilato a runtime da un JIT) la cosa e' piu'
complessa ma possibile purche' il compilatore sia accedibile programmaticamente
e ci sia la licenza per distribuirlo assieme all'applicativo.
Ma il discorso era nato non dalla possibilità di generare nuovo codice ma da
quella di manipolare il codice esistente. E specificatamente quella di
analizzarlo per riflessività (o introspezione come dice Nicola). La possibilità
di modificarlo o di aggiungerne di nuovo e' un passo successivo.
La riflessività e' ben supportata in pochi linguaggi ed e' ottimamente
supportata in ancora meno. La riflessività di C/Pascal e' praticamente nulla.
Quella del C++ poco di piu'. Quella di Smalltalk (e derivati) piuttosto buona.
Quella di Lisp (e derivati) ottima.
SQL e' un caso particolare. E presenta riflessività completa per la parte dei
dati, minore (ma non assente) per quella delle stored procedures.
Non conosco PHP. Non conosco Perl abbastanza da esserne sicuro, ma credo che
possa generare nuovo codice piu' facilmente che non manipolare (anche in red
only) il codice esistente. E comunque e' un linguaggio abbastanza particolare
nel quale non sono sicuro abbia molto senso parlare di riflessivita'.
La riflessività di Java (e suppongo JavaScript) e' molto migliore di quella di
C++, ma non mi pare ai livelli di quella di Smalltalk (e certamente non a quelli
di Lisp).


 servono realmente queste cose?
La possibilità di modificarsi forse no. La riflessività certamente si.


 wrote in message
news:3B496508...@divalsim.it...

I problemi di testabilità di solito dipendono da una cattiva strutturazione del
codice. Che sia fatto in Smalltalk o in C++ non cambia nulla. Lo scopo di
Smalltalk non e' certo quello di obbligare a scrivere codice ben fatto (nessun
linguaggio puo' obbligarti a farlo). E un cattivo design non dipende dal
linguaggio. Solo ADA (e solo entro crti limiti) da qualche vantaggio in termimi
di testabilità. Ma stiamo parlando di "prove di correttezza formali". Cose che
difficilmente servono se non in ambito militare (o per motivi accademici).
Riguardo alle prestazioni ci sarebbero due considerazioni da fare. Una e' che se
il programma e' scritto in un ambiente Smalltalk vecchio e' molto probabile che
le prestazioni non siano eccellenti, ma ho visto codici Smalltalk moderni che
girano piu' velocemente dei corrispondenti C++. Naturalmente molto dipende da
cosa fai. Provare a cambiare il runtime di Smalltalk con uno piu' moderno puo'
essere un'idea (mi dicono che QKS e' fra i migliori).
Inoltre ci sono alcune considerazioni legate all'ottimizzazione del tempo di
esecuzione di un programma Smalltalk che sono specifiche per quell'ambiente. E'
raro che un programma ne abbia bisogno ma in Smalltalk, come in C++, ci sono
casi in cui il codice piu' "ovvio" esegue in un tempo di parecchi ordini di
grandezza maggiore rispetto ad una versione ottimizzata. Il trucco, come sempre,
sta nello scrivere il codice prima, misurare le presatazioni e ottimizzare solo
le parti necessarie (magari con l'aiuto di qualcuno che lo Smalltalk lo conosce
molto bene).
Comunque il fatto che un sistema scritto in Smalltalk venga rimpiazzato da una
scritto in C++ non significa nulla dal punto di vista dell'utilità del
linguaggio. Hai idea di quanti sistemi scritti in C o C++ sono stati rimpiazzati
da VB?


di classi in su).
E' vero, ma sta d fatto che qui in Italia, la diffusione del ST č 
praticamente nulla rispetto a ciň che il citato professore (che tra le altre 
cose č l'organizzatore di 
http://www.xp2001.org/
) auspicava!
Le persone con cui lavoro (e t assicuro che sono tante compresi molti 
consulenti) non sanno neanche com'č ST, e parecchio codice che scriviamo in 
Java secondo me risulterebbe decisamente piů "semplice" (proprio per le sue 
grandi dimensioni ) da scrivere con ST. Ma qsta č la mia opinione di 
novellino che non conta nulla....
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com
.
-- 
Posted from [192.106.52.2] by way of 
law2-f30.hotmail.com
 [216.32.181.30] 


 di persistenza.
Nota che per questo tipo di cose potrebbe essere sufficiente una
rappresentazione statica: in fondo basterebbe poter ciclare sui membri
dati in base al nome.
 
Ciao,
Nicola

 dati in base al nome.
In realta' non e' questo che intendevo dire: se pretendo di eseguire un
ciclo ho bisogno di una rappresentazione dinamica. Pero' potrebbe essere
sufficiente l'aggiunta di un meccanismo specifico, come le properties
Borland, piuttosto che non prevedere un meccanismo di riflessivita'
completa, che per un linguaggio complesso come il C++ sarebbe
intricatissimo.
Tra l'altro personalmente sospetto che parte dei "tagli" compiuti nel
disegnare Java abbiano piu' a che vedere con la possibilita' di ottenere
un meccanismo di riflessivita' maneggevole che non il desiderio di
"proteggere" il programmatore.
Ciao,
Nicola

 rappresentazione statica
Esatto. Era questo che intendevo con "anche solo in lettura".


 novellino che non conta nulla....
Da quello che scrivi potrebbe interessarti questo:
I ragazzi della QKS (ovvero David Simmons il Guru un persona) stanno lavorando a
un progetto conosciuto come SmallScript.
Il nome e la casa madre ti dicono molto. Features di Smalltalk modernissimo.
Velocità incredibile. Nato per Internet (Script non e' li a caso). Portabile su
Unix, Windows, Mac e altro. Puoi sviluppare anche "stand alone" (cioe' slegato
da Internet) e, novità delle novità, lo stesso codice potrà girare su ben tre
diverse infrastrutture di esecuzione. Una free. Una commerciale e
superottimizzata (quella di QKS). E una ... beh, si chiama .NET.


only) il codice esistente.
in effetti se manipoli il codice in black only è molto più facile
:-))))
Anto
--
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

persistenza.
non è che lo puoi spiegare in termini più comprensibili per noi poveri
esseri umani?


cosa fanno, non ti servono a nulla.
Tante grazie. Motivo questo per cui i componenti godono di grande
fortuna nel mondo windows (lo sviluppatore risolve i conflitti). Per
lo stesso motivo trovo folle la filosofia Sun dei dispositivi che
chiedono chi puo' stampare non si sa cosa in rete (risoluzione dei
problemi non banali a carico di una non meglio specificata
intelligenza sintetica).


La possibilità di modificarsi forse no. La riflessività certamente si.
Fammi un esempio non banale.
Un tempo pensavo che il potere "sparare" una classe come e' possibile
fare con Java fosse una bella cosa. Oggi mi sembra una cosa fine a se
stessa.
Un tempo pensavo che i protocolli dovessero essere ottimizzati, mentre
adesso qualsiasi mio protocollo di serializzazione passa attraverso
una stringa. E' bello potere far debug in modo umano.
Io non ci vedo questa grande utilita' nella riflessivita, anche se
ammetto che probabilmente e' un "forzatura" della mia forma mentale
attuale.


 l'introspezione. Non puoi indagare sul significato.
Che ci vogliano delle assunzioni di partenza e' indiscutibile.
L'interospezione ti permette di scrivere codice generico, che utilizza
una singola associazione tra campi di record e attributi di classi e su
questa associazione basa tutte le operazioni necessarie.
Ciao,
Nicola

 esseri umani?
Pensa di dover salvare su file e rileggere istanze di una gerarchia di
classi, partendo da un insieme di primitive che scrivono e leggono
valori dei tipi nativi. Senza riflessivita' ti tocca classe per classe
scrivere esplicitamente tutto il codice, ad es.:
class A { public: int i; double d; };
void scriviA(const A & a) { scriviInt(a.i); scriviDouble(a.d); }
Mentre se hai a disposizione un meccanismo di riflessivita' potresti
magari scrivere:
template <class C> void scrivi(C * c) {
  ClassDesc * cd = c->getDescription();
  for ( AttributeIterator a = cd->begin(); a != cd->end(); ++a )
  {
    if ( a->isInt() )
      scriviInt(a->getValue(c));
    else if ( a->isFloat() )
      scriviFloat(a->getValue(c));
  }
}
E questo funzionerebbe per qualsiasi classe.
Ciao,
Nicola



Non saresti cosi' gentile da farmi un esempio in (pseudo)codice,
magari in un altro thread.
Per un cliente mi sono dovuto imparare Java la mattina per fargli
funzionare nel pomeriggio un suo pezzo di codice (l'alternativa era
dargli i sorgenti del "mio" pezzo di codice).
Per spedire "qualcosa" via rete alcuni oggetti usano una funzione
chiamata print, altri qualcosa chiamato write, e di quelli intravisti
nessuno usa il nome send. Riflettendo su questa porzione di thread
sono rimasto dell'idea che i nomi e i tipi ben poco di dicono*.
Ho capito poco di Java, e non capito come l'introspezione possa
funzionare nel mondo reale. Per esempio io faccio comunicare i miei
processi usando degli stream con header. Uno stream con header e' uno
stream a sua volta? Dal punto di vista pratico si, ma dal punto di
vista logico mi sempra una cosa molto diversa. Dal punto di vista
pratico uno stream potrebbe essere visto come una stringa. Dal punto
di vista concettuale stream e stringhe non li considero oggetti
"simili".
*
Oltre dirmi che nella documentazione Java di Sun c'e' un esempio che
non funziona, usato dai strapagati consulenti Accenture per testare il
programmi Paperi.
