Newsgroup: it.comp.lang.c++
Titolo: Java vs C++

Salve a tutto il NG.
Vorrei proporre una discussione che confronti
java e C++. C'è qualcuno di voi che, oltre ad avere esperienza in C++, ha
sviluppato anche in java e può comunicarmi le sue impressioni usando i due
linguaggi. Mi interesserebbe sapere dove a vostro giudizio sono i pregi e i
difetti delle due soluzioni. Spero di non essere OT (almeno il 50% del
discorso è inerente al NG: si parla comunque di C++, anche se come metro di
confronto viene proposto poi un altro linguaggio). Spero di non infastidire
nessuno.
Grazie a quanti vorranno rispondermi. Se l'argomento non lo riterrete di
utilità per discuterne sul NG potete mandarmi le vostre impressioni in forma
privata via mail.
Ciao a tutti
Andrea


ICQ #34602650

nessuno.
(Crossposto su it.comp.software-engineering dato che puo' interessare anche 
li')
Be', ho sviluppato parecchio in entrambi i linguaggi, e dato che di mestiere 
faccio il designer di sw sono quelli che uso comunemente a meno di vincoli 
esterni. Sulle differenze tra Java a C++ un paio d'anni fa ci scrissi sopra una 
articolo da 15 pagine, e Java aveva un terzo della potenza che ha adesso :), 
quindi in breve si puo' dire molto poco. :)
Comunque, Java nasce come una semplificazione di C++ *e* un potenziamento dello 
stesso: i vantaggi in brevissimo, a livello di linguaggio, capacita' 
espressive, ambienti e librerie (wow :)
- maggiore portabilita'. E' possibilissimo scrivere codice portabile in C++, 
almeno finche' non c'e' di mezzo una GUI,
  ma e' *molto piu' difficile*. 
