Newsgroup: it.comp.lang.c++
Titolo: Riprendere in mano C++....

Salve a tutto il ng,
premetto che è da parecchio tempo che ho abbandonato C++ per utilizzare 
Java, sebbene C e C++ siano stati i miei "primi amori" informatici. Sebbene 
Java sia il mio pane quotidiano, vorrei ricominciare uno studio serio di 
C++.
Vorrei da voi un consiglio su come riprendere in mano, con un buon testo di 
riferimento, questo linguaggio con un occhio di riguardo alla STL. Il tutto 
sarebbe per cultura personale, dal momento che in azienda utilizzo J2EE...
Vi vorrei porre una domanda, sperando soprattutto di NON passare per 
provocatore: oggi come oggi, qual'è il mercato del C++ ? Con la concorrenza 
di C#.NET e Java, ha ancora senso per un professionista investire il proprio 
tempo in C++ ? Secondo me sì: ma vorrei avere da voi un parere su questo 
argomento.
Ringrazio chiunque vorrà rispondermi !
Saluti,
    Scorpio. 

 
Nel mio campo la quasi totalita' del codice e' scritto in C++ (anche se 
molto e' in "modo C", ossia non sfrutta a fondo le caratteristiche del 
C++) per piattaforme Windows e Linux, alcune parti sono in C (solo 
quelle per DSP) e alcune parti critiche sono ottimizzate con codice 
assembler inline con istruzioni MMX e SSE.
E' piuttosto facile dedurne che, per il tipo di applicazioni che 
sviluppiamo, Java non ha prestazioni accettabili e .NET puo' essere 
usato solo per applicazioni non time-critical.
In altri campi il linguaggio C++ e' necessario spesso soprattutto per 
mantenere lo sviluppo di codice "legacy" (in questi casi magari un 
passaggio a C# sarebbe fattibile, a patto pero' di riscrivere buona 
parte del codice pre-esistente!).
--
Roal Zanazzi

> investire il proprio tempo in C++ ? Secondo me sě: ma vorrei avere da voi 


 argomento.
