Newsgroup: it.comp.lang.c++
Titolo: Perche' scegliere di programmare in C++?

Ciao a tutti,
in un recente post Davide Quack ha posto un problema che e' passato
abbastanza inosservato. Oggi come oggi ha senso scegliere di scrivere
un programma in C++?
Ho cominciato a pormi la questione perche' da circa sei mesi due terzi
del codice che scrivo e' in C# ed il terzo rimanente e' in Python. Il
C# e' una scelta imposta, ma per le cose che faccio e' ragionevole;
Python e' insuperabile per quelle cose che stanno nella zona grigia
tra la programmazione e lo scripting. Cosi' mi e' venuto da
domandarmi: esiste una categoria di programmi per i quali sceglierei
il C++ come linguaggio di sviluppo, dal punto di vista della comodita'
di realizzazione? Confesso che non sono sicuro della risposta.
Non e' che non ci sia un rovescio della medaglia: in C# implementare
una parvenza di distruttore o un operatore di uguaglianza e'
allucinante, e in Python sento la mancanza tanto dei distruttori
quanto dell'overloading di funzioni. Pero' quando si scrive codice nel
quale la componente algoritmica e' relativamente ridotta e si fa uso
abbondante di librerie varie questi aspetti perdono di importanza.
Tra l'altro ultimamente mi e' capitato di ficcare il naso
nell'implementazione di un paio di librerie di Boost e mi e' venuto da
chiedermi se una simile complessita' ha davvero senso, se il numero di
linee di codice per funzionalita' "utile" e' davvero giustificato.
Intanto Boost non ha una libreria di accesso a DBMS o un parser XML.
In piu' la prossima versione dello standard conterra' costrutti come i
reference a rvalue o i concetti, che aumenteranno ulteriormente la
complessita' del linguaggio. Ha davvero senso?
Devo dire che per la prima volta da che ho iniziato a programmare in C+
+ sono un po' perplesso.
Ciao,
Nicola

 di realizzazione?
Secondo me sbagli aggettivo. Non è importante la comodità, ma 
l'utilità. Siamo professionisti, e come ogni buon professionista 
dobbiamo avere vari utensili nella nostra borsa degli attrezzi. Il 
bravo professionista usa il linguaggio, il framework, l'ambiente di 
sviluppo che ritiene adatto per quel particolare progetto, anzi per 
quella particolare fase di un progetto.
Per esempio io uso tre editor diversi quando scrivo uno script in 
python (notepad, pyscript, idle) e tre diversi debugger (idle, 
pyscript, pywinpdb).
Per esempio io sto scrivendo una libreria multipiattaforma in C++. 
Usando python avrei avuto tutto gratis. Però l'idea di non potere 
accedere in modo "facile" a tutte le possibilità di un S.O. mi è 
sembrata un'imposizione troppo forte. Tra l'altro ho notato che gli 
ultimissimi windows sono comparse API con interfaccia in C++, giusto 
per mettere una nota di colore. Vincolati a doppia mandata al 
compilatore Microsoft, ma nel mio caso non è un problema.
Per il progetto in questione mi capita di movimentare terabyte di dati 
in un giorno, e questo in un set di una dozzina di computer. Malgrado 
però le apparenze però non considero utile il C++ per la questione 
prestazione. Da quel che vedo un bravo programmatore può cambiare di un 
fattore cento le prestazioni di un prodotto. Però non è da tutti 
arrivare vicino a quel 100. Per esempio ci ho messo un po' a capire 
come fare ad arrivare ad avere throughput degli HD vicino a quello 
teorico. Tieni conto che tutti i S.O. operativi moderni hanno la loro 
cache, e tutti gli HD hanno la loro cache. Le cose, senza il senno del 
poi, non sono così banali. E se vuoi avere un facile accesso al ferro 
il C/C++ sono insuperabili. In Linux non lo so, ma sotto windows in C 
puoi dire al S.O. come si deve comportare con la cache del S.O. stesso 
relativamente a quel file.
Ecco, accesso al ferro, e difficoltà di decompilazione sono dei plus 
interessanti per me. Poi, secondo me, se sei bravo e hai delle 
conoscenze settoriali buone, riesci ad essere abbastanza produttivo su 
una notevole fascia di progetti in C++.
Secondo me però, arrivati a certi livelli programmatori, la differenza 
la fa la forma mentale che deve essere elastica, l'avere un po' di 
tempo per pensare a quello che si fa, avere esperienza, la cultura di 
base, e tante altre cosette del genere. Il linguaggio è solo uno 
strumento.
Per esempio, per me, per essere "produttivi" con il Python uno deve 
cambiare mentalità. Cosa che a me risulta ancora difficile. Non so se 
ti è capitato di vedere Cobra. Ecco, quello è uno che non capito nulla 
di Python e considerava difetti le peculiarità di Python.
Per esempio io non considero minimamente un problema overloading di 
funzioni in Python.
class Papero(object):
  pass
def Quack(txt):
  print( txt )
davide = Papero()
davide.Quack = Quack
davide.Quack( 'Quack' )
Replicarlo in C++ non è complicato, in fondo è solo un puntatore a 
funzione, ma in Python è così naturale. Infondo anche questo è 
overloading.
-- 
Articolo 33 della Costituzione italiana: L'arte e la scienza sono 
libere e libero ne è l'insegnamento

 complessita' del linguaggio. Ha davvero senso?
I linguaggi maggiormente in concorrenza con il C++ sono l'assembly, il 
C, Java e C#. Rispetto al primo, il C++ e' piu' comodo e produttivo. 
Rispetto al secondo permette di creare astrazioni che rendono i grandi 
progetti piu' compatti e manutenibili. Rispetto agli ultimi due consente 
(ma non senza sforzo!) di ottenere migliori prestazioni.
Se stai accedendo pesantemente a un DBMS o a documenti XML, allora le 
opportunita' prestazionali del C++ non emergono. In una tale 
applicazione, risulta pertanto preferibile usare linguaggi di livello 
piu' alto.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 C, Java e C#. Rispetto al primo, il C++ e' piu' comodo e produttivo. 
Anche molto più portabile.
E.

 piu' alto.
Il punto secondo me non e' tanto di livello o per lo meno non solo,
nel senso che Java e C# non si discostano granche' dal C++. Quello che
certamente fa differenza tra il primo ed i secondi sono le librerie
disponibili o la facilita' di reperirle e l'inadeguato riparo da
costrutti avanzati quando si decide di non utilizzarli o di farlo a
"scatola chiusa"; penso ad esempio ai criptici messaggi di errore che
si possono ottenere utilizzando la libreria standard.
Il discorso cambia se ci si riferisce a linguaggi dinamici. Per
esempio sono convinto che Python abbia potenza espressiva analoga a
quella del C++ e sia, malgrado le apparenze, di complessita'
paragonabile. In piu' ha le "batterie incluse", ovvero una libreria
standard notevolmente estesa e tante altre abbastanza facilmente
reperibili.
Ciao,
Nicola

 di realizzazione? Confesso che non sono sicuro della risposta.
