Newsgroup: it.comp.lang.c++
Titolo: perché sconsigliare il C++?

Vedo che il C++ viene bistrattato da tutti, anche (soprattutto?) in 
questo NG. Volevo fare una riflessione a favore del C++, soprattutto 
(eresia!) dal punto di vista didattico. Sto pensando a chi vuole 
imparare a programmare veramente, sulla macchina.
Il punto a favore del C++ sarebbe che, in un certo senso, è un 
soprainsieme degli altri linguaggi di programmazione. Se mi studio il 
Java posso dire che tutti i metodi sono virtuali (riferendomi alla 
distinzione del C++), che le classi vengono memorizzate come puntatore 
(riferendomi ai puntatori del C++) etc... In python posso dire che i 
tipi di base vengono passati per valore mentre i tipi definiti 
dall'utente vengono passati per riferimento... Faccio riferimento a 
concetti che chi studia il C++ è COSTRETTO ad imparare e che in altri 
linguaggi, con motivazioni sensate, vengono eliminati.
Se in un corso di programmazione mi si chiede di implementare una lista 
utilizzando il python, come faccio a capire il senso di fare le liste 
quando il python la lista ce l'ha come tipo di base? Scrivere un 
interprete python in C++ sarebbe un progetto didatticamente molto 
interessante. Avrebbe senso (dal punto di vista didattico, dico) 
scrivere un compilatore Java in python? O un compilatore C in Java?
Non sono veramente (del tutto) convinto di quello che dico, mi 
piacerebbe sentire altre opinioni.
E.

 sentire altre opinioni.
Sono perfettamente d'accordo ed č uno dei motivi per cui continuo a seguire il 
C++ pur utilizzandolo poco.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 che in altri linguaggi, con motivazioni sensate, vengono eliminati.
Io considero il C++ solo uno strumento. Non credo in una sua 
superiorità "a prescindere" nei progetti reali.
La decorazione delle funzioni di Python o dei linguaggi dot net che 
equivalente avrebbe in C++? Io uso molto il C++, ma perché ho necessità 
di essere "veloce", di avere il controllo assoluto di quel che faccio e 
uso*, e perché non faccio grafica.
*
Per dire, se devo scaricare una pagina via http in un programma usa e 
getta, uso C# o dotnet e la libreria relativa. Se devo farla in un 
server preferisco aprirmi un socket i c/c++ e leggere/scrivere dei 
byte. Anche perché non potrei che usare librerie commerciali, e non è 
che il mondo sia pieno di "buone" librerie per tutti gli usi, e che non 
necessitano di anni uomo di studio per usarle a fondo.
-- 
mai più senza: 
http://www.genux.com/scheda.asp?idprod=47974
la cultura è importante: 
http://www.libreriadellautomobile.it

 imparare a programmare veramente, sulla macchina.
Didatticamente, il C++ ha alcuni grossi difetti.
Uno: è troppo complesso. Molte feature del C++ sono risposte a problemi
che si incontrano programmando ed è difficile spiegare "perchè è così" a
gente che non ha programmato mai... sembra sempre un inutile modo di
complicare le cose semplici, e spesso le persone ci si perdono dentro.
Due: insegnare il C++ "nudo e crudo" equivale a lasciare gli studenti in
alto mare; non basta dire che il C++ ha le classi, occorre anche
insegnare a progettare di un sistema di classi e a gestirne le
interazioni, come minimo. Un corso C++ per gente che parte da zero
dovrebbe necessariamente comprendere anche un corso propedeutico sulla
OOP, e probabilmente non basterebbe ancora.
Tre: è dispersivo. Devi occuparti dei dettagli (io x es. ce l'ho a morte
con gli include file, che mi han fatto penare tanto "da piccolo") invece
di concentrarti sull'algoritmo che stai scrivendo. E di nuovo, per uno
studente non è il massimo.
Il C++ è ottimo per velocità ed efficienza, per manutenibilità e
"ingegnerizzabilità" del codice, nonchè per tutto il marasma di
materiale e librerie che si trovano in giro, ma... i difetti che ha come
linguaggio sono innegabili, e credo che tutti, più o meno consciamente,
li avvertano. Da cui il "parlarne male" che hai notato tu. Ma è un pò
come parlar male della moglie: alla fine sempre a casa si torna :-)

 [...]