- supporto nativo al multithreading. C++ si deve appoggiare al s/o.
- supporto nativo al networking. Per C++, come sopra.
- migliore supporto al design OO, con la definizione specifica di interfacce e 
classi di implementazioni. C++ ha solo classi astratte come elementi di 
modellazione.
- garbage collection. In C++ i memory leaks sono all'ordine del giorno, in java 
quasi non esistono. 
- non c'e' l'ereditarieta' multipla. Qui si va a gusti, ma la mia esperienza e' 
che l'e.m. complica le cose piu' di quanto non le aiuti. Non entro in dettagli 
altrimenti faccio un trattato :^)
- gestione esplicita dei package. C++ ha i namespace - ma chiunque abbia 
provato a lavorare con librerie diverse e vincoli di contratto sa quanto 
possono valere.. :)
- loading dinamico delle classi - il programma non e' quasi-monolitico come in 
C++.
- una libreria standard da paura, gratis.
- una curva di apprendimento un pochino meno ripida. Per usarlo efficacemente 
ovviamente, tanto quanto C++, bisogna conoscere l'OO - altrimenti si resta 
praticoni a vita. ;-)
- supporto obbligatorio alle eccezioni. In C++ sono opzionali (e pochi 
programmatori le usano, dato che sono state aggiunte da relativamente poco), e 
i risultati sulla qualita' del codice si vedono.
- tempi piu' veloci per lo sviluppo e una generale miglior qualita' del codice 
prodotto anche da programmatori non.. sopraffini (nella mia esperienza, una 
ratio 3/5gg a favore di java per sw di complessita' media).
C++, d'altro canto:
- e' strutturalmente piu' performante. Alcune caratteristiche di java (gc, 
architettura a VM, etc) lo rendono piu' lento.
- e' stato recentemente standardizzato
- non ha un un'unica radice per le gerarchie di oggetti. Io personalmente non 
lo vedo come vantaggio, ma c'e' chi lo fa.
- non favorisce il downcast dinamico, che in Java e' una prassi
- ha i template, che a volte sono decisamente comodi
- ha STL, che e' potente e versatile - e soprtattuto ha un sacco di algoritmi 
ben fatti gia' pronti
- consente di accedere direttamente al s/o - che a volte e' indispensabile
- non e' facile da reverse-engineering-izzare (lo so e' orrido :) mentre java 
e' tutto sommato facilmente decompilabile.
- di java si sono avute almeno 15 versioni in tre anni. Il linguaggio, anche se 
imho maturo, e' ancora giovane.
Varie ed eventuali:
- java obbliga (piu' o meno) ad una strutturazione dei moduli "una classe-un 
file" (o poche classi *molto* correlate), 
C++ mantenendo la struttura header/codice a volte e' un incubo da ricompilare.
- c++ "vive" (anche se in forme e quasi-standard diversi) commercialmente dai 
primi anni 80, java da meta' 90. Questo significa che e' piu' "accettato" anche 
in ambiti conservatori.. ottenere un contratto nominando C++, in molti ambiti, 
e' ancora piu' facile che non nominando java.
Ovviamente ci sarebbe un libro di cose da scrivere.. comunque e' un inizio.
Saluti,
 Cris

 file" (o poche classi *molto* correlate),
In C++ se ti affidi ad alcuni gestori di codice sei nelle stesse
condizioni.


  ha STL, che e' potente e versatile
STL evidenzia come il C++ si presti a diversi paradigmi. Questa
flessibilità
più la compatibilità con il C hanno aggiunto un livello di complessità al
linguaggio e, probabilmente, hanno anche impedito un'implementazione "pura"
rispetto a uno dei vari paradigmi.
A discapito di questi disagi, i vantaggi possono essere notevoli, anche se
java probabilmente favorisce meglio delle buone pratiche di programmazione,
dovendosi focalizzare su un unico paradigma. Che ne pensi?

dovendosi focalizzare su un unico paradigma. Che ne pensi?
D'accordissimo. Io sono il primo, quando voglio farmi qualche utility 
"quick&dirty" a usare C++ come 
C-con-la-possibilita'-di-dichiarare-variabili-nel-corpo-della-funzione :)
dimenticandomi oggetti&c. E vuoi mettere avere subito un bell'exe o a.out 
invece di dover ogni volta invocate la jvm? :)
E' che il mix procedurale-OO e' potenzialmente potentissimo, ma per usarlo 
in sistemi complessi senza combinare enormi casini devi capire e conoscere 
molto bene teoria, pratica e pragmatica di entrambi. E il triste fatto e' 
che, nella mia esperienza, di programmatori realmente "buoni" anche solo in 
uno dei due paradigmi ce ne sono proprio pochini...
Saluti, 
 Cris

 il sostanziale fallimento del primo approccio),
scusa l'ignoranza... :-)
per favore potresti spiegarmi questo concetto?
non capisco bene cosa intendi per "ruoli e relazioni"
TobiX





Infatti in Java si usano SOLO i puntatori !

 Infatti in Java si usano SOLO i puntatori !
Li usa java, non tu <g>



Ti rimando a
http://space.tin.it/computer/csadun/articoli/design_oo.html
nel paragrafo "ruoli e relazioni" ;-)

Infatti in Java si usano SOLO i puntatori !
Be', "riferimenti" (stile algol :) che vuol dire che *non* hai l'artimetica 
dei puntatori... :)