Io so solo questo: qualche tempo addietro ho dovuto sviluppare un
software che faceva uso di geometria computazionale, in particolare
della triangolarizzazione di delauny in 3D.
Il vantaggio in termini di velocità dello stesso software scritto e
compilato in C++ e scritto in una qualunque VM o CLR è circa di due
ordini di grandezza.
ciò significa su 100.000 punti da interpolare, una differenza tra la
fattibilità e la non fattibilità.
Idem se dovessi pensare alla realizzazione di un codec a/v.
Pertanto non è il linguaggio in sé, quanto la sua realizzazione pratica.
i vari linguaggi di scripting o che fan uso di CLR/VM non credo saranno
mai in grado di competere con un linguaggio compilato ed otimizzato.
Per il resto il grande vantaggio del .NET framework e, di riflesso, di
C# è, stante così le cose, l'interoperabilità dei linguaggi, cosa che
senza un'api comune, non è facilmente relaizzabile.
Per il resto, concordo con te relativamente alla perplessità.
resta comunque che il C++ è un linguaggio di tutto rispetto, e di sicuro
il mio preferito.

 quella del C++
Meditando sulle tue parole sto arrivando alla conclusione che parti da 
un punto di vista troppo ristretto. Forse per capire in quali ambiti  
programmare in C++ ha un senso ci sarebbe da chiedersi perché 
programmare con un linguaggio dichiarativo o con uno imperativo, oppure 
se usare un linguaggio dichiarativo con una forte tipizzazione statica 
o uno con una forte tipizzazione dinamica.
Meditavo anche sulle parole di Laforgia in un altro gruppo. 
Sicuramente, come giustamente scriveva lui, i template in C++ hanno 
cambiato moltissime cose. Oggi, un professionista del C++ deve sapere 
maneggiare template. Non a caso anche i C# sono stati costretti a 
mettere i generics. Però in un linguaggio a tipizzazione dinamica come 
il Python i template sono privi di senso.
Penso che alla fin fine io uso, quando possibile, il C++ sopratutto per 
la mia ristrettezza culturale. Mi trovo bene con un linguaggio 
imperativo a tipizzazione statica. Faccio fatica a cambiare registro 
con uno a tipizzazione dinamica. Peggio con un linguaggio dichiarativo.
Poi ci sono i mei problemi, ad esempio io non riesco a capire la reale 
utilità dei decoratori in Python o in C#. Ci ho messo un po' di tempo 
per metabolizzare i template. Ma i decoratori proprio non li capisco. 
Per fortuna che in C++, per ora, non ci sono :')


 mai in grado di competere con un linguaggio compilato ed otimizzato.
Su questo non sono poi così sicuro. Per quel ne so è teoricamente 
possibile tirare fuori dal cilindro un jit con prestazioni simili, 
magari migliori, di un compilatore "statico".
Dico che potrebbero essere anche migliori perché un jit potrebbe 
giocare anche sulla frequenza delle chiamate e mantere locali in 
memoria le chiamate più frequenti. Meno page missing, più velocità.
Un tempo sotto valutavo il jit, ora non ho idee chiare in merito.
In fondo non mi occupo di compilatori. Un poco di ignoranza la trovo 
non solo lecita, ma anche sana :-)


 un programma in C++?
Ovviamente dipende dal programma che devi scrivere. Per integrare quello 
che hanno detto gli altri faccio notare che se vuoi scrivere codice per 
dispositivi con risorse limitate ASM/C/C++ possono essere le uniche 
alternative tra cui scegliere. Tra queste tre C++ è quello che ti dà 
maggiore flessibilità.
E.

 solo lecita, ma anche sana :-)
Non è del Jit in sé, o delle librerie. Mi dà l'impressione che avere una
tipizzazione statica e la mancanza del garbage collector permette di
avere molto meno overhead generale.
Giusto a sensazione, però.

 Giusto a sensazione, però.
Se la tipizzazione è dinamica voglia dire che viene fatto un check 
"ogni" volta che si acceda ad una variabile non lo so. Voglio sperare 
di no. Ma non so come funziona "dentro" il pcode prodotto da python. La 
sensazione che non sia qualcosa di pesante alla fine della fiera.
Il "garbage collector", a sensazione, non mi convince. Vedo che però ha 
i suoi sostenitori. Non so. Sospendo il giudizio. La sensazione mia è 
che "mangi" memoria, che l'ambiente rilascierà mediamente mai. Boh. 
Rimango sciettico sull'uso del "garbage collector" in una certa classe 
di prodotti.


 limitate ASM/C/C++ possono essere le uniche alternative tra cui scegliere.
In un mondo in cui i cellulari si programmano anche in Java e Python mi 
viene da dire che i tempi cambiano.
Poi un macchina del caffè magari la programmo in C, ma probabilmente 
una macchina del caffè programmabile in python ha un costo industriale 
identico. Forse. Non mi occupo da tempo di embedded.
Comunque viene da dire, se questo vincolo non c'è, vale la pensa di 
usare il C++? Per esempio il fatto che siano pochi programmatori 
"veramente" bravi in C++ è un problema. Un programmatore appena decente 
in VB si trova magari più facilmente. Poi il VB come linguaggio non mi 
piace un gran che, ma capita che un professionista debba considera 
anche queste condizioni al contorno.
Viene da chidersi se la complessità del C++ sia realmente necessaria 
per avere un linguaggio "potente". Anzi no, spesso mi capita di 
chiedermi se ho bisogno di un linguaggio "potente". Non sempre mi 
rispondo di si.
Però sia chiaro che ho le idee confuse sull'argomento.


 magari migliori, di un compilatore "statico".
C'è chi la pensa in modo diametralmente opposto, ovvero che, perlomeno 
nel caso di Java, il codice che gira sulla VM non sarà mai veloce quanto 
il codice scritto in C++, nonostante i possibili miglioramenti del JIT.
Ecco l'articolo:
 
http://www.jelovic.com/articles/why_java_is_slow.htm
--
Andrea Francia
http://www.andreafrancia.it/

 programma in C++?
Tihanno detto molti ottimi motivi, non sarò certo io a dire l'ultima. Ma 
una cosa <<banale>> non è stata detta: lo si usa perché... lo si sa usare 
bene. Cioè si è speso molto tempo (e forse anche soldi in compilatore) 
per impararlo e si <<capitalizza l'investimento>>. Ma al di là di 
questo... perché uno... lo sa fare. Faccio un esempio stupido: un disegno 
io lo faccio con Autocad, perché lo uso bene. Corel non ho mai imparato 
ad usarlo, non sento la necessità... non ne ho voglia. Con Autocad faccio 
tutto e mi basta, mi soddisfa.
Ciao,

 usare il C++? 
Il problema delle risorse limitate c'è sempre, in misura maggiore o 
minore. Se ci fai caso, tutta l'informatica si occupa principalmente di 
questo: come gestire risorse limitate. Poi è ovvio che con l'aumentare 
delle risorse anche le problematiche cambiano.
E.

 Per fortuna che in C++, per ora, non ci sono :')
