Newsgroup: it.comp.lang.c++
Titolo: Passaggio da C++ a Java

Se qualcuno è esperto di entrambi i linguaggi, vorrei chiedere 
qualche parere, tipo :
Quali mancanze strutturali ha notato in Java, rispetto al C++ ?
Quali, tra le suddette, gli risultano meno facili da 
affrontare-integrare, costringendolo ad accrocchi e workarounds 
incasinati ?
In quali contesti (genere di applicativi) si fa sentire di più 
la mancanza delle features suddette ? (ed. generici programmi 
GUI, programmi di calcolo, grafica, multimedia, database, server 
web, client web, altro che non mi viene in mente) ?
ah ... ammesso che esistano, ci sono ambiti (sia intesi come 
genere di applicativi, che come paradigmi di programmazione), in 
cui invece si è trovato meglio in Java che in C++ (che so, più 
facile gestione memoria ... è l'unica cosa che so di Java)
ciao
soviet_mario

 Quali mancanze strutturali ha notato in Java, rispetto al C++ ?
1. mancanza di allocazione statica (il che impedisce una corretta
implementazione dell'idioma RAII);
2. garbage collection (la gestione e il consumo di memoria dell VM
java è abbastanza bizzarra);
3. mancanza di template (bisogna spesso ricorrere a strani giri di
cast, con i container di libreria e i generics sono stati inseriti
solo ultimamente);
Le prime tre che mi vengono alla mente e che sono legate al
linguaggio, perché se si sconfinasse nel mondo delle implementazioni
(con tutti i problemi dovuti alle incompatibilità tra app server in
campo J2EE) non si finirebbe più...
Con le implementazioni Java si è riusciti col tempo persino a sfatare
il mito "write once, run everywhere".

 il mito "write once, run everywhere".
quest'ultima è una pecca che riguarda gli applcativi un po' 
diciamo avanzati/specifici di librerie particolari, o si estende 
anche a applicativi di base che usano solo il "core centrale" 
della JVM standard ... se il concetto ha un senso ?
ciao
Soviet

diciamo avanzati/specifici di librerie particolari,
Il modello di distribuzione delle applicazioni, in Java, è abbastanza
particolare, ma sarebbe inappropriato stare qui a scendere nei
dettagli. Dico solo che quella che è l'apparente portabilità assoluta
del linguaggio viene di fatto annullata dalle peculiarità delle
singole implementazioni.

 ... è l'unica cosa che so di Java)
L'unica attrattiva e' la promessa di far girare lo stesso identico 
prodotto ovunque, ma si noti che non e' mantenuta al 100%.
  bye
	av.

 solo ultimamente);
Dal poco che ho visto di java, è più un problema di implementazione
degli stessi (dovuta peraltro alla retrocompatibilità, da quel che ho
capito....)

 Se fosse bene implementato, sarebbe un plus del java sul c++.
Già: se fosse ben implementato. Ma in ogni caso non vedo la gc come un
plus rispetto a un linguaggio che ha allocazione statica e distruzione
deterministica. Certo, se bisogna scegliere tra un linguaggio in cui
un programmatore è costretto a deallocare un puntatore pena creare
casini immensi ed uno in cui si è dispensati da questa operazione (e
quindi dai casini immensi derivanti), scelgo il secondo. Il fatto è,
però, che si può rendere C++ somigliante a Java, sfruttandone le
caratteristiche buone, mentre non si può rendere Java somigliante al C+
+.

 sul resto potrei anche passare sopra, in certi contesti.
Io ho testato sulla mia pelle la reale impossibilità di compiere
operazioni "memory-consuming" in Java. Il problema nasce quando il
consumo di memoria è tanto, ma è controllato e si presenta a
intervalli regolari (quindi il consumo di memoria è ingente ma non si
rischia mai di esaurire la memoria). Un caso tipico è quello di
calcoli eseguiti per via ricorsiva; a me è capitato di essere
costretto (e sottolineo costretto) a dover rivedere per via iterativa
degli algoritmi che in Delphi o in C++ non avrebbero dato alcun
problema, nonostante i consumi ingenti di memoria. In Java la VM
alloca, alloca, alloca e non dealloca, dealloca, dealloca. Almeno, non
al passo col procedere delle operazioni. Avere la distruzione
deterministica è, in molti casi, indispensabile.
IMHO, ovviamente.

 deterministica è, in molti casi, indispensabile.
Ma in Java non hanno messo un ciambellone di salvataggio per 
controllare più "strettamente" il funzionamento della GC? Cose tipo, 
*adesso dealloca, perdinci".
Se non lo hanno fatto i progettisti di Java vivono in un mondo di 
cristallo tutto loro.
-- 
Un libro da pausa caffè: 
http://research.microsoft.com/~daniel/uhh-download.html

*adesso dealloca, perdinci".
Hai solo modo di invocare esplicitamente il garbage collector che
potrebbe benissimo fregarsene di deallocare alcunché... :-(

 capito....)
Non è un problema di *implementazione*. E' un problema di design.
Non è che chi ha progettato il linguaggio ha detto 10 e chi lo ha
implementato ha fatto 4. E' che proprio sono stati progettati storpi. E
sono stati progettati tanto per eliminare un difetto marchiano di Java:
te la menano con i tipi all'inverosimile e poi ogni volta che ficchi
qualcosa fuori e dentro da un ArrayList (o analogo) devi metterti li a
fare dei cast. Il che ovviamente è sgradevole, da cui i generics.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 emulare) dai templates
Ecco, per dire una cosa così non è fattibile:
template<typename T>
T foo() {
  T t;
  return t;
}
Questo per dire quanto facciano schifo.


 Quali mancanze strutturali ha notato in Java, rispetto al C++ ?