Tutto quello che dici è valido anche se sostituisci il C++ con il C, da
affiancare ad un linguaggio più ad alto livello.
Saluti  Manlio Perillo

 di nuovo, per uno studente non è il massimo.
il C++ ti permette di occuparti dei dettagli (a volte devi) ma non vedo
proprio gli include file come dettagli, oltretutto non sei neanche
obbligato ad usarli. da piccolo usavi le direttive #ifdef ?

 che faccio e uso*, e perché non faccio grafica.
solitamente grafica si fa con il C++ :)
Ciao


Sì è vero. Anzi è meglio. Io per capire le funzioni virtuali o 
l'ereditarietà multipla mi immagino come dovrei implementare le classi 
utilizzando il C. Sarebbe un esercizio interessante!
A suo tempo ho guardato i codici di programmi X per Unix: erano (sono!) 
programmi scritti in codice orientato agli oggetti... in C!
E.

 scrivere un compilatore Java in python? O un compilatore C in Java?
Perchè no? Noi lavoriamo con un interprete C in Prolog. Io mi sono scritto
un frammento (quello che mi serviva) di un compilatore C in Haskell. E
quindi?
Per dire l'ultima edizione del DragonBook utilizza per molti esempi Java.
E quindi? 
Tipicamente scrivere un programma complesso (come un compilatore) in un
linguaggio di alto livello ti scherma da alcuni dettagli rognosamente
implementativi che si hanno nello sviluppo di un qualunque programma
complesso in un linguaggio di basso livello.
Dal punto di vista didattico, se vuoi mostrare come funziona un interprete
o un compilatore, linguaggi con una buona predisposizione per manipolare
strutture ad albero, con pattern-matching e programmazione dichiarativa
sono estremamente comodi. Il codice viene molto più elegante e leggibile
rispetto che utilizzando if espliciti e programmazione imperativa.
Poi se vogliamo fare un discorso di efficienza, siamo d'accordo. Anche se
per dire OCaml rivaleggia con C++ in fatto di velocità.
Insegnare C++ come primo linguaggio è una scelta. Io personalmente non lo
farei, è molto più difficile che seguire altri approcci. MA questa è la mia
idea.
-- 
Consistently separating words by spaces became a general 
custom about the tenth century A.D., and lasted until 
about 1957, when FORTRAN abandoned the practice. 
(Sun FORTRAN Reference Manual)

 solitamente grafica si fa con il C++
Per deformazione professionale definisco "grafica" qualcosa con dei 
pulsanti e una edit box su windows. Per queste mie esigenze preferisco 
C#. Volendo con il C++ managed e un IDE come Visual Studio 2005 lo 
sviluppo è comunque rapido, ma mi irrida dal punto di vista filosofico 
usare il C++ managed. E' più forte di me.


 managed. E' più forte di me.
... parlavi di user interfaces (e/o roba che inizia per W ;)
--*PaN!* 

 questo NG.
La mia personalissima opinione è che il C++ sia poco flessibile e la sua 
sintassi irregolare e goffa.
Non sono d'accordo con chi dice che non si può fare di meglio. I 
linguaggi di alto livello fanno altro quindi non sono migliori del C++.
Allo stesso modo la matematica non è superiore alla filosofia. 
Semplicemente si limita a fare quello che può essere fatto bene.
Il C++ sta al Python come una mediocre esecuzione di un esercizio 
difficile sta ad un'ottima esecuzione di un facile esercizio.
Tuttavia, e intendo dimostrarlo da qui a qualche anno, un'ottima 
esecuzione di un difficile esercizio è tutt'altro che impossibile.
Kiuhnm

 Java in python? O un compilatore C in Java?