Anche io all'inizio non capivo l'utilità dei decoratori!
E tutt'ora non li uso molto spesso.
Manlio Perillo

 overloading.
Il problema dell'overloading come lo intendevo io riguarda la
possibilita' di separare in piu' funzioni con lo stesso nome il
comportamento a fronte di diversi insiemi di argomenti. In Python
l'overloading non e' possibile perche' non e' possibile discriminare
non solo sul tipo, ma anche sul numero di parametri.
Tutt'al piu' uno puo' scrivere funzioni dispatcher che smistano
l'attivita' su funzioni diverse in base al nome, al numero ed al tipo
degli argomenti, verificati a runtime.
Ciao,
Nicola

 Anche io all'inizio non capivo l'utilità dei decoratori!
Quindi adesso ne hai capito il senso. Spiega allora!


 non solo sul tipo, ma anche sul numero di parametri.
Ni. Una volta dentro la funzione puoi discriminare il tipo di parametro 
passato o il numero complessivo di parametri passati, che può essere 
variabile. Certo, lo devi fare tu, e non è gratis grazie al linguaggio.
Più che altro non capisco perché ti serva un overloading alla C++.


 C'è chi la pensa in modo diametralmente opposto
Lo so, ma gli argomenti non sono molto convincenti. Per esempio non è 
che un codice interpretato debba essere per forza eseguito da una 
macchina virtuale. Niente vieta che possa essere compilato in parte o 
tutto nel linguaggio macchina della macchina target. Non so come 
funziona Java, mi sembra che dotnet non sia così piantato, onestamente.
Uno potrebbe dire che il compilatore C++ ha tutto il tempo per 
compilare, mentre il JIT ha vincoli temporali limitati. Ma anche questo 
non so se sia vero. Se il S.O. vedendo di essere sotto carico può 
decidere di chiamare il framework del vattelapesca language ed esso 
potrebbe usare il suo tempo per fare andare un JIT.
Tra l'altro quando uso il gcc, tra -O2 e -O3, non ho mai visto nessuna 
differenza. Non fatto serie misure prestazionali, quindi non se 
l'ottimizzazione è migliore, però posso dire che se c'è non risalta 
troppo. Sono ignorante dei meccanismi fanno funzionare i motori. Non 
dare per scontato che il C/C++ vinca "sempre" a mani basse quanto a 
"velocità". Non tutti scrivono codec.
Poi c'è un'intera classe di problemi che non ha vincoli prestazionali 
stringenti. Un gestionale, ma al limite anche un compressore desktop di 
zip con un'interfaccia amichevole.
Infine, c'è la possibilità che tra un bravo programmatore in Python e 
uno mediocre in C/C++, vinca il primo; ciò il primo consegna prima, il 
codice è più mantenibile, e sia pure più veloce in esecuzione. Tu 
potresti dire che quello stesso programmatore usando il C++ poteva 
produrre codice migliore, anzi più efficiente ed efficace. Però il 
tempo di scrittura ha il suo peso. Io in C/C++ non sono così veloce 
quanto a stesura di codice, su progetti non giocattolo ovviamente. In 
python ti puoi scrivere un server HTTP minimale in una giornata.


 Il problema delle risorse limitate c'è sempre, in misura maggiore o minore.
Ho a che fare con applicativi, non scritti da me ovviamente ;-) , che 
consumano tranquillamente un 1 Gb di memoria. Scritti in dotnet o 
scritti in C o in C++, sempre un GB di memoria *come minimo* parte. Con 
4 applicativi del genere una macchina a 4 processori e S.=. a 32 bit -> 
crash assicurato (prima o poi).
Sto spingendo gli alti vertici aziendali, con scarsissimo successo, 
verso i 64 bit. Ho visto che il passaggio da 32 a 64 per mie le cose 
scritte in C++ è indolore.
Certo con il pcode è tutto trasparente.
Un altro punto a sfavore del c++?


 Quindi adesso ne hai capito il senso. Spiega allora!
Semplice: è solo "zucchero" sintattico :).
Un decoratore è una funzione che prende una funzione come parametro e 
restituisce una funzione come valore di ritorno:
http://en.wikipedia.org/wiki/Higher_order_function
Lo zucchero sintattico consiste nel fatto che non devi applicare la 
funzione "esplicitamente":
@g
def f: ...
invece di:
def f: ...
f = g(f)
dove g è la funziona decoratrice.
In Python 3000 ci saranno delle novità: i decoratori potranno essere 
applicati anche alle classi ma non so dirti di più.
Manlio Perillo

 [...]
Manlio Perillo

 Nicola
Qualche anno fa ho realizzato 3 diversi simulatori di veicolo
ferroviario per un cliente della mia azienda. In C++.
Se dovessi farne un altro oggi, lo farei ancora in C++. Il simulatore
doveva gestire la comunicazione di tutto il bus di veicolo
ferroviario.
Lo farei in C++ per problemi di prestazioni e per problemi di
interfacciamento con le schede che gestiscono il bus di veicolo. Lo
rifarei in C++ per comodità. Ho fatto fare con Simulink, i modelli dei
dispositivi montati sul treno. In questo modo i sistemisti di veicolo
ferroviario potevano verificare il buon funzionamento dei modelli in
un ambiente di sviluppo a loro noto e comunque user friendly. Una
volta verificati i modelli, Simulink mi generava il corrispondente
codice C.
Il simulatore poteva essere installato sulla workstation con le due
schede di comunicazione con un bel "setup.exe".
Il cliente della mia azienda ha poi deciso di far realizzare il quarto
simulatore di veicolo seguendo un approccio di livello più alto.
Questo simulatore è stato realizzato in un tempo doppio con costi
stellari per l'hardware dedicato ( per problemi di prestazione e di
interfacciamento ).
La mia esperienza è principalmente fondata sullo sviluppo di software
per impiego industriale. Quello che ho visto è che con il C++ riesco
ad ottenrere dei prodotti affidabili che si possono manutenere e
modificare ragionevolmente. La mia azienda ed i suoi clienti sono in
grado di gestirli sia sul breve periodo che sul lungo periodo.
E'capitato che qualche cliente richiedesse la realizzazione del
software in VB. Questi applicativi hanno dimostrato, con il tempo, di
essere del tipo usa e getta. Dopo un tot di anni conveniva buttare
tutto e rifare.
Con dei programmi che superano le 100.000 righe di codice (C++), non
mi posso permettere di buttare tutto e cerco di fare attenzione
all'architettura.
Con il C++ ho la ragionevole certezza che lo standard del C++ resterà
stabile per un tempo sufficiente a permettermi di compilare i
programmi scritti oggi anche tra molti anni (C++0x compreso). Inoltre
si tratta di uno standard "serio" (ISO) che evolve sulla base di un
confronto tra molti attori diversi, sia commerciali che non, che tiene
conto di molte esigenze diverse, non ultime quelle delle persone che
con il linguaggio lavorano. Altri linguaggi evolvono in funzione delle
esigenze del marketing delle aziende.
Ho la fortuna di lavorare con dei colleghi molto preparati, con una
cultura forte in C ed in C++. Quindi ho a disposizione diverse persone
preparate con cui confrontarmi. Quando viene assunto un nuovo collega
che non ha la cultura Object Oriented e C++ sufficiente, troviamo il
modo di farlo lavorare un po'con tutti. Così si crea una cultura
tecnica condivisa tra i colleghi e possiamo discutere e lavorare
partendo da basi condivise.
Senz'altro il C++ non è adatto a tutte le applicazioni. Per quanto
riguarda il mio ambiente di lavoro, lo trovo comodo e stimolante.
Ciao, Ugo

 programmi scritti oggi anche tra molti anni