Il mercato c'è eccome. C++ (e C) sono comunque linguaggi usatissimi, per
certi versi *molto* interessanti. C'è un sacco di codice scritto in
questi linguaggi.
Si trova lavoro, e spesso lavoro anche ben pagato (a patto di avere
un'adeguata esperienza, in generale formare un programmatore C++ è ben
più costoso di formare un programmatore Java, per ovvie ragioni).
Comunque esiste un'altro ordine di considerazioni: spesso non conviene
imparare un linguaggio perchè "serve". Imparare un linguaggio offre un
nuovo strumento concettuale per imparare a risolvere certi problemi (o
vecchi problemi in modo diverso). Rende la mente più elastica e mostra
nuovi aspetti.
Al momento sto studiando D ed OCaml. Penso che non li userò *mai* sul
lavoro (e non certo per demeriti dei linguaggi... D è un linguaggio
"simile" a C++, che fa tesoro dell'esperienza di Java, ma anche di
linguaggi come Python e mostra come avrebbero potuto essere Java e C++
se... vabbè). OCaml è un bel linguaggio funzionale che mi ha davvero
colpito. Ben fatto, ha un sacco di features interessanti. Ecco, questo
forse potrebbe servirmi a breve nel caso in cui lavori su CIL (che è
scritto appunto in OCaml). 
Francamente spero di no. Mi sono appena dovuto improvvisare
programamtore Prolog... comunque.
Imparare anche un linguaggio dinamico ben fatto di alto livello come
Ruby o Python apre ulteriormente la mente (con il vantaggio che quello
lo userai *per davvero* in moltissime situazioni reali.. alla fine quasi
tutto quello che faccio per me è in Ruby o Python -- beh, anche un po'
di ObjectiveC, ma ora che con Leopard infileranno RubyCocoa e PyObjC
dentro l'OS, ne vedo sempre meno il bisogno).
-- 
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.

 sarebbe per cultura personale, dal momento che in azienda utilizzo J2EE...
Rispondo volentieri alla tua domanda in base alle mie esperienze di lavoro.
Dopo l'università ho lavorato per alcuni anni come analista/programmatore
esclusivamente Java, arrivando negli ultimi anni ad occuparmi in modo
approfondito anche di progetti basati su elementi avanzati di J2EE
(gestionali con EJB e tant'altro).
Da vari mesi - dopo tante insistenze, studi da "autodidatta" e tante porte
chiuse in faccia - sono riuscito a cambiare lavoro e ambito tecnologico: ora
mi sto occupando, tra le varie cose, di processi video real time su unix.
Nei primi giorni, non conoscendo il c++, e "spaventato" dalla difficoltà che
si vocifera sul linguaggio, ho pensato ingenuamente di usare le librerie JMF
messe a disposizione dalla Sun (per modo di dire, in realtà Sun non mette
praticamente nulla di gratuito a disposizione) ; il risultato è stato
disastroso: librerie che funzionano da schifo e con limiti strutturali,
oltre che di prestazioni, evidenti (qualcuno dirà, giustamente "beh, ma
dovevi aspettartelo che il java è inadatto per questo tipo di applicazioni":
questo è vero, ma voglio arrivare ad un altro punto).
L'impossibilità di usare il Java mi ha obbligato ad optare per il c++: ho
dovuto quindi, prima, per circa tre settimane studiare tutto il linguaggio
(anche se, per fortuna, dall'università avevo già un'infarinatura sul C,
specie sui puntatori), poi ho dovuto fare vari test (e in quel caso ho
penato non poco, specie per le fasi di debugging, assai più difficoltose del
java); infine ho dovuto lavorare concretamente al progetto dell'azienda,
affrontando un mare di problematiche non legate allo standard c++ ma a
posix. Dopo questa faticaccia, il risultato (vale a dire: toccare con mano
cosa si può fare in c++) mi ha lasciato semplicemente a bocca aperta.
Nota bene un particolare: l'azienda in cui lavoro ha permesso l'investimento
sull'apprendimento del C++ non solo perchè era necessario al progetto, ma
anche perchè la sua situazione economica lo permetteva; e non solo: per far
rientrare il mio lavoro in tempi ragionevoli ho dovuto per conto mio
lavorare sul linguaggio in ore aggiuntive (vale a dire: quest'anno mi sono
rovinato le vacanze e parecchi sabati) in cui sbattevo la testa con continui
bug su puntatori, segfault e via dicendo, tutta roba che fatta per studio è
un conto, mentre per lavoro è tutto un altro paio di maniche.
Cinque mesi di sudore buttato sull'apprendimento "sul campo" del linguaggio,
ma che soddisfazione! Lo so che scatenerò un mare di polemiche, ma fino ad
ora non ho visto UN SOLO progetto serio scritto in Java (e ho lavorato a
tanti progetti; inoltre ho amici che a loro volta lavorano ad altri progetti
in java e credo che sia significativo il fatto che anche tu possa avvertire
l'esigenza di "cambiare aria").
Viceversa ho visto in C++ un mondo che praticamente ignoravo, fino ad
arrivare al piacere di fare un'applicazione embedded per linux.
Non è un caso il fatto che in Italia, così mal propensa ad investire su
progetti ad alto contenuto tecnologico, si facciano mille lavori del kaiser
in Java per web, mentre quando si parla di C++ su unix sembra fantascienza
per tanti; non è un caso che nelle facoltà di ingegneria informatica non si
insegni il C++ (a favore del Java... bella roba! I progetti in C++, da che
mi ricordo sono solo per alcune tesi di laurea.. e stiamo parlando di ING.
INFORMATICA!!); di conseguenza, la richiesta per il C++ è quella che è,
mentre per il java è tutto un fiorire di lavoretti "alla svelta" e progetti
malfunzionanti. Senza contare che, a dispetto di un equivoco generale tanto
diffuso, il java di utilità lavorativa ( = J2EE) di gratuito non ha
assolutamente NIENTE.
Quando tu scrivi:
" Vi vorrei porre una domanda, sperando soprattutto di NON passare per
provocatore: oggi come oggi, qual'è il mercato del C++ ? Con la concorrenza
di C#.NET e Java, ha ancora senso per un professionista investire il proprio
tempo in C++ ? "
ti rispondo così: per me il problema non si pone; attualmente lavoro in c++
e ne avrò ancora per un bel po'.
Se dovessi iniziare a lavorare su un nuovo progetto java, piuttosto emigro
(dico sul serio) senza aspettare un secondo: di roba gestionale per web
scritta in quel linguaggio (da quattro soldi, permettimi di dirlo, per non
parlare di C# e roba simile) ne ho piene le scatole. In definitiva, il
consiglio che ti do è di non mollare, se ci tieni, in questo tuo
investimento. Sappi però che, come è successo a me, potresti vederti
chiudere tante porte prima di trovare lo "spiraglio" che ti permetta di
cambiare "universo" lavorativo. Oppure vai da subito all'estero;
non so dove vivi, ma in generale in Italia, a parte pochissime zone (guarda
caso quelle in cui l'economia va ancora bene):
1) la quantità di lavori in c++ è estremamente esigua
2) se tu "punti" qualche azienda, il fatto che tu abbia notevole esperienza
e competenza in JAVA equivale a poco più di nulla per chi deve INVESTIRE
assumendoti in qualche progetto per C++ (anche se nel curriculum ci metti
che conosci Struts, Oracle, EJB e quello che ti pare.. caso mai dettaglia
bene la tua tesi scritta in C++) . Più che altro devi mostrarti davvero
motivato a voler optare per questo linguaggio, in questo modo fai buona
impressione.
Se poi insisti parecchio, come ho fatto io, alla fine la cosiddetta "porta"
riesci a trovarla (e io l'ho trovata in extremis: ormai ero lì lì per andare
all'estero). Una volta entrato in questo mercato di nicchia, e dopo aver
fatto la tua buona esperienza, è vero che le aziende sono in numero assai
minore di quelle che lavorano su J2EE ma ti pagano meglio e ti assumono
assai facilmente (perchè a quel punto non devono più correre il rischio
dell'investimento sulla formazione).
Cmq, nel concreto, ti indico un percorso, per gli studi, da seguire:
1) inizia con qualche manuale di "transizione" da un linguaggio ad un altro
(ti semplificano enormemente le cose e io purtroppo li ho scoperti tardi):
questo che ti linko mi è sembrato ottimo:
wwwagse.informatik.uni-kl.de/teaching/se1/ws2003/cpp_tutorial.pdf
2) prosegui con qualche manuale completo: in questo caso "Programmare in
C++" (
www.archimagazine.com/bookshop/lvsteve2.pdf
) è ottimo. Vedrai che se
hai studiato bene quanto indicato nel punto 1) studierai quest'ultimo
manuale in tempi molto molto rapidi.
3) "Digeriti" i punti 1) e 2) abbi come riferimento (non da studiare, ma da
avere come riferimento) un manuale ultracompleto: in questo caso va bene
Thinking in C++ (che trovi in rete)
4) Passa quindi al C++ non standard (con quello standard ci fai ben poco di
utilità pratica); l'OS lo scegli tu, ma io ti consiglio di buttarti su API
POSIX; comincia a smanettare su (butto giù alla rinfusa) processi, fork,
socket, thread , libtools, MakeFile (che trovi in parte anticipato nel
manuale del punto 2), scrivendo magari la tua applicazioncina che fa uso di
tutte queste belle cose....
5) passa quindi a qualche libreria per costruire GUI (Gtk, Qt, etc.)
Questi mi sembrano i passaggi obbligati; come puoi intuire il percorso è
tutt'altro che semplice... molto dipende dalla tua volontà, dalla tua
passione e dalla tua pazienza. Poi vedrai che le soddisfazioni non sono
poche.
Ribadisco (almeno in base alle esperienze che ho vissuto, poi forse mi
sbaglio) quanto detto prima: puoi tranquillamente scordarti che le aziende
che lavorano a progetti in C++ considerino significativa un'esperienza
consolidata in Java. Per questo motivo: olio di gomito e tanta pazienza.
in bocca al lupo,
L
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