Ci han scritto un libro didattico sopra: "Modern compilers implementations 
in Java"
--
Marco 

 scrivere un compilatore Java in python? O un compilatore C in Java?
I compilatori sono programmi che leggono e scrivono file. L'utilizzo
di un linguaggio di basso livello non comporta quindi particolari
vantaggi. Se provi a chiedere in un newsgroup di compilatoristi
probabilmente ti rispondono che il linguaggio ideale e' un linguaggio
funzionale.
Ciao,
Nicola

 in Java"
Attento che quello e' la traduzione in Java di un libro scritto
originariamente per ML. Gli esperti dicono che la versione ML resta
quella migliore ;-)
Ciao,
Nicola

 ha scritto:

non stato cosi perspicace :)

 non stato cosi perspicace :)
Onestamente era difficile capirlo. Specie se uno la mattina ha dovuto 
usare il c++ :-)


 di un difficile esercizio è tutt'altro che impossibile.
Se ci riesci diventi ricco oppure morto :-)


 Se ci riesci diventi ricco oppure morto :-)
Probabilmente ne l'uno ne l'altro, ma almeno si e' divertito un po'
nel frattempo :-)
Ciao,
Nicola

 Se ci riesci diventi ricco oppure morto :-)
E' principalmente ad uso personale ed incluso nel mio software come 
sorta di interfaccia (v. Matlab, Mathematica, ecc...).
Kiuhnm

 Mathematica
Il tipo che invento Mathematica mi pare che sia ricchissimo. Non so se 
lo inventò perchè gli serviva o se puntava da subito a venderlo.


 nel frattempo :-)
Bisogna sempre puntare in alto. Se ognuno lasciasse perdere per 
questioni di probabilità allora nessuno riuscirebbe, no? :-)
Kiuhnm

 Kiuhnm
Sono curioso di sapere come intendi dimostrarlo, e cmq condivido il tuo 
atteggiamento di sfida. :-D
La mia personalissima opinione è che in progetti ambiziosi e grandi 
alcune peculiarità del C++ come l'ereditarietà, il polimosrfismo, la 
possibilità di templatizzare classi e tipi siano davvero irrinunciabili, 
inoltre (cosa non meno importante) apprezzo molto la possibilità di 
operare in modo grezzo sulla memoria e fare alcuni piccoli e sporchi 
giochetti per sperimentare un po' di cose di tanto in tanto. A questo 
proposito infatti ricordo anche il comodissimo assembler inline se il 
c++ di per sè non bastasse. All'atto pratico però spesso e volentieri ho 
solo bisogno di fare qualche test veloce veloce ed utilizzo C# perchè mi 
pare un buon compromesso tra i costrutti rigidi del C++ e la 
supervelocità di VB con cui anche il primo ferrotramviere che passa 
(senza offesa) si può improvvisare programmatore in 5 min. Oltre tutto 
il framework .NET fra un po' fa anche il caffè.
E' anche vero però che quando questi piccoli test mi appassionano un po' 
di più, immancabilmente riscrivo tutto in C++ ;-)
Per fare un bilancio finale, direi che il C++ viene bistrattato da chi 
non lo conosce bene o almeno non abbastanza. Ne viene criticato qualche 
aspetto particolare di chi lo conosce fin troppo bene e viene "bollato" 
come TROOOOOPPO DIFFICILE da chi vorrebbe aprire l'IDE C++ per la prima 
volta e scriverci di getto il suo primo fichissimo programma, ma resta 
deluso quando non ce la fa. Inoltre posso essere d'accordo ma solo in 
parte sull'affermazione che non ci sono linguaggi migliori o peggiori, 
ma solo nati per certe esigenze. Perchè d'accordo "la velocità 
d'utilizzo" ma io non definirei un buon linguaggio (ogni riferimento al 
VB è puramente casuale) uno che permette delle selvagge conversioni di 
tipo (per giunta automatiche) da stringa a numero di qualsiasi 
precisione a byte e chi più ne ha più ne metta. Devo dire che ho scritto 
anche programmi importanti in VB per un ufficio tecnico e per la 
gerstione edilizia di un  comune del centro italia (per intenderci un 
capoluogo di regione, non un comune qualsiasi) ma mi è stato 
espressamente chiesto quel linguaggio... brrrrr ho ancora i brividi a 
pensarci.
Ciaooo!
Aspidus

 Aspidus