Questo non lo avevo considerato, ed è una verità sacrosanta.


 Questo non lo avevo considerato, ed è una verità sacrosanta.
Non direi.
E' vero che lo standard è stabile, ma come fai a garantire lo stesso per 
le sue implementazioni?
Inoltre magari tra 10 anni i computer non saranno più come sono oggi, e 
non è affatto detto che riuscirai a ricompilare il tuo programma su 
questa nuova generazione di computer.
Manlio Perillo

 le sue implementazioni?
Ancora oggi ci sono compilatori C che accettano quella terribile 
sintassi in cui il tipo dei parametri è definito una riga sotto la 
definizione. Una cosa che ho rimosso, e che quindi non posso spiegare 
meglio.
Nel mondo microsoft, invece, tutto rischia di cambiare drasticamente da 
un giorno all'altro. Per quel che ho visto, ciò che si compilava ieri 
si compila anche oggi con il compilatore nuovo. Dove con ieri si 
possono intedere molti anni, e con oggi ti becchi un compilatore con 
minori bugs, e magari un ambiente di sviluppo migliore.
Poi chiaro, del domani non c'è certezza. Ma rispetto il mondo microsoft 
è l'eden (VB docet).


 Più che altro non capisco perché ti serva un overloading alla C++.
Non e' che mi serva; trovo piu' pulito separare la gestione di
specifiche combinazioni di parametri che non utilizzare if a cascata.
Certo che piuttosto che non avere gli argomenti di default, come ad
esempio avviene in C#, molto meglio Python coi suoi *args e **kwargs.
Ciao,
Nicola

 specifiche combinazioni di parametri che non utilizzare if a cascata.
Capisco. Ultimamente mi sono messo chiamare in modo diverso le funzioni 
che hanno parametri diversi anche in C++. Non vale questa regola per i 
template, in cui magari uso i soliti trucchi per determinare se i 
parametri sono di certi tipi.
Comunque in generale, oggi come oggi, uso molto poco l'overloading.
Perché in C# si siano impuntati a non mettere gli argomenti di default 
non lo capisco. In Python puoi decidere addirittura tu l'ordine dei 
parametri durante la chiamata, cosa comoda se vuoi valorizzare il terzo 
parametro ma usare il default del secondo.


 
Si, ma il problema non è semplicemente essere in grado di compilare un 
programma sintatticamente valido.
Di solito nel programma devi interfacciarti con il mondo esterno, ed è 
questo che cambia abbastanza "rapidamente".
Nel caso esposto da Ugo Mendes, ad esempio, è probabile che i dispositivi 
con cui ha dovuto interfacciarsi non esistano più in futuro.
Manlio Perillo

 puoi scrivere un server HTTP minimale in una giornata.
Sono assolutamente d'accordo. Tant'è che personalmente preferisco 
lavorare con linguaggi a piu' alta astrazione, come il Java, che ti 
permettono di non curarti di alcuni dettagli come quelli relativi ad 
ogni aspetto della gestione della memoria anche se a costo di penalità 
sulle prestazioni.


 parametri sono di certi tipi.
ciao ... se ne sarò parlato mille volte, ma mi rispolvereresti 
per caso la memoria con qualche trucco inerente a quanto sopra 
(discriminare il tipo dei parametri templatizzanti da dentro al 
template stesso, se non ho capito male) ?
CUT
ciao
soviet_mario

  Un altro punto a sfavore del c++?
No, Java e C# semplicemente ti limitano nell'uso della memoria, e'
ovvio che abbiano meno problemi. A stare attenti (come sei stato tu)
il passaggio a 64bit e' indolore anche per il C++. Nel mio caso ho
avuto solo problemi con accesso ad array con indice che risultava
essere unsigned ma che, in taluni casi, diventava negativo. A 32 bit
wrappava, a 64 no. S'e' risolto in mezza giornata su una codebase
fatta di 5 applicazioni e una ventina di librerie, ed il grosso era
solo in una libreria di elaborazione immagini che avevo sviluppato un
po' a tratti, rifattorizzando alla buona codice preesistente....
--
Marco
 
-- 
I'm using an evaluation license of nemo since 208 days.
You should really try it!
http://www.malcom-mac.com/nemo

 con cui ha dovuto interfacciarsi non esistano più in futuro.
Infatti il tipo di bus di veicolo è cambiato quando ho fatto il terzo
simulatore.
Ho scritto un nuovo modulo di interfaccia con l'hardware, che è una
porzione modesta del codice del simulatore. Da quel momento in poi
esso era in grado di supportare sia quello vecchio che quello nuovo.
La maggior parte del codice è rimasta immutata.
Tieni comunque presente che si tratta sempre di applicazioni
industriali. In questo campo le tecnologie cambiano ma gli standard
sono abbastanza stabili.
I modelli di cellulare GSM cambiano ma la norma che stabilisce le
interfacce software del GSM è abbastanza stabile.
Ugo

 il Python i template sono privi di senso.
Si. Da questo punto di vista sono gli ibridi come C# e Java che mi
lasciano perplesso.
Ciao,
Nicola

 linguaggio per sviluppare
Ecco, io ho una discreta libertà, quindi il "quale" linguaggio usare è 
una domanda corrente per me. Di solito la risposta è: uso C++ così uso 
la mia libreria. Di solito, per fare ciò che serve in azienda, quella 
mia particolare libreria mi fa molto comodo. Però le parti 
fondamentali, log a parte, le ho replicate anche in Python, quindi mi 
capita di rispondermi: uso il C++ perché ho fretta, e conosco meglio le 
problematiche che potrebbero capitare.
Poi ci sono altre situazioni in cui la scelta del linguaggio ha 
motivazioni diverse, ma non è la norma.