utilità pratica); 
Che cos'è il "C++ non standard" ? :-)
Per un'ottima conoscenza del C++ bisogna *PROPRIO* studiare il
linguaggio nella sua veste standard.  In più, si dovranno apprendere
le estensioni di ogni compilatore, per lo sviluppo su una determinata
piattaforma...

 linguaggio nella sua veste standard.
A questo punto inizio a capire con che tipo di interlocutore ho a che
fare.... e capisco anche il perchè dell'atteggiamente da moralista java
stizzito da parte di chi casca dalle nuvole a sentire parlare di C++
standard e C++ non standard...
saluti eh,


 Java, in passato.
m'era quasi sfuggito un "particolare".
Come mai hai tralasciato, nel quoting
1) l'indecenza che nelle facoltà universitarie (anche in ING.
INFORMATICA!!!!) non si insegni il C++ ?
2) il fatto che Java sia grauito solo a chiacchiere (vedi J2EE) ?


 2) il fatto che Java sia grauito solo a chiacchiere (vedi J2EE) ?
Mai avuto a che fare seriamente con J2EE ma in che senso non e' gratuito
? servlet container JSP etc direi che sono gratis ci sono componenti che
fanno parte della specifica che non hanno un implementazione gratuita ?
senza polemica non lo so.

 ad uno non interpretato.
Questo e' evidente penso che lui si riferisse alla sintassi.
Detto questo a meno che tu non viva di puntatori non vedo queste immense
differenze nell'utilizzo. Un linguaggio interpretato (o se vuoi puoi
anche compilarlo in nativo con qualche tool) ti semplifica spesso la
vita.
-- 
Ciao
Wezzy

 standard e C++ non standard...
Io non cado dalle nuvole e non sono un moralista Java.
Rileggi quello che ho scritto.

 senza polemica non lo so.
Io sto usando una JVM gratuita (Sun), un application server gratuito e
che rispetta le specifiche J2EE (JBoss) e un sistema di sviluppo
gratuito (Eclipse).

 scritto appunto in OCaml)
Mi son letto anche io un po' di OCaml e ha features carine ma la
sintassi e' a mio avviso proprio bruttina! Se non l'hai gia' visto dai
un occhio a questo:
http://caml.inria.fr/pub/docs/tutorial-camlp4/index.html
PS mi scuso con tutti per l'OT

 Il 06 Ott 2006, 21:33, "Scorpio" <_scorpio@_NO_SPAM_libero.it> ha scritto:
[...]
E dove lo mando il curriculum? ;-)
Ciao,
Nicola

 senza polemica non lo so.
Ignori che un container di servlet non è equivalente ad un container per
ejb. Nel secondo caso (che appunto corrisponde a progetti di grosse
dimensioni) gli strumenti gratuiti sono del tutto inadatti (almeno fino ad
un anno fa).
probabilmente non lo sa neanche l'altro interlocutore del thread, che
sostiene di poter lavorare su un progetto J2EE di grosse dimensioni
utilizzando JBOSS.
Purtroppo le trappole commerciali del Java ben riescono in questo: sfido
chiunque a far funzionare (ripeto: a far FUNZIONARE) un gestionale
distribuito - di grosse dimensioni - con ide open source, unix , mysql e
JBOSS. Noi ci abbiamo provato per un po' e alla fine, per disperazione siamo
tornati ai soliti mix di jdeveloper, windows, oracle e oc4j (cioè l'antitesi
dell'open source). Mi chiedo che tipo di esperienza pratica abbia l'amico e
dubito seriamente che possa aver lavorato in concreto con gli EJB (e qui sto
andando off topic: motivo in più per chiudere definitivamente la
discussione)...


discussione)...
Fammi un piacere: taci e torna a parlare di questi argomenti quando ne
saprai *almeno* qualcosa, nel ng giusto e nel thread giusto.

 Perche' cos'ha che non va un linguaggio interpretato?
Come persona di mezza età preferisco il C++ perché così rimango ancorato a
vecchie conoscenze. Ho fatto programmi di discreta complessità in Python e
non avuto problemi, in 
dot.net
 ho tuttora grossi problemi con il GC.
Più che interpretato si, interpretato no, le vere domande, per me, sono: 
Quali sono i limiti dei linguaggi che usano il GC?
Quali sono i limiti delle macchine virtuali che eseuono il pcode?
Ppoi, per me, troppa astrazione rende i programmi di un certo livello
impredicibili. Cosa fa un record set disconnesso quando qualcosa va male,
per esempio, è qualcosa di misteroso, ed è pure un mistero che ritengo
inutile indagare. Per certi versi con il vecchio VB6 avevo molti meno
problemi e comunque erano noti, che 
dot.net
. Non conosco più Java, ma
sospetto sia un macchinone stile 
dot.net
.
Ciò che mi piace del C/C++ è che ho l'illusione di tenere sotto controllo
tutto. Sopratutto il consumo di memoria e di CPU, mi verrebbe da dire in
questo periodo della mia vita lavorativa.

 sospetto sia un macchinone stile 
dot.net
.
Dai un'occhiata a Erlang, giusto per curiosità.
Kiuhnm

 Eh che perle di saggezza....