design OO "moderno".
Correggimi se sbaglio ma non è il primo approccio, come dici tu, ad essere
fallito (ereditarietà e riuso del codice sono ancora valide soluzioni),
bensì il tentativo di applicarlo sistematicamente ad ogni situazione di
design. Le forme di riuso sono molte, dall'implementazione alle interfacce
alle relazioni alle astrazioni e ai meccanismi di interazione. C'è poi riuso
del codice e riuso del design. Scusami se
insisto, ma continuo ad essere perplesso quando mi devo confrontare con
un'affermazione del tipo "java offre un miglior supporto ad un design OO
moderno". Il C++ supporta adeguatamente tutte le forme di riuso che ho
accennato prima. Certo, c'è anche una questione di stile, ma qui si va a
gusti personali e quindi mi fermo.
Se permetti, vorrei fare un ulteriore passo nella direzione delle interfacce
e del design. Prendo spunto da un articolo di C. Pescio, apparso un po' di
tempo fa su Computer Programming (N° 63). Se proprio vogliamo parlare di
design, un sostanziale passo in avanti nella direzione di una specifica di
interfacce più chiara e rigorosa possiamo farlo con linguaggi come Eiffel
oppure come Ada.
C++ e java li vedo più o meno sullo stesso piano. Al di là delle differenze
sintattiche, nessuno dei due brilla per fornire un vero supporto al design
by contract. Il contratto implementato da una classe astratta c++ o da una
interfaccia java è basato sulla considerazione che la signature di una
funzione basti come meccanismo che assicura il rispetto comportamentale
della stessa. La specifica è troppo ambigua ed informale.  Quando estendo le
varie classi, l'unico vincolo che devo rispettare è l'adeguamento sintattico
alla signature, mentre nessuno dei due linguaggi forza ad un adeguamento
semantico. Certo, in C++ potrei aggiungere delle asserzioni per verificare
le pre-condizioni o le post-condizioni; potrei usare le stesse asserzioni o
un meccanismo analogo per verificare gli invarianti ad ogni invocazione di
funzione e ad ogni uscita. Però, ancora una volta, questo armamentario è
lasciato alla discrezione (e all'ambiguità) del progettista.  Non è un
grande supporto. E che dire di java che non fornisce - correggimi se erro -
un meccanismo per togliere dal codice tutto questo mucchio di asserzioni e
altro codice di debug necessario per ovviare alla mancanza di un livello di
specifica più formale?
Non mi sembra proprio che si possa dire di aver raggiunto con java un
livello di progettazione del design OO moderno...specialmente sul problema
della chiarezza dell'interfaccia. Queste mie perplessità non sono fondate?
Grazie molte comunque per gli interessantissimi spunti di riflessione.
Ciao
Andrea

uno dei due paradigmi ce ne sono proprio pochini...
Apro una digressione sulla qualità della programmazione.
"M$, dove vuoi andare oggi?"  :-)
Ho rubato una battuta, ma solo perché si presta al mio discorso.  Credo
che ogni progettista debba porsi degli obiettivi. Alla fine della fiera, si
affronta questo (come qualsiasi altro lavoro) semplicemente perché si è in
grado di farlo e perché bisogna pur sopravvivere in qualche modo, oppure
perché, oltre alle ovvie esigenze di cui sopra, si è mossi anche da una
"spinta interiore" nei confronti della crescita personale. Io sono giovane
ed anche inesperto, ho appena 25 anni e sto frequentando ancora
l'università. Ho scritto codice quasi esclusivamente in ambito accademico e
il programma più grande che ho finora scritto in C++ consta di circa 20 K
righe. Non è molto, certo, però da qualche parte bisogna pure iniziare. Il
punto, a mio avviso, è di obiettivi e di atteggiamento. L'esperienza resta
fondamentale, però non sono proprio convinto che essere soddisfatti del
proprio codice solo perché "gira" sia un modo di asserire "sono un buon
programmatore".  Progettare codice riusabile, pulito, comprensibile,
facilmente estendibile e testabile costa semplicemente più fatica e, per
questa ragione, viene accantonato con la frase "costa economicamente
troppo". Però si tratta quasi sempre più di una questione di atteggiamento
che di puri quattrini, almeno in tutti quei progetti di medio, lunga
dimensione e soggetti a lunga vita (manutenzione, estensione,
ridefinizione...). In tutti questi casi, un design affrettato o
semplicemente affidato al tool RAD che si è abituati ad usare ed
un'implementazione sbilanciata ad ottenere il proprio eseguibile il prima
possibile, costi quello che costi, alla fine finisce per costare
paradossalmente di più (correggimi se sbaglio). La mia impressione, ed
ancora una volta parlo di impressione, è che affidarsi così tanto ad
ambienti RAD o a tool automatici sia semplicemente un modo per scaricare le
proprie responsabilità.  Finendo così per perdere l'abitudine di pensare.
E questo, è davvero mediocre per un buon
progettista. Tu dici che ce ne sono pochi? Beh, probabilmente perché la
risorsa a cui attingere non è più un costrutto, una sintassi o un libro, ma
un atteggiamento, una dedizione nell'affinare la propria capacità critica, e
anche un pochino di rigore mentale... insomma qualità che ho hai o non hai.
Per di più il sapere che costa molta fatica consolidarle nel campo di
battaglia non rende la cosa meno indigesta... chi te lo fa fare dunque? Ne
vale
la pena? Ad ognuno la propria risposta.
Torniamo alla tua affermazione "il mix procedurale-OO e' potenzialmente
potentissimo ma difficile da portare a termine senza casini". Sono
d'accordo, ma a me, come ormai appare chiaro, piace di più girare la
frittata e pormi la domanda "ne vale la pena?". Delle volte la risposta sarà
no, come è giusto che sia, ma in un certo numero di altre opterrò per il sì
o quantomeno per un forse.
Capisci cosa intendo per capacità critica? Quante persone si soffermano un
attimo a pensare quale sia l'atteggiamento migliore per affrontare un
problema e quante altre, invece, non si pongono neppure il problema e
sviluppano per "partito preso", guidate dall'abitudine, dai tool o da altre
considerazioni di pura comodità personale? Credi davvero che queste mie
posizioni
dipendano esclusivamente dal mio background, finora orientato più al mondo
accademico che a quello di produzione? E' insomma aria fritta? Io ritengo di
no.
Saluti
Andrea