Cosa? 
Non ci sta scritto da nessuna parte che il codice deve essere 
interpretato o compilato all'esecuzione. Magari Java e Python 
funzionano così, ma non dotnet. Il framework può decidere quando gli 
pare lui di compilare, o ricompilare, programmi/moduli anche non in 
esecuzione. Il problema magari è che appunto la fa, magari piantandoti 
la macchina (mi è capitato con l'installazione di un SP).
Comunque niente vieta che il codice macchina tra due istanze di 
esecuzione sia lo stesso usando un sistema "dinamico" di compilazione. 
E' una scelta il farlo, ma non una necessità.


 con cui ha dovuto interfacciarsi non esistano più in futuro.
Se cambiano, cambiano per tutti i linguaggi. Pace, non ci si può fare 
nulla.
Cosa seccante invece è che il VB N sia bacato in un punto, ma il VB N+1 
non è retrocompatibile. Di solito con i linguaggi standardizzati da 
enti terzi stanno attenti a queste cose.
Tra l'altro questo è il motivo per cui in azienda io uso ODBC per 
interfacciarmi ai DB. E sono rimasto l'unico. Però io uso codice di 10 
anni fa, e gli applicativi sono veloci. Gli altri, tra oledb, pippodb 
caccadb, e tutti quelle straordinarie diavolerie, sono sempre a 
impararsi a tonnellate di documentazione, e ad usare cose sempre più 
assurde.
Come i recordset disconnessi, che in azienda impazzano, e che io trovo 
demenziali per i nostri scopi. Infatti in azienda sono in molti che si 
ritrovano ad inseguire l'ultima novità come speranza risolutoria dei 
problemi contingenti.
Magari è anche per quello che preferisco il C/C++. Ho l'illusione che 
sia qualcosa di abbastanza stabile. L'illusione che non dovrà buttare 
nel cesso le mie conoscenze quando il mio "vendor" domani farà uscire 
la sua nuova release del compilatore c++.


 sua nuova release del compilatore c++.
Alla fine se conosci bene il C++, tanto vale usarlo: specialmente se hai 
creato un set di librerie di supporto.
Io comunque preferisco utilizzare linguaggi diversi, scrivere la parte a 
basso livello in C, e qualla ad alto livello in Python.
Ora sto imparando Haskell, anche se temo sarà dura farlo entrare nel 
ciclo ;-).
Manlio Perillo

 stesso
Con la specializzazione parziale. La versione generica ti dice che NON 
è di un certo tipo, mentre la versione specializzata con il tipo 
preferito ti dice che è di quel tipo.
A grandi linee.


 non solo sul tipo, ma anche sul numero di parametri.
Questo problema in Python *di fatto* non esiste. Mi spiego meglio, tu 
stai cercando di 'tradurre' una soluzione di C++. La soluzione non la 
traduci, il problema lo risolvi.
In Python il modo tipico di fare la faccenda è usando named parameters 
e argomenti di default. In questo modo *non* hai bisogno 
dell'overloading.
-- 
We will perhaps eventually be writing only small modules which are 
identified by name as they are used to build larger ones, so that 
devices like indentation, rather than delimiters, might become feasible 
for expressing local structure in the source language. (Donald E. 
Knuth)

 (Donald E. Knuth)
Toh, mi è pure venuta la firma a proposito di Python...
-- 
If you optimize everything, you will always be unhappy.
Donald Knuth

 paragonabile.
La differenza di complessità è che quella di C++ ti scoppia in faccia 
quasi subito. Ovvero senza prendere contatto con determinati argomenti 
'complessi' fatichi molto a scrivere codice decoroso.
In Python gli argomenti 'tosti' li puoi schivare piuttosto a lungo 
(metaclassi, mro, etc etc etc). Non a caso Python viene spesso usato in 
comunità di non programmatori per risolvere problemi. Questo perchè 
buona parte dei problemi possono essere *ben* risolti con un 
sottoinsieme particolarmente facile del linguaggio.
-- 
A list is only as strong as its weakest link.
Donald Knuth

 reale utilità dei decoratori in Python o in C#.
I decoratori in Python sono solo zucchero sintattico per funzioni che 
prendono in input 'oggetti funzione (quindi funzioni o 'funtori' per 
dirla alla C++)' e hanno per output oggetti funzioni.
Sono insomma zucchero sintattico per funzioni che manipolano funzioni: 
higher-order functions. Probabilmente se maneggiassi di più i linguaggi 
dichiarativi ti verrebbero più naturali.
BTW: io stesso li uso *pochissimo*.
Comunque un decoratore è questo
def dec(f):
  # fai qualcosa e trasforma f in F
  return F
@dec
def foo(): ...
è *esattamente* la stessa cosa di
def foo(): ...
foo = dec(foo)
Esempi 'pratici' non legati alle pippe dei matematici? Puoi farci un 
po' di AOP, logging...
Quest esempio è fatto male, ma tanto per:
def logging(f):
    def aux(*args):
        print "Called %s%s." % (f.__name__, args)
        return f
    return aux
@logging
def addition(a, b):
    return a + b
@logging
def product(a, b):
    return a * b
addition(4, 4)
product(3, 4)
-- 
After more than 30 years of programming we ought to know that the 
design of complex software is inherently difficult.
Niklaus Wirth

 applicati anche alle classi ma non so dirti di più.
Cosa intendi? Anche ora possono essere applicati alle classi.
-- 
Jesus did. I was hopping along, when suddenly he comes and cures me. 
One minute I'm a leper with a trade, next moment me livelihood's gone. 
Not so much as a by your leave. Look. I'm not saying that being a leper 
was a bowl of cherries. But it was a living. I mean, you try waving 
muscular suntanned limbs in people's faces demanding compassion. It's a 
bloody disaster.

 lasciano perplesso.
IMHO non hanno senso di esistere. Il punto è che anni di propaganda in 
un certo senso hanno reso inaccettabile per molti l'uso di un 
linguaggio dinamico. Per cui ci sono le mezze vie alla Java, più 
semplici di C++, ma non comode come Python (e in effetti pure meno 
comode di C++).
-- 
Computers are useless. They can only give you answers.
Pablo Picasso

 Cosa intendi? Anche ora possono essere applicati alle classi.
http://www.python.org/dev/peps/pep-3129/
Mi sembra ne avesse anche parlato Michele Simionato, ma stiamo andando 
fuori tema.
Manlio Perillo

 avere molto meno overhead generale.
Distinguiamo un po' di cose.
1. più ancora della tipizzazione statica conta dove allochi gli 
oggetti. Allocarli sull'heap costa di più, in media. In C++ puoi usare 
(se hai un collo di bottiglia) allocatori ad hoc etc etc etc. In altri 
linguaggi *no*.
2. a questo punto veniamo alla tipizzazione statica. ObjectiveC ha 
tipizzazione dinamica *e* compilazione in codice nativo. La velocità è 
marginalmente più lenta di C++: tipicamente il runtime che va a 
risolvere i nomi usa euristiche e caching molto buoni, per cui le 
faccende funzionano bene.
Il jit permette ottimizzazioni spinte (almeno a livello teorico, poi la 
tecnologia deve arrivarci). Queste ottimizzazioni beneficiano 
relativamente pocco della tipizzazione statica: a runtime anche in caso 
di tipizzazione dinamica *conosci* i tipi. Semmai il problema è usare 
pesantemente liste di oggetti con tipo simile e classe diversa, etc etc 
etc.
Il GC ci si aspetta che addirittura *velocizzi* le operazioni in 
diversi casi non banali. In un SW tipico non hai computazioni 
*costantentemente elevate*. Ci sono spesso tempi di idle: fare gc in 
questi tempi (e non deallocare nei picchi) potrebbe anche aumentare le 
performance.
Io ricordo che senza arrivare a vero e proprio GC avevo scritto una 
libreria per manipolare polinomi e usando tecniche di allocazione e 
deallocazione furba (in pratica non deallocavo quasi mai, se non quando 
non se ne poteva fare a meno) avevo aumentato le performace di oltre un 
ordine di grandezza, per dire. Certo, la versione 'rigorosa' era troppo 
disciplinata per essere efficiente.
-- 
A good designer must rely on experience, on precise, logic thinking; 
and on pedantic exactness. No magic will do.
Niklaus Wirth

 classe di prodotti.