Questo tuo tono ironico mi indispone francamente ... 
Tanto piu' che se l'avessi capita tanto tempo fa questa "perla di
saggezza" avresti compreso meglio perche' hai studiato e cosa ti han
fatto studiare ... Soprattutto ad ingegneria poi!! magari ci sono
facolta' piu' orientate alla programmazione o anche gli ITIS devono
insegnarti a butar giu' codice ma decisamente non e' lo scopo che si
prefigge un ingegneria.
-- 
Ciao
Wezzy

 
http://caml.inria.fr/pub/docs/tutorial-camlp4/index.html
Mi fai un riassuntino (magari in mail che qua si rompe le palle per
nulla a tutti -- nome punto cognome at gmail punto com).
Esattamente non ho capito che fa, gli ho dato solo un'occhiata di
sfuggita.


 ad uno non interpretato.
Non conoscevo fra le definizioni di "avere buon senso" quella secondo
cui uno non sa quello di cui parla.
Per esempio Pascal è stato a lungo tempo usato come linguaggio
"interpretato" (anche se a me non piace confondere le soluzioni
interpretative pure con quelle a bytecode). Il compilatore generava un
p-code e poi una macchina virtuale eseguiva il p-code.
Oggi Pascal viene generalmente compilato in codice macchina nativo. 
Quindi dove è "l'essere un'altra cosa"? Pascal è un'altra cosa rispetto
a Pascal? Il linguaggio è lo stesso.
Java in compenso può essere compilato. gcj per esempio è in grado di
farlo.
"GCJ is a portable, optimizing, ahead-of-time compiler for the Java
Programming Language. It can compile Java source code to Java bytecode
(class files) or directly to native machine code, and Java bytecode to
native machine code."
Questo ti fa diventare di colpo Java un'altra cosa (e no, a me Java non
fa certo impazzire).
ObjectiveC, di livello molto più alto di Java e molto più dinamico è
completamente compilato in codice macchina (anche se nulla vieta di
interpretarlo, nonostante a me non risulta esistano interpreti
ObjectiveC).
Il buon vecchio C può essere interpretato. tcc è in grado di farlo. CIL
pure. Al momento devo mettere mano su un altro interprete C (scritto in
Prolog) che interpreta per l'appunto codice C.
Come vedi semplici esempi pratici ti smentiscono: essere compilato o
interpretato non rende il linguaggio "diverso". È una questione di
implementazione.
Come ti hanno fatto notare le vere questioni sono altre.


 INFORMATICA!!!!) non si insegni il C++ ?
Se ti interessa nella mia si insegna C++. E non sono affatto convinto
che sia una buona scelta.


 fa certo impazzire)
con questa abbiamo raggiunto l'imo. Ma forse mi sbaglio: hai posto le basi
per rivoluzioniare l'ingegneria del software. Dopo aver letto una notizia
del genere secondo me dovresti scrivere alle aziende che lavorano su J2EE
proponendo di trasformare in linguaggio macchina i loro progetti (o
addirittura scriverne di nuovi, questa volta compilati). C'è GCJ per lo
scopo.
Per fortuna tua c'è ancora chi crede agli asini che volano.
Io, per fortuna, credo ancor meno agli asini di terraferma.


Io, per fortuna, credo ancor meno agli asini di terraferma.
Hai provato lo specchio ? :-)

 fantomatici progetti, geniaccio.
Fammi capire eh, ma tu, per il "progetto importante e complesso" che stai
realizzando, usi OC4J o JBOSS?
Scusa eh, ma per chi abbia un minimo di esperienza lavorativa è praticamente
assodato che lavorare per un cliente, su un progetto di grosse dimensioni
con EJB, usando JBOSS & co. è un suicidio in partenza, a meno che il cliente
non sia un filantropo dell'allegra comunità java o un idiota patentato.
O forse intendi dire che dal cliente lavori con OC4J e nel tempo libero su
JBOSS?
Dimmelo sinceramente guarda, perchè se riesci a far funzionare il porting di
un progettone su JBOSS già solo per il deploy posso indicarti delle aziende
(per cui ho lavorato, composte da persone che masticano J2EE dalla sua
nascita) che ti accoglierebbero a braccia aperte e ti pagherebbero fior di
quattrini.
Ma che fai, pistola? Parli di J2EE a vanvera perchè non è argomento
conosciuto bene qui e non hai contraddittorio???
Ma sei davvero sicuro di lavorare su EJB??? La JVM SUN gratuita?????????????
No, davvero non riesco a credere che chi dice queste cose lavori davvero ad
un progetto J2EE


Ma che fai, pistola?
Sei un povero demente.


Allora visto che l'italiano č per te arabo, provo a ripetere sotto altra
forma la domanda:
1) PER I PROGETTI DI GROSSE DIMENSIONI SU CUI LAVORI USI JBOSS (che č
GRATUITO) oppure OC4J (che č NON GRATUITO)????
alternativamente:
2) STAI LAVORANDO O HAI LAVORATO A PROGETTI DI GROSSE DIMENSIONI CON
JBOSS?????
o, anche:
3) PER PROGETTI in CUI, TANTO PER DIRNE UNA) LE TRANSAZIONI SONO CRITICHE e
COMPLESSE(e quindi il container . BADA BENE, DICO IL CONTAINER - non puň
sbagliare), RIESCI A FAR FUNZIONARE BENE JBOSS????
e ancora:
4) LA JVM SUN č GRATUITA???????


> Questo tuo tono ironico mi indispone francamente ...
hai ragione, scusami per i miei modi. Ammetto inoltre di avere il dente
avvelenato contro JAVA, ma secondo me se ci rifletti un attimo:
1) il discorso che fai sul C++ all'università non sta in piedi. Che nelle
facoltà di informatica italiane, a differenza di TUTTE le altre dei paesi
sviluppati europei, non si insegni C++ è solo un demerito.
2) noterai qualche incongruenza non banale nelle parole del interlocutore su
cui, a torto o a ragione, mi sono accanito.


 ha
scritto:

scegli bene tra alcune zone del nord italia. Ad esempio l'Emilia, In quelle
dove c'č sviluppo e l'elettronica (ancor piů che l'informatica) ancora č
viva, il C++ č vivo e vegeto


 Io, per fortuna, credo ancor meno agli asini di terraferma.
Non hai fiducia in te stesso. Mi dispiace.


 sviluppati europei, non si insegni C++ è solo un demerito.
Non mi hai ancora spiegato perche' e poi non confonderei ingegneria
informatica con le altre facolta' informatiche del paese.
-- 
Ciao
Wezzy

 vendibile etc etc etc.
c'č da dare craniate a terra per lo scenario desolante. Evidentemente eri
cosě preso dalle tue cavolate da non capire neanche l'ironia delle mie
parole.
MA TU DAVVERO CREDI CHE SI POSSA COMPILARE IN CODICE MACCHINA UN PROGETTO
JAVA (magari J2EE) ?? utilizzando GCJ ??
Ma tu davvero credi che le aziende non lo facciano perchč " A loro interessa
avere un prodotto funzionante, utilizzabile
 vendibile etc etc etc" ??
Scusa, fammi capire, stai scherzando o cosa??
Ma che fai, le ricerche dell'ultimo secondo su google per poi sparare
cazzate in serie??
Probabilmente a te non interessa affatto, ma fossi in te mi prenderei almeno
cinque minuti per riflettere sull'enormitŕ che hai detto


 JAVA (magari J2EE) ?? utilizzando GCJ ??
Si, si puo': 
http://sourceware.org/eclipse/
Ciao,
Nicola
P.S. Ma tu ti chiami Vincenzo per caso?

 Dai un'occhiata a Erlang, giusto per curiosità.
L'avevo visto anni fa. Per interesse personale leggo fumetti e riviste di
auto. Per interesse aziendale lo trovo inutile perché una scelta simile non
passerebbe mai. Pensa che sto facendo una lotta di retroguardia per
convincere alcuni miei colleghi che il codice aziendale mission critical
deve rimanere in C++, invece che portarlo il C#.
Ammetto di averci messo anni per accettare che l'XML può essere un
protocollo di comunicazione interessante, quindi magari anche in questo
caso sono in ritardo sui tempi, però credo ancora che la complessità e la
vicinanza del nudo ferro del C++ obblighi il programmatore ad essere
disciplinato e a sforzarsi di capire sempre cosa succede.
Quello che non capisco è perché con Python non mi sembra di perdere il
controllo delle cose come con C#, gestione della memoria a parte
ovviamente. Può essere che sia dovuto al fatto che uso molto python per i
programmi usa e getta, e praticamente mai in progetti "grossi" e quasi mai
in progetti "complessi". 

 Sei un povero demente.
Lascia perdere Andrea. E' inutile arrabbiarsi. Onestamente non mi ricordo
di avere letto tuoi post in cui eri cosě arrabbiato. Visto i contenuti
raggiunti dal thread ti chiedo se ne vale la pena.

 in progetti "complessi". 
Non saprei. Non ho lavorato con nessuno di questi due linguaggi.
Kiuhnm

 Si, si puo': 
http://sourceware.org/eclipse/
Nessuno mette in dubbio che si possa. Si dimostra banalmente. Il 
problema è che i linguaggi interpretati sono così espressivi da rendere 
minimo il vantaggio che una compilazione in codice nativo comporta. 
Limitando tuttavia la loro espressività nei punti critici, è possibile 
ottenere codice molto veloce.
Kiuhnm

 tesi.
Ammetto che non ho mai capito bene la differenza tra linguaggio imperativo
e linguaggio dichiarativo. O meglio, mi dimentico la differenza alla
velocità con cui mi mangio un bombolone alla crema, e ti assicuro che ci
metto poco tempo :-)
Per me è proprio l'assurda complessità del C++ a rendere i programmi dei
professionisti "migliori". Per fare un paragone anomalo: con un auto
moderna vai oltre i limiti perché è tutto "facile". Con un auto di 20 anni
fa, con le ruote che fischiano e il rollio assurdo, stai ben attento ai
limiti.
Ovviamente dare il C++ in mano ad un demente è come dare un mitra ad un
bimbo. Però parlando di professionisti, più che il linguaggio, per me la
differenza la fa "paura". Anche il C va bene, visto i danni che si possono
fare anche con questo linguaggio. Sia chiaro che è solo una mia opinione.
Anche se sono vicino ai 20 anni di esperienza, e di programmatori ne ho
conosciuti un po', sono conscio che la mia opinione lascia il tempo che
trova.
Poi detto ciò preferisco un linguaggio procedurale ad uno dichiarativo, e
nutro forti sospetti su tutte i GC a prescindere. Per me la complessità è
un fattore non comprimibile dal linguaggio. Prima o poi torna fuori. Per
questo sono del parere che è meglio averci a che fare "subito".


Secondo me l'OP lo metteva proprio in dubbio. In ogni caso sono
convinto che il discorso sull'espressivita' si applichi meno a Java che
alla maggior parte dei linguaggi interpretati.
Ciao,
Nicola

 alla maggior parte dei linguaggi interpretati.
Infatti. Java non è affatto più espressivo di D (anzi), che pure è
compilato. Ed è sicuramente molto meno espressivo di ObjectiveC, che
pure è compilato.
Anzi a dirla tutta non è nemmeno più espressivo di C++ (che è
compilato).


 ottenere codice molto veloce.
Non sono d'accordo. In primo luogo non vedo necessariamente un legame
fra l'essere espressivi ed essere compilati/compilabili efficientemente.
In primo luogo manca una buona definizione formale di "espressività", ma
suppongo che ci si riesca ad accordare se un dato linguaggio sia o meno
espressivo.
Pensa ad Haskell. È un linguaggio di livello piuttosto alto, molto
vicino al modo in cui si pensa (ammesso di pensare funzionale), con
costrutti di alto livello e tutto.
Adesso mi riferisco al computer language shootout, quindi tutta roba
algoritmica.
Eppure Haskell è spesso e volentieri molto più veloce di Java e ha anche
un uso minore di memoria (e pure lui è GarbageCollected). OCaml (pure
lui compilato e di livello parecchio alto) è solo marginalmente più
lento di C++. Nel peggiore dei casi è due o tre volte più lento.
Ma in effetti sull'algoritmica pure Java non è molto più lento di C++
(con C++ intendo sempre g++, con compilatori che ottimizzano meglio il
divario può aumentare).
Se a Python aggiungi un JIT pure ottieni incrementi *spaventosi* di
performance (sempre su codice algoritmico).
D che complessivamente è di livello più alto di C++ (anche se non di
molto, ma comunque ha garbage collector incorporato, array checked --
iirc -- ) è assolutamente comparabile come performance (e lo è anche con
C).


 cinque minuti per riflettere sull'enormità che hai detto