qui).
Concordo in pieno - il punto triste e' che MFC e' forse la libreria C++ piu' 
usata. :^)
Sul resto rispondo in un thread separato - altrimento 'sto articolo ci vuole 
compress per postarlo! :)

della chiarezza dell'interfaccia. QueCio' che intendo io, credo di averlo 
chiarito. ste mie perplessità non sono fondate?
Se per "chiarezza di interfaccia" intendi la possibilita' di verificare 
staticamente la correttezza semantica di un'implementazione, no di certo - ne' 
era nei suoi obiettivi. Ma ho l'impressione che su questo staremo freschi per 
un bel po'.. :)

post.
Raccolgo molto volentieri....
Ciao
Andrea

loro assenza. Come si costruisce una lista in Java?
Domanda da postare su it.comp.java
Ciao
---------------------------------------
Email: sostituire "nospam" con "uol"

C++ mantenendo la struttura header/codice a volte e' un incubo da ricompilare.
Questo con i tool solitamente forniti dai compilatori (almeno quelli commerciali)
non e` piu` un grosso problema...
Per il resto comunque sostanzialmente concordo anche se vorrei far notare che
un confronto cosi` generico tra i due linguaggi mi sembra un po' azzardato dato che
non hanno lo stesso target! Tant'e` vero che ad esempio la GC di java non e`
presente nel C++ proprio per dar modo al programmatore di scegliere cosi`
come non sei obbligato ad utilizzare tutto cio` che il C++ ti mette a disposizione.
Se da un lato Java (per quanto ne so) e` stato pensato per risolvere in primo
luogo il problema della portabilita` a livello di codice eseguibile, il C++ e`
stato pensato in modo da non obbligare l'utente ad utilizzarne tutte le caratteristiche
e a pagarne il prezzo che esse impongono.
Nel caso di Java la scelta si paga in termini di prestazioni, nel C++ in termini di
tempi di sviluppo!
Saluti,
Paolo
------------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
  G: Per concludere, possiamo chiedervi di commentare
     l'attuale panorama informatico?
  I: /* l'attuale panorama informatico */
------------------------------------------------------------------