ciao
Soviet_Mario

 possibilità di templatizzare classi e tipi siano davvero irrinunciabili, 
[...]
Chi svita le viti a mano dirà che il cacciavite manuale è 
irrinunciabile, finché non gli viene fatto provare quello elettrico e 
alla fine quello magnetico (ala Mission Impossible).
Nel mio linguaggio non esisteranno né oggetti, né classi, né istruzioni, 
né variabili e sarà totalmente aparadigmico. Sarà molto più ad alto 
livello dei linguaggi attualmente conosciuti e allo stesso tempo non 
farà rimpiangere il C.
Inoltre abolirò l'ICI sulla prima casa.
Kiuhnm

 ora.
Adesso implementerò una semplice interfaccia grafica per il mio software 
usando tale motore grafico.
Quando l'"hardware" (scritto in C++) sarà completo (praticamente un 
piccolo OS), creerò il linguaggio con il quale scriverò il "software".
Kiuhnm

 In java hai riflessione e genericita' a runtime...
Riflessione e genericità parecchio povere, comunque. 
-- 
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.

 precisione a byte e chi piщ ne ha piщ ne metta. 
Ah, la tipizzazione debole. No, non piace nemmeno a me. Ma ti confesso
che anche buona parte dei cast di C e C++ non li renderei possibili.
Questione di gusti, ben inteso.
Personalmente sono un fan della tipizzazione forte (possibilmente
dinamica). 
Ad ogni modo con VB.Net non ho mai lavorato (in effetti non lavoro su
piattaforma ms, se non a volte dovendo garantire che quello che faccio
'gira *anche* li'). E i problemi piщ grossi di VB non li indicherei a
livello di linguaggio, ma a livello di IDE. 
Complessivamente sono piщ ben disposto a tollerare un cast implicito da
stringa ad intero che a collassare Model, Controller e View e appicciare
il codice applicativo nei bottoni et similia.
E a dire il vero non sono nemmeno un grosso fan degli IDE: preferisco
lavorare con tecnologie intimamente sintetiche che non rendano nemmeno
necessario l'uso del polpettone.


 
Eheh concordo per la tipizzazione come da post precedente, anche se la 
mia posizione non è proprio di quelle radicali. Invece tengo molto di 
più allo stile di scrittura del codice, ma questo è un discorso 
totalmente slegato dal linguaggio per cui mi fermo qui.
Saluti!
Aspidus

 Kiuhnm

 
Ciao
Soviet

 poi non si lascia)
Ha, LOL :)


 entrato in contatto con la sintassi Intel).
si, buona memoria
Mi leggo un po' tutto e al limite ti chiedo qualche altro lume
CUT
Soviet

 farà rimpiangere il C.
Secondo la mia very very IMHO opinion, l'unico modo in cui potresti
riuscirci è prestabilire una quantità enorme di dettagli tecnici che
altrimenti si dovrebbero curare a mano... insomma fare un linguaggio
"customizzato" per una particolare classe di applicazioni o per il
particolare OS... però complimenti per il tentativo, sono davvero
curioso di vedere cosa esce fuori :-)
Per L'ICI è già più facile :-)

 Mi leggo un po' tutto e al limite ti chiedo qualche altro lume
Ok. Eventualmente la mia mail è su gmail nome.cognome.


 totalmente slegato dal linguaggio per cui mi fermo qui.