Non voglio farti lezioni di informatica da 5 minuti, ma non c'è *nessun*
limite teorico nel compilare Java in codice macchina.
In primo luogo puoi compilare il bytecode Java in codice nativo. Il JIT
lo fa "Just in time" a tempo di esecuzione, ma potresti benissimo
scrivere un programma che lo fa a "Ahead of time". 
In secondo luogo puoi scrivere un compilatore per ogni linguaggio che
viene interpretato (al limite non essendo minimamente efficiente
rispetto all'interpretazione).
In aggiunta ti ho esibito un compilatore esistente che compila Java in
codice macchina. 
Non vorrei dire, ma mi sembra che ti manchino le minime basi di
informatica per capire quello che sto dicendo. Studia un po' e capirai
che hai torto. O altrimenti prova ad esibire una prova del perchè Java
non potrebbe essere compilato in codice macchina nativo di un
processore, per esempio x86.


 fra l'essere espressivi ed essere compilati/compilabili efficientemente.
In un linguaggio X molto espressivo (che permette cioè di esprimersi, 
volendo, in modo poco ridondante) una singola istruzione può 
corrispondere a molte righe di linguaggio macchina (LM). Nel caso 
peggiore, tali righe di codice sono equivalenti all'interprete stesso di 
X. Questo avviene poiché, scendendo al livello del LM, la semantica di 
ogni riga di un programma P scritto in X (cioè la porzione di codice in 
LM effettivamente eseguito) non dipende solo dal resto del codice 
sorgente di P nel quale tale riga si trova (come avviene nella maggior 
parte dei "vecchi" linguaggi imperativi), ma dipende anche dalla "storia 
d'esecuzione" del programma (che varia al variare dell'"input" 
ricevuto). Naturalmente, nella pratica, si hanno varie sfumature di grigio.
Kiuhnm
P.S. Al posto di Haskell, considera Clean. Il paradigma funzionale è 
molto più semplice di quello stateful quindi è possibile ottimizzare il 
codice in altro modo. Per es. Clean utilizza una tecnica chiamata Graph 
Rewriting. Rinunciando al paradigma funzionale, si perde la possibilità 
di applicare simili tecniche.

 Poi detto ciò preferisco un linguaggio procedurale ad uno dichiarativo
Devo correggermi. Su quello che è il core businness preferisco un
linguaggio procedurale e un "sistema" di sviluppo che non mi nasconda
nessun dettaglio. Per il resto (database, http) preferisco le scatole
nere.


--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


no


 questo sono del parere che è meglio averci a che fare "subito".
Insomma sei della vecchia guardia ;-)
Kiuhnm

 Saluti eh, "capatosta"
ci sono almeno un paio di dozzine di teoremi sui linguaggi che se 
avessero un viso ti starebbero deridendo a crepapelle...
complimenti per la cultura...

 
http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html#About-CNI
Qui parlano di CNI. Ovvero un metodo alternativo a JNI per chiamare
metodi "nativi". Sul sito del progetto parlano anche chiaramente della
possibilità di tradurre il byecode Java in codice x86 (pensa te, si
chiama compilazione pure questa).
A questo punto sei troppo ignorante e sciocco per essere vero. Credo che
tu sia un troll in mala fede.
Comunque ti do una possibilità: voglio la dimostrazione teorica del
perchè a tuo avviso non si possa compilare Java in codice x86.


 progetto J2EE in queste condizioni??
Il problema si divide in de parti: serve? molto probabilemente no,
perche' le applicazioni server side sono quelle che piu' traggono
vantaggio dalla compilazione JIT. Si puo' fare? Dipende effettivamente
dalle librerie disponibili e dalla necessita' o meno di codice nativo,
scritto per forza di cose in altri linguaggi, per supportare quelle che
mancano.
Comunque ho consumato l'energia che sono disposto a spendere per
mostrarti i tuoi errori. Se ti ho convinto bene, senno' pazienza. Il
dispiacere che provero' a sapere che vai in giro per il mondo a fare
certe figure e' inferiore a quello che provo quando scopro di aver
inavvertitamente calpestato una formica.
Ciao,
Nicola

 Insomma sei della vecchia guardia ;-)
Sono vecchio :-O

 argomento.
Proprio pochi giorni fa ho cercato qualche offerta di lavoro per 
programmatori C++ e ne ho trovate diverse fra le software house di 
videogiochi. Cercavano specificatamente C++, Assembler e conoscenza 
delle SDL.

Massimo Soricetti ha scritto:

P.S.
FASCISTI SU MARTE!!!! ^_^


