Newsgroup: it.comp.lang.c++
Titolo: Un parere sul C++ e Java

Ho letto il messaggio "perche' C++?" ed il parere di
Alex Martelli sulle notevoli differenza tra Java e C++
Non sono un esperto di C++ e Java, data la mia giovane
eta', ma il mio vuole essere solo un parere.
Java ' stato il primo linguaggio di programmazione che ho mai
utilizzato. Era molto bello e mi veniva naturale
usarlo dato che in pratica ti "costringe" a pensare ad oggetti,
cosa che il C++ ti lascia la "possibilta'" di fare, ma non 
ti obbliga.
Da quando ho iniziato a programmare in C++ mi sono accorto
che il programmatore ha il potere di "farsi male" quanto
vuole, utilizzando costrutti molte volte incomprensibili
ed incorraggiando stili di programmazione che si discostano
molto dai concetti OOP di base. Naturalmente una buona
conoscenza del linguaggio, che puo' richiedere anni
di studio e decine di libri, fanno del C++ il migliore
amico del programmatore.  
L'ereditarieta' multipla, le funzioni e le classi friend, 
molti sono i costrutti che in Java sono stati aboliti.
In C++ posso scrivere:
while(i--) printf("Conto alla rovescia: %d", i);
e
while(*p) *p2 = *p++;
mentre in java:
while(i-- != 0) System.out .......
e 
while(p[i++] != 0) p2[i] = p[i];
che personalmente mi sembrano piu comprensibili.
Dobbiamo parlare di come e' implementato il multithreading?
Be, io dopo 2 settimane SENZA ALCUNA ESPERIENZA DI PROGRAMMAZIONE,
in java sono riuscito a scrivere il mio primo stupido programmino
multitreading. Ora, a distanza di un paio di anni sto
provando a scrivere roba multihreading in Win32 e che lo ha
fatto sicuramente capira' cosa sto dicendo.
Naturalmente inutile parlare del fatto che il Java NON vuole
sostituire il C++.
Se Java fosse derivato dal C++, si presume che sia un C++ molto
migliorato, vero? Di conseguenza lo scopo per cui sarebbe stato
creato e' quello di scalzare il C++ da linguaggio di prog. eletto.
ASSOLUTAMENTE NO.
Java e' stato pensato per un motivo ben preciso. Lo scopo 
dei ceatori du questo "caffe'" era quello di creare un 
linguaggio SINTATTICAMENTE SIMILE al C, che eliminasse
parecchia di quella che io definisco TROPPA LIBERTA' che
il C dava agli sviluppatori e che fosse multipiattaforma.
Una volta eliminata la gestione della memoria ed i puntatori,
l' 80% degli errori tipici dei programmi C++ e' stata eliminata.
Le prestazioni ne risentono, il bisogno di memoria libera aumenta,
ma ricordiamo che in Java i puntatori esistono, anche se 
sono esplicitamente deferenziati dal linguaggio. I cosiddetti
reference, non sono altro che dei puntatori, dato che in Java
tutti gli oggetti sono passati per riferimento.
Come conclusione quindi voglio dire che i due sono linguaggi
creati per soddisfare esigenze diverse. SONO DIVERSI.
E' da pazzi cercare di creare un programma al limite delle
prestazioni in Java, ma e' anche molto difficile scrivere un
programma multipiattaforma il C++.
Personalmente amo ed utilizzo entrambi i linguaggi.
Stefano Cristiano