Beh, il GC di cpython dovrebbe piacerti. Di fatto fa reference 
counting, per cui... (questa non è una specifica, è l'implementazione, 
un interprete python può usare la politica che preferisce, un programma 
python che facesse conto sulla distruzione deterministica sarebbe 
errato, in compenso c'è il with_statement).
class Foo(object):
  def __init__(self, value='bog'):
    self.value = value
  def __del__(self):
    print '%s) Oh, my...' % self.value
def p():
  return Foo('p')
def alot():
  Foo('Nobody loves me.')
  return [Foo(i) for i in xrange(10)]
p()
print 'p result was not saved'
x = p()
print 'p result has been saved. No GC.'
del x
print 'x has been deleted.'
alot()
x = alot()
del x
p) Oh, my...
p result was not saved
p result has been saved. No GC.
p) Oh, my...
x has been deleted.
Nobody loves me.) Oh, my...
9) Oh, my...
8) Oh, my...
7) Oh, my...
6) Oh, my...
5) Oh, my...
4) Oh, my...
3) Oh, my...
2) Oh, my...
1) Oh, my...
0) Oh, my...
Nobody loves me.) Oh, my...
9) Oh, my...
8) Oh, my...
7) Oh, my...
6) Oh, my...
5) Oh, my...
4) Oh, my...
3) Oh, my...
2) Oh, my...
1) Oh, my...
0) Oh, my...
-- 
Nevertheless, I consider OOP as an aspect of programming in the large; 
that is, as an aspect that logically follows programming in the small 
and requires sound knowledge of procedural programming.
Niklaus Wirth

 
http://www.python.org/dev/peps/pep-3129/
yep. hai ragione.
-- 
I decry the current tendency to seek patents on algorithms. There are 
better ways to earn a living than to prevent other people from making 
use of one's contributions to computer science.
Donald Knuth

 penalità sulle prestazioni.
Pensa, io vedo Java come un linguaggio a *più basso* livello di 
astrazione rispetto a C++. Poichè ti costringe a scendere e gestire in 
modo manuale una serie di problemini che con C++ non hai. Vale anche il 
viceversa.
Non a caso il language level dei due è generalmente considerato 
comparabile.
-- 
In the practical world of computing, it is rather uncommon that a 
program, once it performs correctly and satisfactorily, remains 
unchanged forever.
Niklaus Wirth

 macchina venduta.
Guarda che io vedo sempre più spesso diffondersi Python *anche* 
nell'embedded.
Certo, su alcuni dispositivi non hai manco C e su altri manco C++. Ma 
questo non vuole dire molto, dipende.
-- 
Python is fast enough for our site and allows us to produce 
maintainable features in record times, with a minimum of developers.  
(Cuong Do, Software Architect, YouTube.com)

 c# allocare effettivamente un unico array di dimensione > 4G bytes.
vorrei anche vedere un programmatore c++ che lo fa. intendo dire un 
programmatore *di buon senso*. magari in campi particolari si fa, ma 
normalmente allocazioni del genere io non ne ho viste mai.
-- 
He must be a king.
Why?
He hasn't got shit all over him.

 per impararlo e si <<capitalizza l'investimento>>.
Siccome ho speso molti soldi per un buon martello e ho imparato ad 
usare il martello, pianto le viti con il martello e stacco i bulloni a 
martellate.
-- 
During the process of stepwise refinement, a notation which is natural 
to the problem in hand should be used as long as possible.
Niklaus Wirth

 questo non vuole dire molto, dipende.
Cosa vuol dire non hai C/C++? Se hai a disposizione un compilatore (e 
già gcc compila per moltissime architetture) quello che metti sul 
dispositivo è codice macchina.
E.

 nell'embedded.
Sì, immagino. Probabilmente se hai un dispositivo sul quale vuoi far 
girare codice esterno senza dargli la possibilità di accedere 
direttamente alle risorse allora è necessario un linguaggio interpretato 
e python sarebbe probabilmente la scelta migliore. In pratica questi 
dispositivi sono i telefonini e il linguaggio scelto è il Java.
Ma su una macchina del caffè non vedo nessun motivo sensato. Considera 
anche che quando devi accedere direttamente all'hardware il C (e quindi 
anche il C++) è il linguaggio più adatto. Union, e campi di bit sono 
(credo) peculiari del C.
E.

 modo manuale una serie di problemini che con C++ non hai. 
Ad esempio?
-- 
Andrea Francia
http://www.andreafrancia.it/

 Ad esempio?
Diventa lungo. I generics sono finti, per cui è una rogna pazzesca fare 
certe cose.
In Java non hai il *minimo* modo di ereditare implementazione. Cosa che 
invece è comoda e perfettamente sicuro. Se non ti piace l'ereditarietà 
multipla, pensa ai mixins.
Ma poi ancora, stare con il polimorfismo dinamico invece che con quello 
statico fa spesso perdere tempo e scrivere più codice.
Se qualcuno pensa che gli stream di C++ siano complessi, guardi quelli 
di Java. Agghiacciante è il termine che reputo più appropriato.
La ridicola idea secondo cui non debbano esistere funzioni fuori dalle 
classi.
Costringermi a gestire le eccezioni in modo non naturale. Il che fa si 
che un sacco di progetti piazzino dei catchall qua e la e che poi ci si 
si scordi di mettere a posto, etc etc etc.


 dispositivo è codice macchina.
Eh, ma spesso e volentieri il codice automatico non è abbastanza parco 
di memoria. Oltre tutto.
Che dirti, di recente un mio caro amico è stato assunto in una ditta 
che fa ste cose e in molti casi devono usare il codice macchina dei 
dispositivi. Lui fa roba che processa segnali, IIRC per 
telecomunicazioni.
-- 
Your highness, when I said that you are like a stream of bat's piss, I 
only mean that you shine out like a shaft of gold when all around it is 
dark

 di bit sono (credo) peculiari del C.
E in Python hai il concetto di pack unpack che ti risolve gli stessi 
problemi.
Dipende dalle risorse: *se* hai un dispositivo non di classe infima e 
ci riesci a fare girare python, può essere che ti convenga farlo. 
Dipende moltissimo.
-- 


 E.
Manlio Perillo

 normalmente allocazioni del genere io non ne ho viste mai.
Beh, se si parla di portabilita' in senso generale, mi sento di
includere anche i campi particolari... in cui peraltro mi son trovato
a lavorare :)
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 210 days.
You should really try it!
http://www.malcom-mac.com/nemo

 dichiarativi ti verrebbero più naturali.