Pensa, lo stile di scrittura è una delle cose che mi fa preferire la
tipizzazione dinamica. Tipicamente quando mi rendo conto che in Java
devo aggiungere codice con il solo scopo di fare digerire le cose al
sistema dei tipi, bene, per me quello è un (necessario) cattivo stile.
Colpa del linguaggio, chiaro.


 
Le usavo, le usavo.
Però quando andavo a compilare ottenevo errori negli include file DEL
COMPILATORE (windef.h, winnt.h ecc.) e mi sono rotto la testa giorni e
giorni per capire cos'era che non andava...

 quella migliore ;-)
Sisi, li ho letti entrambi... per curiosita', anche se ML non lo capisco 
granche' =) Sono 3 le versioni, se non erro... c'e' anche quello in "C", 
giusto?
--*PaN!* 

 funzionale.
Consigliare linguaggi funzionali e' l'abitudine di tutti i linguisti che 
conosco ;)
Non che mi dispiacciano, beninteso...
purtroppo sono poco applicabili in ambito industriale, in particolare 
inapplicabili nelle consulenze: il cliente vuole qualcosa di leggibile e 
modificabile da lui (anche se e' ipocrisia, perche' non lo fara' mai).
--*PaN!*

 Questione di gusti, ben inteso.
I cast non sono un grosso problema. Il *vero* problema sono le
conversioni automatiche e l'effetto nefasto che hanno sulla
risoluzione degli overload.
Ciao,
Nicola

 gli strumenti effettivi a disposizione nella dura realta' terrena del C++).
Forse è questo il punto centrale di quello che volevo esprimere. Capire 
la differenza tra list e vector (ad esempio). Come faccio a implementare 
un vector in un linguaggio come, per dire, il LISP? Sbaglio o è 
impossibile ottenere un contenitore in cui l'accesso casuale agli 
elementi avvenga in tempo costante? Come farei in python? Immagino che 
dovrei utilizzare l'apposito tipo già bell'e pronto. (sto parlando del 
python senza conoscerlo abbastanza, purtroppo). In C++ li posso 
costruire "veramente", in quanto posso gestire direttamente la memoria.
Non possiamo dire che questo sia "indispensabile" per capire la 
differenza tra un vector e una list?
Un'altro esempio. Vi siete chiesti perché il python ha come tipo 
primitivo i numeri complessi? Qualunque persona direbbe che questo è un 
punto a favore del python... io non credo. Significa che il python non è 
in grado di fornire all'utente gli strumenti per farsi i numeri 
complessi da solo. Lo stesso vale per i numeri a precisione arbitraria. 
Se dovessi implementare i quaternioni? Oppure i polinomi? E' vero che lo 
posso fare, ma non riuscirei ad avere la stessa efficienza e la stessa 
comodità d'uso che si hanno con i tipi predefiniti. In C++, invece, i 
tipi definiti dall'utente sono "sostanzialmente" indistinguibili dai 
tipi primitivi. Potrei ridefinire gli interi, mediante una classe, senza 
perdere efficienza e facilità d'uso rispetto agli int.
E.

 di fornire all'utente gli strumenti per farsi i numeri complessi da solo.
Dipende da come sono inseriti, e sono ignorante in materia Python, quindi 
tralascio un giudizio, ma propongo due alternative:
1) Possono essere implementati in modo identico ma molto inefficiente, 
quindi il linguaggio non pecca a livello sintattico/semantico.
2) Non possono essere implementati senza "accrocchi sintattico/semantici" 
(v. String in java), quindi si sta tentando di nascondere sotto lo zerbino 
una mancanza del linguaggio (overload degli operatori, nell'esempio delle 
String di Java).
Gli accrocchi sintattici non mi piacciono, per questo motivo C++ mi piace 
piu' di molti altri linguaggi... perche' ai problemi del linguaggio viene di 
solito cercata una soluzione, e non una pezza.
--
Marco

 primitivo i numeri complessi? [...]