Diciamo che se Java non offrisse ottimi strumenti di sviluppo e non
fosse il beniamino di buona parte del mondo business si meriterebbe di
essere ignorato e seppellito.
Sfortunatamente è troppo usato per essere ignorato e seppellito. E
complessivamente proprio per il fatto che è molto usato hanno pezzato il
linguaggio con ottimi IDE. Ora è un bene avere ottimi strumenti di
sviluppo, ma nel caso specifico è come vendere macchine che non sterzano
e risolvere il problema aggiungendo ai bordi delle strade dei cosi tipo
autoscontro per permettere di cambiare direzione.


 linguaggio con ottimi IDE. 
Uso java per lavoro .... non lo amo .... ma mi sembra un po esagerato il
giudizio negativo sul linguaggio .... alla fine... di primo acchito ....
nn mi sembra poi così malaccio ...e per esempio le enum di java 5 le
trovo molto carine :) 


 trovo molto carine :) 
Dipende cosa hai provato di alternativa. Anche Fortran  nel 5x non era
malaccio.
Il problema di Java è che è un linguaggio concettualmente *vecchio*
spacciato per il non plus ultra della modernità.
Dopo di che le enum di Java 5 non mi pare che abbiano molto di più delle
enum (che pure non si chiamano enum) di Pascal, per dire. E poi voglio
dire... non è che giudico un linguaggio dalle enum :)
Ho lavorato con diversi linguaggi, e posso dirti che già il semplice
fatto che Java sia sostanzialmente inutilizzabile senza un IDE decoroso
dovrebbe fare pensare a lungo. Attenzione, questo è un discorso diverso
dal 'un IDE è comodo': è un discorso del tipo 'senza è un suicidio'.
Di programmi C e C++ su vim ed emacs ne ho affrontati parecchi
(tipicamente nelle occasioni in cui è necessario lavorare in remoto su
workstation unix è assolutamente comodo). Vim ed Emacs per quanto
abbiano una curva di apprendimento ripida sono decisamente ben
attrezzati per C++ e ancora più per C. Si fa. Qualcuno trova più comodo
un IDE? Ottimo. Ma il punto è che Java senza è quasi inaffrontabile.
Ci sono errori di design nella libreria standard (vatti a ricordare se
per un dato contenitore è size, length, add, addElement o whatever). Da
cui il completamento non è una comodità: è una necessità.
Il mondo di Java è la sovraignegnerizzaizione presa a principio
costitutivo architetturale standard. 
Ora non voglio stare a dire che C++ è perfetto. Per dire le enum sono
precisamente migliori in Java (ah, retrocompatibilità con C...). Ci sono
altri piccoli particolari di C++ che vorrei cambiati (sempre
ipoteticamente). Tuttavia non esiste paragone. 
Vero è che un programmatore incapace con C++ è possibile che si impicchi
molto prima che con Java (un programmatore capace è per definizione
capace). Allo stesso modo non mi piace la semantica dei throws
dichiarativi di C++: preferisco quella di Java, solo fosse
disabilitabile tramite #pragma o altre opzioni di compilazione. 
Ma globalmente il problema di Java è che in tanti pensano che sia
veramente figo: il punto è che fa decorosamente il suo mestiere
principalmente per i fondi investiti e per  una congiuntura astrale
sfavorevole. 


 costitutivo architetturale standard. 
Sono troppo d'accordo :)

 Sono troppo d'accordo :)
:P


 trovo molto carine :)
Diciamo che più che "carine", somigliano (finalmente) a quelle di
altri linguaggi.
Il problema è che, per molte persone (me compreso), le caratteristiche
di Java 5 non sono semplicemente utilizzabili.
E questo perché, nel mio caso specifico, i server aziendali del
cliente presso il quale presto consulenza sono certificati per l'uso
di una determinata versione del software e l'assistenza non ti viene
garantita per versioni successive. Quindi, si è costretti a restare
alla versione precedente della virtual machine, versione di Java per
la quale, peraltro, esiste una montagna di codice in cui le enum -
tanto per dirne una - sono realizzate con dei mostri inguardabili.

 costitutivo architetturale standard. 
Questa me la segno :-)
  bye
	av.