L'esempio che fai dopo è anche interessante, però faccio fatica a 
digerirli lo stesso. Sono lontani dal mio modo di lavorare.
Non centra niente, ma mi sono letto su MSDN il nuovo mirabolante 
linguaggio della Microsoft: F#. Già citare su oclam per me è citare in 
arabo, poi il resto del linguaggio è veramente ostico.
Mi guadagno il pane e pago il muto con il C++/C#, vedo di tenermeli 
stretti.


 Beh, il GC di cpython dovrebbe piacerti. Di fatto fa reference counting,
Il "reference counting" mi fa venire in mente COM, e i sudori freddi. 
Ho provato a dare un'occhiata a cpython ma non è una cosa che io posso 
fare in poco tempo. Ho lasciato perdere per quello. Anche Pyrex 
sembrava interessante da studiare.
Però sono indietro già di tre numeri dei classici di Paperino, uno 
scaffale che aspetta da 6 mesi di essere montato. Non ho tempo anche 
per quello.
Penso che prima o poi integrerò python *dentro* i miei programmi in 
C++. Avere accesso a quella libreria sterminata sarebbe estremamente 
comodo. Adesso spedire una mail usando MIME in C++ è un affare di 
stato, in Python è una scemenza. Però non avendo mai tempo di studiare 
la cosa ritardo. In ditta ho altre priorità.


 ritardo. In ditta ho altre priorità.
Come linguaggio da integrare credo che Lua sia superiore, perchè pensato 
per quello (in Python è un mezzo casino, direi, a meno che non devi fare 
cose veramente semplici).
Manlio Perillo

 dell'overloading.
Certo, pero' il risultato e' che ti tocca affastellare insieme
implementazioni diverse di una stessa operazione concettuale. Siccome
resto convinto che e' meglio estendere il codice che modificarlo,
trovo molto meglio suddividere le implementazioni di cui sopra in
funzioni diverse. Puoi farlo anche in Python, ma al costo di un
dispatching esplicito.
Sono due soluzioni diverse dello stesso problema. Quella del C++ e'
migliore. Detto questo sono consapevole che il motivo per cui in
Python non si puo' avere e' lo stesso che permette altre cose che non
sono possibili in C++.
Ciao,
Nicola

 migliore.
C'è da dire che in C++, in un certo senso, l'if che scrivi è implicito. 
Ciò per tre overloading scrivi tre funzioni in C++ con parametri 
diversi, mentre in Python scrivi una funzione sola ma con uno switch 
con tre case. Esteticamente preferisco la soluzione C++, ma come codice 
siamo lì.
C'è da dire che io uso l'overloading solo in pochi casi particolari, 
quindi non ne sento un gran bisogno. O meglio in C++ mi servono 
*veramente* solo con i template, per il resto dipende da come mi 
sveglio.


 Non sempre, e non parlavo di telefonini. Non ti so fare esempi più concreti.
Potrei rispondere io, se la cosa interessasse. Conosco chi fa embedded 
con python. Il punto, in quel caso, e la rapidità di sviluppo. E' vero 
che con un milione di macchine da caffè guadagni di più a fare la 
logica in C (forse), però devi avere le personi capaci di farlo, e cosa 
più importante il tempo per farlo.
Io ho (anche) usato per un decennio il VB per le supervisioni 
nell'automazioni industriali. Il VB era un linguaggio pessimo, ma si 
abbassavano i tempi di sviluppo in modo drastico.


 abbassavano i tempi di sviluppo in modo drastico.
Questo (rapidità di sviluppo) difatti è probabilmente un problema che è 
diventato predominante solo in tempi "recenti", o sbaglio?.
Manlio Perillo

 diventato predominante solo in tempi "recenti", o sbaglio?.
Da quando lavoro è sempre stato un problema. Poi c'è un secondo 
problema, l'uso di software già esistente. Vuoi l'interfaccia grafica 
"bella", anche se non serve ad un tubazzo? Allora si usa un ambiente 
grafico (windows o un kde per dire). Vuoi che i dati/log allarmi siano 
salvati un database server centralizzato? Insomma, per sopravvivere si 
usa quallo che ti permette di sopravvivere :-)
Quindi anche per governare una "stupida" stampante industriale finisce 
che c'è un PC discretamente carrozzato dietro. Alla fine non sono i 
soldi del PC a fare la differenza.
Ho conosciuto uno che si era fatto un suo S.O. per governare macchine 
per dei proscuttifici. Ci poteva mettere la mani solo lui su quel 
codice (scritto in C++). Troppo complesso. Un genio, ma era codice 
veramente troppo complesso per quel che doveva fare. Alla fine si può 
risparmiare anche mettendo hardware più costoso.


 Siccome ho speso molti soldi per un buon martello
Usare il cannone per uccidere le mosche suonava meglio :-)


 ma come codice siamo lì.
Beh, in C++ è compile time, in Python runtime. Non a caso le differenze 
prestazionali non sono irrilevanti. :P


 stretti.
Bene. Ma fai conto che se usi per bene la stl, fai più programmazione 
dichiarativa di quello che pensi. Dopo tutto fatico a pensare a 
qualcosa di molto più dichiarativo di:
std::copy(v.begin(), v.end(), std::ostream_iterator<...>(std::cout));
-- 
quality of work can be expected only through personal satisfaction, 
dedication and enjoyment. In our profession, precision and perfection 
are not a dispensible luxury, but a simple necessity.
Niklaus Wirth

 studiare la cosa ritardo. In ditta ho altre priorità.
Vero tutto. Embeddare Python dentro C non è complessissimo. Il punto è 
che progettare applicazioni che usino 'bene' questa possibilità non è 
banale. Tipicamente è molto più facile fare chiamare C/C++ da Python. 
Fra le altre cose i nuclei computazionali in C/C++ hanno vantaggi, le 
interfacce in Python pure. :)
-- 
"Python makes us extremely productive, and makes maintaining a large 
and rapidly evolving codebase relatively simple." (Mark Shuttleworth)

 a lavorare :)
Ovviamente un programma che alloca un array di 4 GB non è strettamente 
parlando portabile, visto che non necessariamente quella quantità di 
memoria è indirizzabile. :)
-- 
My duty as a teacher is to train, educate future programmers.
Niklaus Wirth

 Usare il cannone per uccidere le mosche suonava meglio :-)
Eh, ma il cannone le abbatte le mosche :)
-- 
Any inaccuracies in this index may be explained by the fact that it has 
been sorted with the help of a computer.
Donald Knuth

 Tipicamente è molto più facile fare chiamare C/C++ da Python.
Nel mio caso io faccio l'infrastruttura in C/C++ poi gli "altri" 
possono fare i plugin in Python. La complessità sarebbe nascosta dal 
mio codice. Per ora però è solo un'idea, senza un'implementazione 
pilota.
Il caso inverso personalmente l'ho usato recentemente con una 
declinazione diversa. Ho un server scritto in C++ che ad un certo punto 
lancia dei batch in Python con dei parametri di configurazione in un 
modulo Python scritto al volo. Con segnali e stardard input/output 
"piloto" e "controllo" il batch. Poi c'è pure un programmello grafico 
scemo scritto in C# che monitora lo stato di avanzamento del batch 
comunicando con il server in C++ attraverso un socket. Sono abbastanza 
soddisfatto del giocattolo. Ho usato tre linguaggi per abbassare i 
tempi di sviluppo.


 prestazionali non sono irrilevanti. :P