Quoto in pieno! Non conosco python a sufficienza per usarlo come confronto,
ma credo che il piu' grande punto di forza del C++ sia proprio quello di
lasciare ampio spazio a chi scrive, non fornire cioe' soluzioni pronte,
bensi' le basi per farle. Tocca poi allo sviluppatore, in base alle sue
esigenze e capacita', decidere se utilizzare strumenti di libreria gia'
scritti o svilupparne di nuovi.
Resta il fatto che il C++ e' un linguaggio nato ormai da diversi decenni,
che prende spunto da un linguaggio ancora piu' vecchio, e pertanto si porta
dietro alcuni difetti, dovuti soprattutto alla retro-compatibilita'.
A suo favore occorre pero' ricordare che, anche se con una certa lentezza,
lo standard continua ad evolversi, ed alcuni cose vengono via via
migliorate con le revisioni successive. Penso ad esempio alle evoluzioni
interessanti che si potranno avere grazie alla keyword "auto" ed ai "Rvalue
Reference".
Ciao,
Frank.

 gli strumenti effettivi a disposizione nella dura realta' terrena del C++).
Il punto e' proprio questo: a scrivere codice fetido imparano tutti ed
in generale imparare specifici costrutti non e' poi cosi' complicato.
Imparare ad avere una visione d'insieme, astraendo dal dettaglio e'
molto piu' difficile.
Non saprei dire qual'e' il metodo migliore per arrivarci, ma nella mia
esperienza questa e' la lacuna peggiore e piu' diffusa tra i
programmatori e sarebbe opportuno cercare di ovviare a questo problema
alle origini, perche' dopo e' troppo tardi.
Certo questo e' anche dovuto al fatto che molti ritengono di aver
finito di imparare quando escono dalle scuole e si aspettano che
eventuali ulteriori conoscenze necessarie al loro lavoro gli calino
addosso dall'alto, quasi si trattasse di benefit aziendali.
Ciao,
Nicola

 giorni per capire cos'era che non andava...
bhe il linguaggio allora non centra niente, usavi un compilatore con
include bacati
ciao

 
[SNIP]
salve, ormai frequento pochissimo il ng (dopo aver frequentato assiduamente
e, spero, anche con profitto,  verso la fine degli anni '90 (dico "con
profitto" visto che C e C++ sono stati la mia maggiore fonte di guadagno
fino ad un paio di anni fa).
Scrivo qui ma avrei potuto rispondere a qualsiasi messaggio del thread.
Quello che non capisco bene e' che qui si parla di lentezza
nell'apprendimento, complessita' e robe simili a "sfavore" di C++.
Potra' anche essere vero, ma qualcuno ha provato quella baracca di J2EE
di cui  mi tocca occuparmi dall'anno scorso ?
Io in piu' di un anno, ancora non ho praticamente appreso una mazza!!
E' anche vero che l'impegno che ci metto e' decisamente minore
di quello che ci mettevo per apprendere C++ e che C/C++ li uso
dal 1994 ma a me sembra che
a livello di lentezza  di apprendimento (oltre che lentezza
di esecuzione!!) non ci siano paragoni. E' anche vero che J2EE non e'
solo linguaggio (infatti di java penso di sapere qualcosa, di J2EE molto
meno) eppure J2EE attualmente va alla grande nelle aziende. C++ pare
che bisogna cercarlo con il lumicino (anche se nelle ultime settimane
qualche annuncio di lavoro si vede => ma non potevano metterli 4-5 mesi
fa quando cercavo lavoro ? :-)).
Ciao,
Marco

 risoluzione degli overload.
Vero anche quello.


 gestori della memoria, garbage collector, roba così.
Io mi ci trovo bene anche per fare modellazione di domini applicativi
semanticamente ricchi.
Ciao,
Nicola
P.S. Penso che ci vedremo a Firenze. Nella tana del lupo :-)

 P.S. Penso che ci vedremo a Firenze. Nella tana del lupo :-)