Raccolgo molto volentieri....
Be' non e' che io abbia ricette particolari e miracolose, solo qualche idea. :)
Stralcio da un'articolo su cui sono seduto :) da un po' : 
[....]
Posto che una certa cosa prometta e mantenga un certo aumento di produttivita', 
si possono valutare:
- minore "coscienza del problema" o "controllo" del programmatore
- contesto di applicabilita' e contesto medio di *uso* del linguaggio/strumento
- effetti positivi e negativi generali della suddetta mancanza di controllo, 
nell'intersezione tra i due contesti di cui sopra
- effetti positivi e negativi nel problema particolare
- curva di apprendimento della feature
Prendiamo la garbage collection (ad esempio in java, forse l'unico linguaggio 
"popolare" che la adotta). Eliminando la delete esplicita, c'e' il rischio che 
un programmatore sia meno cosciente della gestione della memoria, qualcosa di 
cui non e' ancora possible fare troppo a meno (anche se, ohime', migliaia di 
applicazioni visual basic la raccontano diversamente.. :( ).
[Sia detto per inciso, in teoria (e in dipendenza dalle ottimizzazioni del 
compilatore), anche, che so, la sequenza di riempimento di una matrice potrebbe 
avere un influsso sulle prestazioni, in base all'architettura fisica 
dell'accesso a memoria.. ma chi conosce e fa uso di tutte le caratteristiche 
combinate dei compilatori e dei processori a tutt'oggi?]
Ora, pero', osserviamo bene: per *usare* java (non come giocattolo-applet, e' 
chiaro) bisogna aver ben chiara l'idea di allocazione dinamica (new) dato che 
il linguaggio e' pervaso da riferimenti algol-like. Se quest'idea non c'e', e' 
relativamente impossibile "usare" tout court il linguaggio. E conoscere 
l'esistenza di un gc, di per se', evidenzia almeno superficialmente l'esistenza 
di qualcosa (la memora deallocata) che puo' essere "garbage" e puo' essere 
"collected". Quindi una certa coscienza dell'argomento "memoria dinamica" - 
anche se in prima istanza piu' superficiale - viene mantenuta.
In altri termini, viene preservata la visione ad alto livello, mentre si puo' 
*scegliere* di ignorare i dettagli (ad esempio, lo specifico algoritmo di gc).
Questo e' un processo di astrazione! Non cosi' "controllato", certo, come 
quello che conduce ad un modello software (dove si suppone che i dettagli siano 
*conosciuti* prima di toglierli :), ma simile ai processi cognitivi di 
comprensione che usiamo quotidianamente.
Da queste considerazioni emerge un ulteriore osservazione: una feature 
raramente e' valutabile "da sola", ma anche in relazione alle altre features 
presenti.
Il contesto di applicabilita', essendo una feature di linguaggio, e' generico. 
Quello d'uso - no: sistemi real time o con particolari restrizioni di spazio o 
di performance probabilmente non sono adatti alla presenza di un gc.
L'effetto positivo e' la maggiore produttivita' - i cui motivi dovrebbero 
essere evidenti, cfr. [3]; una curva di apprendimento praticamente nulla. 
Effetti negativi - certamente un impatto sulle performance, e (culturalmente) 
la "non esposizione" a problemi critici in altri linguaggi, relativi alla 
gestione della memoria. Il che significa che un programmatore java, spostandosi 
per esempio verso C++, incontrera' problemi dovuti alla mancanza di cultura ed 
esperienza specifiche.
[... valutazione numerica con un modello sw-e ad hoc...]
Veniamo ora a uno strumento come un "wizard" - il quale genera codice 
"skeleton" per framework o codice "concreto" per funzionalita' specifiche.
I due casi sono diversi:
Nel primo, intere pagine di codice "scheletro" vengono create automaticamente - 
ma *poi* il programmatore deve riempirle. Dato che per far cio' la curva di 
apprendimento e' quella del framework (e non del wizard stesso) il reale 
incremento di produttivita' dipende dalla bonta' e complessita' del framework 
stesso. 
La "coscienza" del programmatore rischia di esserer seriamente minata. I 
dettagli "eliminati" in prima istanza spesso non riguardano solo 
l'*implementazione* di una funzionalita', ma la rete di relazioni e di ruoli 
(cfr [2]) predisposti dal framework. La non conoscenza di tratti essenziali non 
appare di solito bilanciata da altre caratteristiche, e conduce spesso nella 
pratica all'apprendimento "per tentativi" e in ultima analisi a codice 
"spaghetti" [4].
Il contesto di applicabilita', generalmente, e' limitato - e appare vagamente 
in relazione inversa con l'incremento di produttivita': se la funzionalita' per 
cui e' generato il codice e' complessa le possibilita' di parametrizzazione e 
personalizzazione appaiono limitate - specie in frameworks "rigidi".
[....]
Quando (e se) il tempo (e la testa ;-) mi consentiranno di completare 
l'articolo lo mettero' in linea. Commenti a quanto sopra sono benvenuti,
ovviamente (anche se sto spendendo troppo tempo a scrivere news negli ultimi 
due giorni!).
Saluti,
 
 Cris