Caro amico 2,
vedo che tu segui la degna scuola del tuo compagno di thread, vale a dire
leggere di fretta e non capire ma esser pronto lo stesso a "spararla" nel
momento d'emergenza. E anche nel tuo caso mi vedo costretto a correggerti,
non perchè tu sia degno di contraddittorio, ma semplicemente per evitare il
gonfiarsi di certe cretinate sparate alla cieca in questo thread.
Mi perdonerai se salto a pie' pari tutto il resto della tua inutile
manfrina, e passo subito all'elemento equivoco basilare su cui affogano le
tue (e di lui) strampalate idee (se non altro ti do il merito di aver dato,
a differenza del tuo compare, almeno una mezza lettura a quanto riportato
sul sito GCJ; alla cieca, sia chiaro: il comprendonio non rimane certo il
tuo punto di forza); quando tu scrivi:
"Mi spiace, ma l'annebbiato sei tu, tant'e' che riporti sotto
informazioni errate. Non so se sia stata la fretta di cercare un
argomento a sostegno della tua tesi o una forma di fanatismo che ti
impedisce di leggere le cose per quelle che sono, fatto sta che accusi
gli altri dell'errore che stai commettendo tu.
CNI e' una libreria che permette di scrivere codice misto C++/Java, non
e' il formato intermedio del compilatore."
ovviamente spari una cazzata senza controllarne minimamente l'attendibilità.
Cribbio, lo so che è dura, ma hai provato a dare un'occhiata a come funziona
il compilatore GCJ o perlomeno a cercare qualche istruzione in merito?
Toh, pistola:
www.redhat.com/support/wpapers/redhat/gcj/gcj.pdf
E se leggi una volta tanto senza il fumo degli occhi, magari pagina 8 tra le
tante, parla PROPRIO di CNI come layer intermedio di compilazione; e non
pretendo certo che tu ti metta a scrutare il codice di gcc-java, vale a dire
il codice del "compilatore" stesso, sia perchè non ci capiresti nulla, sia
perchè la tua ottusa insistenza, pur di fronte a cento "#include
<gcj/cni.h>" nel COMPILATORE, bada bene NEL COMPILATORE, continuerebbe a non
demordere.
Lo so che è difficile da mandar giù, pisellino, ma tant'è: gcj non è un
compilatore java-->codice macchina, ma è invece un binding verso il java di
un compilatore gcc.
La "compilazione" in java di fatto non avviene se non passando attraverso
questo layer di conversione di metodi ed oggetti Java-->C++, ciò che
capovolge totalmente la logica di quello che vorresti dimostrare.
E del resto, cervellone, riguarda un po' meglio (vale a dire leggi almeno le
prime righe) anche il link della sezione CNI nel progetto GCJ, che avevo
postato prima:
http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html
non ti sembra perlomeno curioso che sia TUTTO incentrato su come richiamare
metodi e utilizzare oggetti java in contesto C++, piuttosto che viceversa???
Cribbio, geniaccio, si vuole usare un compilatore per il java e ci si
preoccupa di come utilizzare CNI per eseguire metodi java in C++; sei capace
di fare 1 + 1 = 2 ???
Vabeh, fermiamoci di nuovo. Aspetto con curiosità le risposte, ormai non mi
sorprende più nulla in certe discussioni.



gentile Enrico 'Mc Osten' Franchi,
mi perdonerai se taglio corto. Ribadisco che Il mio scopo non era certo
discutere di compilazione con te, quanto piuttosto chiarire (spero) agli
altri una cazzata gigantesca che te e (purtroppo) qualcun altro ha spalmato
sul forum. Quindi mi permetterai se non rispondo alla tua osservazione -
tanto scema quanto inutile - circa la "compilazione da java bytecode a
codice macchina" (non c'è nulla da fare Franchi: le cose si comprendono non
quando si realizza che accadono, ma quando perlomeno ci si inizia a chiedere
come accadono). Consentimi solo però di osservare quanto puerile e sciocco
sia stato il tuo "colpo di coda", attaccandoti - a corto di argomenti - alla
definizione generica di compilazione. Noto peraltro che tu inserisci
commenti di risposta alle righe dei post man mano che le scorri, anzichè
leggere prima, nell'interezza, il messaggio: spero davvero per te che ciò
sia dovuto al prurito delle mani in reazione alla tua stizza, perchè se
questo dovesse essere anche il tuo atteggiamento nell'affrontare un problema
inerente al C++, perderesti il lavoro ancor prima di averlo trovato.
Saluti, ciccio-pasticcio
AH, P.S: ovviamente, hai ragione tu!


 di applicare simili tecniche.
Clean non lo ho presente. Mi metterò d'impegno appena finito con
Haskell. Al momento sto attaccando le monadi. Ho avuto una mezz'oretta
prima di pasto per pensarci su, ma ovviamente non mi è bastato (come
previsto). Adesso sta sera o domani ci torno sopra.
D'altra parte non mi sembrano impestate come tutti dicono. Sarà perchè
le ho solo scalfite.
Peraltro io da buon matematico mi sto innamorando tantissimo di Haskell
e il fatto di *non* avere side effects mi fa intravvedere tutto un mondo
meraviglioso che non vedo l'ora di esplorare.
Tempo fa avevo programmato in common lisp, ma alla fine con tutti i
costrutti imperativi dello stesso finivo per usarlo in modo
relativamente poco funzionale.


 relativamente poco funzionale.
Hai provato Scheme?
Kiuhnm

 Hai provato Scheme?
Di sfuggita, tempo fa, ai tempi del Lisp. Più o meno avevo
sleggiucchiato i sorgenti di sawtooth (o come accidenti si chiamava, che
era un windows manager in scheme).
Ma alla fine non ci ho mai fatto nulla.


 sistemare il tutto.