sono esplicitamente deferenziati dal linguaggio.
I puntatori sono presenti in tutti i linguaggi, solo che alcuni
(java, lisp, basic...)  li rendono invisibili ai programmatori proprio
per evitare le difficolta` connesse ad essi.
Ovviamente la cosa ha un prezzo, niente e` gratis (almeno nel
mondo dell'informatica)!
Paolo

I puntatori sono presenti in tutti i linguaggi, solo che alcuni
Che assolutismo...!  Hai mai programmato in Fortran  IV o
Fortran '77...?
Java, Basic, ecc, i puntatori "li hanno", d'accordo -- senza
aritmetica (roba da C), ma li hanno.  Ma il Fortran...?  Giusto
per evitare il tipico depistaggio: no, neppure gli argomenti
passati per riferimento -- la semantica degli argomenti e`
per "value/return" (con divieto di alias per permettere a ogni
dato compilatore di _implementarli_ come reference, se
occorre ed e` opportuno).
Fortran e` stato il primo linguaggio di alto livello, e fra i
piu` diffusi almeno sino a pochi anni fa (probabilmente anche
oggi, considerando che mazzo si sono fatti alla Cygnus per
integrare anche il compilatore fortran in quello che era un
tempo un compilatore solo C/C++).  Non e` quindi qualcosa
che si possa trascurare nel fare simili affermazioni
eccessivamente generali.
Alex


[omissis]
In effetti non conosco il Fortran, tuttavia stento a crederci... 
come cavolo fanno con le prestazioni quando si passano
argomenti grossi alle funzioni?

argomenti grossi alle funzioni?
Gli "argomenti grossi" possono essere solo array.  La semantica
che il linguaggio garantisce e` "COME SE" l'array venisse copiato
in input, modificato in copia locale, e copiato nuovamente all'uscita
dalla funzione.  Ma, come dicevo, il linguaggio _vieta_ inoltre di
avere qualsiasi tipo di alias; cioe`, se un array e` passato come
argomento a una procedura, quella procedura non puo` accedere
a quello stesso array attraverso _nessun_ altro nome -- ne`
quello di un altro argomento, ne` quello di un common (le "variabili
globali" del fortran classico); se lo fa, il programma non e`
corretto, e il compilatore non e` tenuto a diagnosticare l'errore.
Questa semantica e` cosi` precisa e rigida proprio per permettere
qualsiasi tipo di ottimizzazione appropriata per la macchina in uso.
Ad esempio, su di un supercomputer, un array puo` spesso
fruttuosamente essere passato in un "registro vettoriale" (copiato
in input nel registro vettoriale stesso, ivi elaborato, copiato di
nuovo in memoria come risultato a fine procedura).  Su di un'altra
macchina, la copia del vettore in entrambi i versi puo` essere
sostituita da una qualche forma di passaggio per indirizzo, e la
cosa resta trasparente a programmi Fortran corretti.  Ricordo
un compilatore Fortran per Transputer che usava le connessioni
ad altissima velocita` fra le molteplici CPU per questi passaggi,
ad esempio, per cui gli argomenti NON erano "in memoria" da
NESSUNA parte -- erano "in transito" sulle connessioni veloci
(la CPU "di arrivo", che eseguiva la subroutine, poteva trattare
i primi elementi arrivati, e rispedire i risultati, mentre altri ancora
continuavano ad arrivare).
Molti programmatori Fortran non conoscono abbastanza bene
il linguaggio da capire questa semantica, e _credono_ che il
passaggio sia definito come "per riferimento"; questi tendono
a subire opportune docce fredde le prime volte che provano a
girare i loro programmi su supercomputer/macchine vettoriali/
macchine ad altissimo parallelismo/eccetera.  Il "supercalcolo"
(anche contando sia il vettoriale, sia il parallelo) e` e resta una
"nicchia", piccola rispetto al mercato "generico"; ma e` una
nicchia che ha grande importanza proprio per i tipici utenti di
Fortran -- programmatori scientifici che devono fare delle
elaborazioni, con calcoli estremamente pesanti, su strutture
dati tipicamente molto semplici (vettori, matrici, ecc).  In questo
ambito, "mostrare" al programmatore, sotto qualsiasi forma
(anche non esplicita, ma legata alla semantica del linguaggio,
come ad esempio in Java), degli "indirizzi", costituirebbe un
pesante vincolo rispetto alle ottimizzazioni possibili.
Alex

Personalmente amo ed utilizzo entrambi i linguaggi.
Oh, anch'io, e, come dicevo, altri ancora (beh -- magari
senza "amarli", ad esempio, il VB, pero`, rispettandoli
per quello che fanno veramente bene...:-).
Ma tornando alla questione originale, quella del primo
linguaggio da imparare: mi pare che la tua fortunata
esperienza con Java non sia casuale, e che si tratti di
un linguaggio veramente buono per cominciare -- ci
vorrebbe, magari, il "libro giusto" (tu quale hai usato?).
Alex

generica.  Avere un solo paradigma privilegiato puo` certo
Non mi e` chiaro... che differenza c'e` tra OOP base e "avanzata"?
-- 
Gargamella alias Massimo Lauria

Non mi e` chiaro... che differenza c'e` tra OOP base e "avanzata"?
Questione di gradi; la programmazione OOP piu` "avanzata" (non
necessariamente un termine "positivo"... si potrebbe altrimenti
chiamarla "complicata"...!-) comprende ad esempio l'uso di basi
virtuali ed altri schemi di eredita` multipla, spesso congiunti ad
operazioni di "navigazione" dinamica entro la gerarchia delle classi.
Gran parte di testi come "Design Patterns" (Gamma et al) o
"Advanced C++" (Coplien) e` dedicata a queste complessita`.
Mentre schemi del genere si giustificano, e con ampio ritorno,
a fronte di esigenze commensurate, tanti compiti di programmazione
si affrontano bene anche con paradigmi di OO piu` semplici,
"di base" -- semplici polimorfismo, incapsulamento, delegazione,
eredita`.
Alex