-- 
God is Real, unless declared Integer

impongono. 
Non mi e' chiara la frase, dopo "il C++". "non obbligare"? Cosa intendi?
Il punto e', se una feature esiste, porta dei vantaggi in termini di
potenzialita', ma aggiunge complessita'. Java e C++ scelgono tradeoff
diversi - e hanno quindi forme diverse - ma le feature di C++ sono li'
perche' qualcuno ha ritenuto che siano usate, no? (vedi anche
l'evoluzione e la storia dello standard). 
Senno' e come dire - una Ferrari va a 300 all'ora, ma non e' pericolosa
perche' puoi andare a un decimo del gas. Io la Ferrari a un neopatentato
non gliela darei lo stesso! :) 

perche' puoi andare a un decimo del gas.
Non ho detto questo, la presenza di un costrutto non ne giustifica l'uso in un
qualunque contesto come il possesso di una ferrari non autoirizza ad andare
a 300 all'ora!


 di design e contesto storico.
Molto giusto. In C++ sei lasciato libero di scegliere. E la scelta si
basa sulle tue reali necessita'. Vi sono casi in cui la GC non e'
applicabile, o magari il programmatore e' cosi' in gamba da riuscire a
gestire il programma senza utilizzare la GC (chiaramente non sto
parlando di progetti da MLOC, ma per mia fortuna/sfortuna non ho mai
partecipato alla stesura di un programma di tali dimensioni).
massimo

partecipato alla stesura di un programma di tali dimensioni).
Stavo per finire con "e si vede". Ma in effetti ho letto un solo tuo post - 
questo - quindi, al contrario tuo, rifletto e mi astengo.


 questo - quindi, al contrario tuo, rifletto e mi astengo.
Mi sembra di cogliere una appena accennata supponenza.
Ah, per concludere, accolgo il tuo suggerimento di non sprecare banda
(almeno dal prossimo post), tanto tutto cio' non mi e' di alcun aiuto
nel produrre software migliore (che alla fine dovrebbe essere il fine
ultimo della lettura dei post).
Senza, e confermo, senza alcun rancore.
massimo

ridimensionato i loro progetti a riguardo).
Credo che vada considerata anche l'attuale situazione di mercato in cui su
oltre il 90% sono pc su cui gira windows. In un simile contesto le caratteristiche
di java (in particolare la portabilita` degli eseguibili) non sono di aiuto alla
sua diffusione nella produzione di applicazioni... In un simile contesto java
deve fare i conti con linguaggi come l'object pascal di delphi (con tutto cio`
che delphi mette a disposizione) e (purtroppo) visual basic che garantiscono
tempi di sviluppo sostanzialmente uguali (se non maggiori) a quelli di java (IMHO).
In effetti uno dei maggior difetti del C++ e` che impone tempi di sviluppo maggiori
e richiede una maggiore preparazione del programmatore. L'ultima in questo senso
mi e` capitata poche settimane fa... alla mia proposta di utilizzare (eventualmente)
il C++ nella realizzazione di un progetto ci fu il seguente scambio di parole:
a:             Ti vuoi fare male!
 risp:       Lo uso da qualche anno e non mi crea alcun problema...
b:            E chi verra` dopo di te ad occuparsi del progetto?
Avrei volentieri risposto "Cavoli suoi!", ma mi limitai ad una risposta piu`
diplomatica!
Per la cronaca come alternativa mi fu proposto Delphi, ma ancora la
scelta definitiva non e` stata fatta.
Paolo
P.s.
   Non ho ancora avuto modo di leggere "Large Scale C++ Programs" per
   questioni di tempo, ma qualcosa la si trova anche su C. Pescio "C++ manuale di stile".


ma senza emoticon). Se paolo la applica o meno lo dira' lui, se ritiene.
Dipende... in effetti ho avuto una tale necessita` solo una volta, e nel caso in
esame scelsi l'ereditarieta` perche` mi permetteva di venirne fuori in due
ore risparmiandomi la ricompilazione di OWL, la gestione di due
diverse versioni e la molto probabile fase di debugging...
Credo che i guadagni in termini di costi e tempo siano stati tali da
giustificare l'uso di una "pezza"  al posto di una seria revisione di
tutta una serie di classi!
Ho poca esperienza pratica, ma una cosa che ho imparato e` che "la
differenza tra la teoria e la pratica e` in pratica molto maggire che
in teoria" (mi sembra di aver letto una frase simile da qualche parte,
ma non ricordo dove). In sostanza la teoria spesso non tiene in considerazione
i problemi contingenti e la necessita` di una pronta soluzione.
Paolo


soluzione. 
Parole sante! :) Il problema comunque, e' anche l'opposto - la pratica
non tiene in considerazione la teoria: tranne ovviamente in casi come
quello che tu citi - in cui e' l'esperienza e la capacita' del designer a
decidere di usare una "pezza" oppure no -  l'applicazione di tecniche
"giuste" spesso non comporta costi pratici particolarmente superiori
(certo, c'e' ancor oggi chi l'analisi non sa nemmeno cosa sia, ma questo
e' un altro paio di maniche :). 


   manuale di stile". 
Ne ho visto una recensione molto positiva qualche tempo fa - ma (a parte
il fatto che dove vivo e' un pelo faticoso far arrivare libri italiani)
mi e' fisicamente mancato anche solo il tempo di *pensare* di comprarlo
:( 
Saluti,
 cs


e' un altro paio di maniche :). 
Fosse solo dell'analisi (cosa comunque fondamentale) che non si tiene conto...
Saluti,
Paolo
P.s.
   Comunque tutto questo mi sembra OT rispetto al subject (e anche al NG)!


supporto a feature "avanzate", etc. 
Anch'io ho avuto una certa esperienza con TP (la 5.5), ricordo che la
cosa che mi piaceva era il livello di astrazione, niente dettagli tipici del
C++ e questo ti permetteva tempi di disegno e soprattutto di sviluppo
piu` brevi. Oggi mi sembra che l'object pascal di delphi si sia molto avvicinato
al C++, ma non saprei dire in quali termini cio` e` stato (o viene) pagato.
Saluti,
Paolo


   Comunque tutto questo mi sembra OT rispetto al subject (e anche al NG)!
Si, ho spostato il thread a it.scienza.informatica.software-eng (che spero 
nel frattempo ti sia arrivato).


     in C++ (sempre con il rischio di arrivare secondi).
Be', i sistemi realtime sono una brutta gatta da pelare - e certo come ho
detto piu' volte java non e' certo adatto. Il punto e' che anche C++ puo'
avere problemi - talvolta C, e su un sistema operativo adatto (e non NT!
:) - e' l'unica soluzione. Inoltre la 1) purtroppo puo' non servire a
nulla, per i realtime. Comunque non ne ho mai seguiti di progetti cosi'
quindi la mia conoscenza e' puramente accademica.. :( 
Ciao,
    Cris