Io temo di no... credo che sarò uno dei pochi organizzatori a non essere
presente. Ho impegni universitari in zona e non so bene come comportarmi
a riguardo.


 perdere efficienza e facilità d'uso rispetto agli int.
Una fava se non perdi efficienza rispetto agli int. Tipicamente perdi il
fatto che la CPU è perfettamente in grado di manipolare interi in modo
nativo, ma non di manipolare classi. Occupano più spazio di sicuro. Per
la velocità ti devi mettere nelle mani del compilatore: sperare che
capisca di avere a che fare con un pazzo che ha creato una classe
isomorfa agli interi e che pertanto deve cercare di usare quanto
possibile l'aritmetica nativa e ignorare il resto.


 di cui  mi tocca occuparmi dall'anno scorso ?
Stai paragonando un *linguaggio* (e con la sola STL riesci a completare
solo compiti parecchio teorici, per quanto affascinanti e difficili) ad
un framework (e tra l'altro un framework overingegnerizzato che fa del
feature-bloat la sua flagship).


 nativo, ma non di manipolare classi. Occupano più spazio di sicuro. 
class squaqquerone {
   int x;
   public:
   /*
   INTERFACCIA
   */
};
Questo occupa esattamente quanto un int. Se non vuoi utilizzare gli int 
all'interno della classe puoi benissimo utilizzare un char[4], anche se 
in tal caso, forse, perderesti efficenza quando vai a definire le 
operazioni tra squaqqueroni.
Se fai un array di 256 squaqqueroni occupi esattamente lo stesso spazio 
che occupa un array di 256 interi. Puoi fare lo stesso in python? ...non 
credo. Credo che se definisci l'analogo dello squaqquerone in python, 
quando fai un array di 256 squaqqueroni in realtà in memoria viene fatto 
un array di 256 puntatotori a 256 zone di memoria diverse che contengono 
ognuna uno squaqquerone. Non giurerei neanche sul fatto che uno 
squaqquerone occupi solo 4 bytes... probabilmente deve contenere anche 
un puntatore per identificare il tipo di dato e suppongo quindi che 
occuperà 8 bytes.
Immagino che sia piuttosto semplice verificare se quello che ho detto è 
giusto, da parte di chi sa utilizzare il python.
E.

 giusto, da parte di chi sa utilizzare il python.
Come ti ho detto, bisogna vedere l'implementazione. 


Ti volevo chiedere una cosa (ma č OT ... su python infatti). 
Potresti ricevere una mail privata per non infastidire altri 
(eccetto te, ovviamente, eh eh he) ? Se si, scrivila oscurata a 
mano nella risposta. Se no, ignora il messaggio, fa niente 
(immagino che tu abbia altro da fare)
ciao e grazie in qualsiasi caso
Soviet

 (eccetto te, ovviamente, eh eh he) ?
Procedi, come ti avevo scritto in un altro thread è il mio nome.cognome
su 
gmail.com
 [ quello fra virgolette è puramente un gioco e non c'entra
nulla ].


 Allora precisiamo, dipende cosa intendi con 'Array'. 
Ok, su questo proverò ad indagare...
E.

 sizeof(squaqquerone)==sizeof(int). 
Probabile. Ho sbagliato io. Resta comunque il fatto che di base il
codice generato è parecchio meno efficiente. E anche se un ottimizzatore
potrebbe migliorare le cose, questo non cambia un fatto fondamentale:
gli squaqquaroni *non* sono interi, e non hai garanzie che il
compilatore li tratti da interi.
class Squaqquarone{
public:
  Squaqquarone(const int i){
    value = i;
  }
  int value;
};
Squaqquarone sum1(const Squaqquarone& s1, const Squaqquarone& s2){
  Squaqquarone ret(s1.value+s2.value);
  return ret;
}
int sum2(int i1, int i2){
  int i3 = i1 + i2;
  return i3;
}
Sulla mia piattaforma abbiamo che la prima somma è definita
.globl __Z4sum1RK12SquaqquaroneS1_
__Z4sum1RK12SquaqquaroneS1_:
LFB6:
        pushl   %ebp
        movl    %esp, %ebp
LCFI5:
        movl    8(%ebp), %eax
        movl    (%eax), %edx
        movl    12(%ebp), %eax
        movl    (%eax), %eax
        leal    (%edx,%eax), %eax
        movl    %eax, 4(%esp)
        leal    -12(%ebp), %eax
        movl    %eax, (%esp)
        call    L__ZN12SquaqquaroneC1Ei$stub
        movl    -12(%ebp), %eax
        leave
        ret
che contiene anche una chiamata a
__ZN12SquaqquaroneC1Ei:
LFB5:
        pushl   %ebp
LCFI0:
        movl    %esp, %ebp
LCFI1:
        subl    $8, %esp
LCFI2:
        movl    8(%ebp), %edx
        movl    12(%ebp), %eax
        movl    %eax, (%edx)
        leave
        ret
mentre la seconda è
.globl __Z4sum2ii
__Z4sum2ii:
LFB7:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp
        movl    12(%ebp), %eax
        addl    8(%ebp), %eax
        movl    %eax, -12(%ebp)
        movl    -12(%ebp), %eax
        leave
        ret
ora questo è un esempio cretino, ma comunque *potenzialmente* viene
generato più codice. Bella forza, uno Squaqquarone non è un int e non
stimerei il C++ maggiormente se prendesse in considerazione che preso da
follia invece che fare un typedef mi creo un nuovo tipo isomorfo ad un
int pretendendo che si comporti come un int con l'efficienza degli int.


 feature-bloat la sua flagship).
Sono d'accordo (nel mio post originale anche io dicevo che J2EE non e' un 
linguaggio). Quello che mi risulta difficile da capire e': perche'
alle aziende piaccia molto la frase "il c++ ha tempi lunghi di apprendimento"
per giustificare l'utilizzo e l' eventuale acquisto 
massivo di "robe" (tipo AS per J2EE appunto) che hanno tempi di apprendimento
assi piu' lunghi di "C++ piu' altre cose" per fare cose che si potrebbero fare 
altrettanto efficacemente e probabilmente meglio,
con "C++ piu' altre cose" (per c++ piu' altre cose intendo ad esempio tutto
cio' che riguarda posix, eventuali sistemi per il web, ecc). Il tempo di
apprendimento di "C++ piu' altre cose"
non credo che sia superiore a quello di apprendimento di J2EE. Per non parlare
del costo di "attrezzi" come BEA Weblogic (per quelle aziende che lo
usano).
Ciao,
Marco.

 usano).
Fondamentalmente perche' il programmatore medio fa meno fatica ad
imparare ad usacchiare un'API, per quanto estesa e complessa, di
quanta non ne faccia per imparare ad usare *bene* un linguaggio di
programmazione.
Se poi abbia senso o meno usare programmatori che non sono in grado di
imparare a usare *bene* linguaggi di programmazione e' un altro paio
di maniche.
Ciao,
Nicola

 a riguardo.
Peccato!
Ciao,
Nicola

 confronto tra C++ e Python.
Se ci pensi, il concetto di 'espressività' è una cosa intangibile
scientificamente. È difficile definirlo in modo preciso, e ci si rischia
sempre di confondere con le 'potenzialità' (ovvero sul cosa posso
esprimere, non sul come posso farlo).


 della classe non si interessa.
Beh, in un certo senso passare un oggetto di una classe derivata ad
una funzione che prende come parametro un oggetto della classe base
costituisce un po' una via di mezzo.
Ciao,
Nicola

interazioni, come minimo
PAROLE SANTE!!
Ciao
F