Il paradigma funzionale soffre di alcuni problemi. Per es. ostacola la 
separazione tra interfaccia e implementazione.
Ti faccio l'esempio classico scritto in pseudo-codice.
Supponi di avere
getMethods
{
   Create() =
   Push(S,E) = ...
   Pop(S) = ...
   IsEmpty(S) = ...
   return (create = Create, push = Push, pop = Pop, isEmpty = IsEmpty);
}
getMethods restituisce un record (con i 4 indici letterali "create", 
"push", "pop" e "isEmpty") contenente appunto i metodi da chiamare per 
lavorare sullo stack.
Un possibile uso:
M = getMethods();
S = M.create();
S2 = M.push(S,5);
S3 = M.push(S2,6);
ecc...
Supponi che getMethods voglia contare quante volte vengono chiamati i 
vari metodi. Come fa?
Nel paradigma stateful l'interfaccia non cambia minimanente, mentre nel 
paradigma funzionale si è costretti ad aggiungere dei parametri con 
funzione di accumulatori.
Per es.
Push(S,E,I) = { ... return I+1; }
Il chiamante dovrà passare il contatore restituito da Push alle altre 
funzioni. Come facciamo con Pop che restituisce l'oggetto rimosso?
Pop(S,I) = { ... return (E,I+1); }
Come vedi, siamo costretti a restituire una coppia (elemento,contatore).
L'interfaccia è stata chiaramente alterata.
Esiste una soluzione più elegante?
Dipende da cosa s'intende per più elegante. Non la scrivo, ma l'idea è 
quella d'inglobare lo stack e il contatore in getMethods (che ora si 
chiama createStack).
Si userebbe in questo modo:
S = createStack();
S2 = S.push(6);
S3 = S2.push(7);
Ancora una volta, Pop dovrebbe restituire due valori: l'elemento rimosso 
e i nuovi metodi.
Infatti il trucco sta nel far sì che ogni funzione restituisca un record 
di nuove funzioni che conoscono i valori aggiornati dello stack e del 
contatore.
Ho visto persone ridursi con funzioni del tipo:
f(s, e, I1, O1, I2, O2, I3, O3, ....., I12, O12)
Bisogna accettare che il paradigma funzionale ha forti limiti e 
soprattutto che è un sottoparadigma di quello stateful.
Non esiste tecnica usata in un paradigma funzionale che non possa essere 
usata in quello stateful. Il problema è che i linguaggi comuni come il 
C++ non hanno mai sentito grande necessità di usare certe tecniche.
Kiuhnm

 Java-->C++,
Prova-lo. Da me, riesco a avere codice assembler senze qualcuno
layer intermediaro.
--
James Kanze (GABI Software)             
email:james...@gmail.com
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, 
+33 (0)1 30 23 00 34

 di fare 1 + 1 = 2 ???
Si. Dal momento che nessun sistema operativo su cui gira gcc e' scritto
in Java e' necessario poter chiamare da Java codice nativo non Java e
CNI e' la libreria che fornisce questa interfaccia in modo efficiente.
In modo assolutamente analogo codice C++ (o Delphi, o qualsiasi altro
linguaggio) deve poter chiamare le primitive di sistema scritte in C ed
e' per questo si fa in modo che la parte funzionalmente comune tra
questi linguaggi ed il C utilizzi le stesse convenzioni usate dal
sistema operativo. Cio' non toglie che tutti questi linguaggi siano
compilati.
Hai finalmente capito?
Ciao,
Nicola



Certe. Non posso parlare d'Italia, ma a nivello europeo, vedo
che c'è bene un po più di domanda per i programmatori di Java,
ma per i piccoli progetti, con contratti corti. L'infrastruttura
vienne anche oggi programmata in C++, e se c'è un po meno
domanda, la differenza non è tanto importante, e i progetti C++
durano tipicalemente più di tempo: i progetti in Java durano
tipico tre a sei mesi, quelli in C++ tre a quattro anni.
So in ogni caso che non ho problemi a trovare il lavoro. In C++,
più di in Java, sebene che conosco i due.


 dei post man mano che le scorri, anzichč leggere prima, nell'interezza
neanche sai come "funziona" un newsgroup (gia, questo non č un forum)...

 soprattutto che è un sottoparadigma di quello stateful.
Probabilmente dipende da quello che devi fare. Ad ogni modo non ho
guardato benissimo il tuo esempio. Ti confesso che non ho nemmeno ben
capito il tuo pseudo-codice.
Se usassi una pseudosintassi tipo ML o tipo Haskell o anche tipo Lisp
forse capirei meglio. Oppure se mi spieghi a parole quello che intendi
:)
Tuttavia in Haskell con i cosidetti "Named Fields" risolvi di buona
misura molti problemi. Oltre che sia Haskell che OCaml sono funzionali
*e* ad oggetti.
Peraltro di Haskell mi piace che rende chiara la separazione ovvia fra
tipi e classi che purtroppo in molti linguaggi imperativi viene
sostanzialmente persa.


Su che testo hai studiato Haskell?
Ciao,
Nicola

 sostanzialmente persa.
Sì, la differenza è notevole. I tipi (Abstract Data Type) vengono anche 
definiti unbundled e gli oggetti bundled.
Un altro aspetto importante è che gli oggetti sono sicuri perché 
proteggono i dati interni, mentre gli ADT non lo sono. Possono essere 
resi sicuri usando un wrapper protetto da una chiave. La chiave è locale 
all'oggetto quindi solo lui la conosce, ... ma stiamo andando 
tremendamente OT :)
Kiuhnm

 tremendamente OT :)
Ovviamente sto parlando di un "oggetto" reso con le chiusure. In realtà 
bastano queste per proteggere i tipi.
Kiuhnm

 Su che testo hai studiato Haskell?
Per adesso su un PDF online chiamato Yet Another Haskell Tutorial di Hal
Daumé III.
In arrivo amazon permettendo il testo di Hudak.


 tremendamente OT :)
Infatti. Riguardo l'OT. Riguardo quanto dici, ti prendo in parola.
Purtroppo sono iper-nuovo di Haskell. Ci avevo dato svariate occhiate in
diverse occasioni, ma questa è la prima volta che lo affronto
seriamente, e non sono che pochi giorni che ci lavoro. Con tutto il
resto che ho da fare.
Studi precedenti di logica e di lambda calcolo/combinatori mi hanno
notevolmente facilitato, ma purtroppo sono e resto un niubbo di Haskell.
Ovviamente ho intenzione di cambiare lo stato di cose con il tempo. :P


 Ovviamente ho intenzione di cambiare lo stato di cose con il tempo. :P
Proprio non ci siamo: non imparerai mai a programmare in Haskell 
cercando di cambiare lo stato delle cose :)))
Kiuhnm

 cercando di cambiare lo stato delle cose :)))
Ah rotfl :)