Su questo non sarei sicuro. Dipende. Ci penso spesso, ma non ho una 
risposta chiara perché non so che test dovrei fare per i "miei" casi 
specifici. La sensazione è che dato un certo nostro nucleo che dovrebbe 
rimanere scritto in C, ma che il resto potrebbe essere riscritto nel 
linguaggio K senza perdite significative di prestazioni. Però non mi 
pagano per fare test del genere, quindi rimango con il dubbio.
Il "mio" problema è che il molosso in C/C++ è scarsamente mantenibile, 
e che avrebbe bisogno di manutenzione. Comunque mi consolo pensando che 
fino alla pensione avrò lavoro, se non falliamo prima.


 fare i plugin in Python.
A me queste idee sono sempre piaciute MOLTISSIMO; mi fa piacere che 
qualcuno la pensa un poco come me... Ciao,

 il mio preferito. 


Concordo pienamente meglio usare linguaggi tipo Vb, .net ecc... per 
interfacce ma per sviluppare algoritmi non scherziamo ... si usa il c++!
Denis 

 pilota.
Beh, come dire, non sarà una cosa leggera. Principalmente Python non è 
proprio pensato per funzionare in questo modo.
Oltretutto non riusciresti a fare cose come restricted execution etc 
etc etc.


 rimango con il dubbio.
Il fatto che in Python si facciano programmi *globalmente* efficienti 
(concetto del 'veloce abbastanza') è fuor di dubbio.
Tuttavia a.foo in Python è un'accesso a dizionario, che per quanto 
efficiente non può essere meno costoso che uno spiazzamento in C++. 
Questo è proprio a livello di 'espressioncina' eh, di quello si 
parlava.
Io poi in Python ci faccio pure calcolo numerico (basta usare numpy e 
analoghi :P).


 Oltretutto non riusciresti a fare cose come restricted execution etc etc etc.
Francamente della cosa me ne frego.
Per ora, a livello mentale, non ho risolto come passare il codice 
python da un nodo del cluster e l'altro. Facendo 4 chiacchere sembra 
tutto semplice, ma prendendo un pezzo di carta e disegnando il flusso 
saltano fuori un sacco di problemi pratici e di punti di potenziale 
fallimento. Il maccherone finale mi diventa sempre troppo complesso. 
Boh, ci sto pensando su, magari la soluzione la trovo tra un'anno 
durante una "sessione di lavoro" sul WC (mia fonte di ispirazione 
suprema).
In realtà non è nemmeno questo il mio problema principale oggi. Il mio 
problema oggi è mettere su un sistema di test degli applicativi valido, 
ma ho ancora avuto tempo di studiare cosa realmente sia un "crash 
dump". Non so nemmeno bene dove cercare info.


  ma ho ancora avuto tempo di studiare cosa realmente sia un "crash dump"
Mi rispondo da me, ho trovato questo sito (forse) russo con 
un'interessante bibliografia.


 martellate.
Nell'ambito della programmazione mi sembra esagerato definire il C++ un 
<<martello>>.
-- 
<<L'età della pietra non è finita perché sono finite le pietre>>.

 valido,
Questo è veramente tosto, in effetti. Ma parli di Python (la risposta è 
nose) o di C++?
-- 
During the process of stepwise refinement, a notation which is natural 
to the problem in hand should be used as long as possible.
Niklaus Wirth

 quantità di memoria è indirizzabile. :)
Ho come il sospetto che tu stia eludendo la domanda :)
Vedila cosi', un programma alloca un array di dimensione X, dove X e'
una variabile a 64bit, potenzialmente >4G. Su una macchina adatta,
funziona C++ (domanda retorica)? e Java?
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 214 days.
You should really try it!
http://www.malcom-mac.com/nemo

 o di C++?
In C++, anzi in C/C++. Ho scoperto recentemente che il sistema 
operativo windows mette a disposizioni un sacco di API per il 
monitoraggio e l'analisi post mortem di un processo. Per le vacanze di 
pasqua, tra un gioco con il pupo, e lo spostare qualche divano per 
ordini del comandante supremo della casa, magari mi studio un poco di 
documentazione.
Teoricamente dovrei fare la cosa multipiattaforma, ma per iniziare 
windows va più che bene. Il robo sarebbe un coso del genere.
1) Davide c'è da testare questo programma XYZ.
2) Faccio delle elaborazioni massicce in parallelo su una dozzina di 
computer multicore.
3) Ecco, questi sono i crash dump, questo è stato il consumo di memoria 
in prossimità del crash, e così via. Buon debug.
4) Io torno a scaricare immagini di ippopotami con il computer della 
ditta.
Se riesco a mettere in piedi tutto per la fine del 2008 sono bravo, 
visto che devo farlo nei ritagli di tempo tra una commessa e l'altra.


 funziona C++ (domanda retorica)? e Java?
Questo dalla faq di sun:
How large a heap can I create using a 64-bit VM?
On 64-bit VMs, you have 64 bits of addressability to work with 
resulting  in a maximum Java heap size limited only by the amount of 
physical memory and swap space your system provides.
Il che direi che risponde bene alla tua domanda (su 32 bit mi pare ci 
fosse un limite 'vero', in parte per questioni di OS).
Comunque credo che il problema non sia estremamente significativo. In 
primo luogo sono cose che si fanno di rado (specie in Java o in un 
linguaggio dinamico). In particolare il concetto stesso di 'allocare'. 
IN java ancora ancora, in Python mi prendo la memoria di cui ho bisogno 
per creare gli oggetti di cui ho bisogno.
Tipo adesso ho detto a Python di crearmi una lista di 2**30 elementi. 
Sti sta inchiodando la macchina perchè non ho abbastanza ram libera (ho 
su un fottio di applicazioni, windows emulato da cui scrivo e tutto... 
funziona, non protesta, ma ovviamente il problema è che è una richiesta 
sovradimensionata per la mia macchina -- che dopo tutto ha un GB e 
mezzo di RAM fisica).
-- 
A good designer must rely on experience, on precise, logic thinking; 
and on pedantic exactness. No magic will do.
Niklaus Wirth

 Eh, ma il cannone le abbatte le mosche :)
Appunto per quello la tua metafora e' sbagliata!
Con il C++ si puo' fare qualunque tipo di programma, cosi' come con un 
cannone si puo' uccidere qualunque tipo di animale, mentre con un 
martello non si possono proprio staccare bulloni.
Quando uno ha gia' un cannone e lo sa gia' usare bene, e si trova a 
dover uccidere delle mosche, puo' preferire usare il cannone, anche se 
sembra costare molto di piu' di una paletta pigliamosche, perche' quella 
non la sa usare, e forse non sa neanche che esiste, e a volte perche' si 
lascia convincere dal venditore di cannoni che questi ultimi sono piu' 
efficaci.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila