Perche' scegliere di programmare in C++?

[Nicola Musatti]

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

[Davide Quack]

Post by Nicola Musatti
esiste una categoria di programmi per i quali sceglierei
il C++ come linguaggio di sviluppo, dal punto di vista della comodita'
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.

[Nicola Musatti]

On Mar 11, 3:16 pm, Davide Quack <***@tin.it> wrote:
[...]

Post by Davide Quack
Per esempio io non considero minimamente un problema overloading di
funzioni in Python.
pass
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.

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

[Davide Quack]

Post by Nicola Musatti
In Python
l'overloading non e' possibile perche' non e' possibile discriminare
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++.

[Nicola Musatti]

Post by Davide Quack

Post by Nicola Musatti
In Python
l'overloading non e' possibile perche' non e' possibile discriminare
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++.

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

[Davide Quack]

Post by Nicola Musatti
Non e' che mi serva; trovo piu' pulito separare la gestione di
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.

[Soviet_Mario]

Post by Davide Quack

Post by Nicola Musatti
Non e' che mi serva; trovo piu' pulito separare la gestione di
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.

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

[Davide Quack]

discriminare il tipo dei parametri templatizzanti da dentro al template
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.

[crxor 666]

Post by Nicola Musatti
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.

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.

[crxor 666]

Post by crxor 666
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)

Toh, mi è pure venuta la firma a proposito di Python...

[Nicola Musatti]

Post by crxor 666

Post by Nicola Musatti
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.

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.

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

[Davide Quack]

Post by Nicola Musatti
Sono due soluzioni diverse dello stesso problema. Quella del C++ e'
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.

[crxor 666]

Post by Davide Quack
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ì.

Beh, in C++ è compile time, in Python runtime. Non a caso le differenze
prestazionali non sono irrilevanti. :P

[Davide Quack]

Post by crxor 666
Beh, in C++ è compile time, in Python runtime. Non a caso le differenze
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.

[crxor 666]

Post by Davide Quack
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 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).

[Carlo Milanesi]

Post by Nicola Musatti
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++?

Non e' una questione di senso, ma di opportunita'.

Post by Nicola Musatti
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.

Penso di no. Eccetto alcuni innamorati del linguaggio, come Stroustup,
chi usa il C++ non lo sceglie per la comodita' rispetto a linguaggi di
livello piu' alto. Lo sceglie invece per la comodita' rispetto al
linguaggio assembly, che e' di livello piu' basso, e per le prestazioni
che si possono ottenere rispetto a linguaggi di livello piu' alto.
Bada che per prestazioni ottenibili non intendo solo la velocita' di
esecuzione delle istruzioni, ma anche la velocita' di avvio del
programma, l'occupazione di memoria, e la possibilita' di richiamare API
di basso livello.

Post by Nicola Musatti
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?

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.

[?manu*]

Post by Carlo Milanesi
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.

Anche molto più portabile.

E.

[Nicola Musatti]

[...]

Post by Carlo Milanesi
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.

In realta' usando i template in modo accorto sono convinto che questo
sia vero anche rispetto a Java e C#.

Post by Carlo Milanesi
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.

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

[Davide Quack]

Post by Nicola Musatti
Il discorso cambia se ci si riferisce a linguaggi dinamici. Per
esempio sono convinto che Python abbia potenza espressiva analoga a
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 :')

[Manlio Perillo]

Post by Davide Quack
[...]
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.

Io sto giusto cominciando a studiare Haskell, un linguaggio funzionale
puro da affiancare a C (nota: parlo di C e non C++) e Python.

Nel mio caso, comunque, ho già esperienza in merito (Mathematica, SQL,
XSLT, XForms).

Post by Davide Quack
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 :')

Anche io all'inizio non capivo l'utilità dei decoratori!
E tutt'ora non li uso molto spesso.



Manlio Perillo

[Davide Quack]

Post by Manlio Perillo
Anche io all'inizio non capivo l'utilità dei decoratori!

Quindi adesso ne hai capito il senso. Spiega allora!

[Manlio Perillo]

Post by Davide Quack

Post by Manlio Perillo
Anche io all'inizio non capivo l'utilità dei decoratori!

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

[crxor 666]

Post by Manlio Perillo
In Python 3000 ci saranno delle novità: i decoratori potranno essere
applicati anche alle classi ma non so dirti di più.

Cosa intendi? Anche ora possono essere applicati alle classi.

[Manlio Perillo]

Post by crxor 666

Post by Manlio Perillo
In Python 3000 ci saranno delle novità: i decoratori potranno essere
applicati anche alle classi ma non so dirti di più.

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

[crxor 666]

Post by Manlio Perillo
http://www.python.org/dev/peps/pep-3129/

yep. hai ragione.

[Nicola Musatti]

Post by Davide Quack

Post by Nicola Musatti
Il discorso cambia se ci si riferisce a linguaggi dinamici. Per
esempio sono convinto che Python abbia potenza espressiva analoga a
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.

Non sono sicuro di cosa intendi, ma di certo mi sto riferendo alla mia
situazione specifica. Non sono libero di scegliere qualsiasi
linguaggio per sviluppare; posso giustificare l'uso di C++ o Java al
posto di C# e usare Python per quelle cose dove conta il risultato e
non il codice. Anche il COBOL sarebbe ben accetto, ma quella e'
un'altra storia.

Sono convinto che il C++ non sparira', perche' per applicazioni di
tipo sistemistico e' di fatto insostituibile, indipendentemente dai
tentativi di usare Java per le stesse cose. Resta il fatto che per il
tipo di programmi che presumibilmente dovro' scrivere nel breve/medio
termine il C++ appare sempre meno come un candidato preferenziale.

Post by Davide Quack
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.

Si. Da questo punto di vista sono gli ibridi come C# e Java che mi
lasciano perplesso.

Ciao,
Nicola

[Davide Quack]

Post by Nicola Musatti
Non sono libero di scegliere qualsiasi
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.

[crxor 666]

Post by Nicola Musatti
Da questo punto di vista sono gli ibridi come C# e Java che mi
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++).

[crxor 666]

Post by Davide Quack
Poi ci sono i mei problemi, ad esempio io non riesco a capire la
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)

[Davide Quack]

Post by crxor 666
higher-order functions. Probabilmente se maneggiassi di più i linguaggi
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.

[crxor 666]

Post by Davide Quack
L'esempio che fai dopo è anche interessante, però faccio fatica a
digerirli lo stesso. Sono lontani dal mio modo di lavorare.

E' una posizione legittima, ovviamente. Comodi sono comodi (che so, ci
puoi fare un 'deprecated' che ti logga 'non dovresti usare questa
funzione' e altra roba del genere).

Anche io ci ho messo un po' a capire a cosa potevano servirmi (e non lo
ho capito finchè non mi hanno fatto vedere che era proprio semplice
zucchero sintattico). E confesso di non usarli tantissimo.

Post by Davide Quack
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.

Di F# mi hanno parlato bene, OCaml lo conosco e non è il mio preferito
e... mi fa specialmente piacere che MS spinga la programmazione
dichiarativa nel mondo mainstream.

Post by Davide Quack
Mi guadagno il pane e pago il muto con il C++/C#, vedo di tenermeli
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));

[crxor 666]

Post by Nicola Musatti
Per
esempio sono convinto che Python abbia potenza espressiva analoga a
quella del C++ e sia, malgrado le apparenze, di complessita'
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.

[HappyCactus]

Post by Nicola Musatti
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.

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.

[Davide Quack]

Post by HappyCactus
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.

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 :-)

[HappyCactus]

Post by Davide Quack
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à.

Questo è compito del sistema operativo e del processore, perché
togliergli la palla?

Post by Davide Quack
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 :-)

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ò.

[Davide Quack]

Post by HappyCactus

Post by Davide Quack
Meno page missing, più velocità.

Questo è compito del sistema operativo e del processore, perché
togliergli la palla?

Mica tanto. Il linker decide di mettere la funzione A al byte 0
dell'eseguibile, e la funzione B al byte 2048. Se una pagina è di due
Kb hai che la funzione A è in una pagina di memoria e la pagina B in
un'altra pagina. E le cose non possono cambiare a run-time.

A meno che non stiamo parlando di un JIT. La seconda volta che il
programma parte, avendo dei dati statistici di funzionamento della
prima volta, può prendere decisioni diverse.

Post by HappyCactus
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ò.

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.

[crxor 666]

Post by Davide Quack
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.

Cosa intendi con 'fare un check ogni volta che si accede a una
variabile'? Cosa intendi con 'accedere' e cosa intendi con 'fare un
check'?

Post by Davide Quack
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.

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...

[Davide Quack]

Cosa intendi con 'fare un check ogni volta che si accede a una variabile'?
Cosa intendi con 'accedere' e cosa intendi con 'fare un check'?

a.Quack()

In C++ il check è statico, ma in Python il fatto che ha abbia il metodo
richiamabile Quack viene fatto ogni volta che si incontra questa riga?
Oppure internamente usa metodi "intelligenti" per non fare il check
ogni volta? Poi in C++ tutto si risolve chiamando una funzione.
Sospetto che il Python si cerchi la variabile di nome "a" in un suo
qualche dizionario interno, e poi ci acceda. Almeno un indirizzamento
in più.

Ma come poi diceva un mio collega del Python mentre parlavamo proprio
di questo, "è solo una vtable dinamica" cosa pure furba a pensarci.

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à.

[Manlio Perillo]

[...]
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à.

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

[crxor 666]

Post by Davide Quack
a.Quack()
In C++ il check è statico, ma in Python il fatto che ha abbia il
metodo richiamabile Quack viene fatto ogni volta che si incontra
questa riga? Oppure internamente usa metodi "intelligenti" per non
fare il check ogni volta? Poi in C++ tutto si risolve chiamando una
funzione. Sospetto che il Python si cerchi la variabile di nome "a"
in un suo qualche dizionario interno, e poi ci acceda. Almeno un
indirizzamento in più.

Togliamoci di torno l'ereditarietà per semplificare il tutto. In Python
quando scrivi

a.Quack()

vai precisamente a fare una cosa logicamente equivalente a questo
a.__dict__["Quack"]. Formalizzo meglio

In [4]: def f(a): return a.Quack()
...:

In [5]: dis(f)
1 0 LOAD_FAST 0 (a)
3 LOAD_ATTR 0 (Quack)
6 CALL_FUNCTION 0
9 RETURN_VALUE

In effetti questo è più veloce che chiamare indirettamente il
dizionario che fa invece:

In [6]: def g(a): a.__dict__["Quack"]()
...:

In [7]: dis(g)
1 0 LOAD_FAST 0 (a)
3 LOAD_ATTR 0 (__dict__)
6 LOAD_CONST 1 ('Quack')
9 BINARY_SUBSCR
10 CALL_FUNCTION 0
13 POP_TOP
14 LOAD_CONST 0 (None)
17 RETURN_VALUE


Ma insomma, se a ha direttamente (ovvero non per via ereditaria) un
metodo chiamato "Quack", funzionano tutti e due. Il primo è più
efficiente, ci si appoggia ad un'istruzione della VM altamente
ottimizzata.

Ecco, se in C++ implementassimo un 'dynamic object' che accetta
chiamate di metodo non checkate a compile time (usando la prospettiva
del passaggio di messaggi, qualcosa con una semantica simile a

a.send("Quack", 0);

probabilmente il meccanismo che implementeremmo non sarebbe altrettanto
efficiente del meccanismo della vm python (che è estremamente
ottimizzata). Tuttavia ovviamente la chiamata statica è oltremodo più
efficiente.

Post by Davide Quack
Ma come poi diceva un mio collega del Python mentre parlavamo proprio
di questo, "è solo una vtable dinamica" cosa pure furba a pensarci.

Furba e comoda. Se non hai fretta.

Post by Davide Quack
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.

Beh, dimentica COM. :)
Il ref counting di python funziona bene (oltre tutto ci sono anche
meccanismi per beccare i cicli).

Post by Davide Quack
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à.

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. :)

[Davide Quack]

Post by crxor 666
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.

[Barry Lyndon]

Nel mio caso io faccio l'infrastruttura in C/C++ poi gli "altri" possono
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,

[crxor 666]

Post by Davide Quack
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.

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.

[Davide Quack]

Post by crxor 666
Beh, come dire, non sarà una cosa leggera. Principalmente Python non è
proprio pensato per funzionare in questo modo.

Peggio per python. Il mio problema è che sto scrivendo software per
cluster. Questo ovviamente nei ritagli di tempo tra un programma
stupido e l'altro; cioè i programmi che portano i veri soldi in ditta.
Se fare debug di un'applicazione multithread è qualcosa di tremendo,
farlo in un cluster è micidiale.

Riuscire ad avere una infrastruttura "stabile", e poi variare il codice
in base alle necessità esclusivamente agendo su python sarebbe un passo
avanti notevole a livello di debug.

Fare lo stesso usando delle dll o dell'equivalente in linux sarebbe
invece mortale.

Post by crxor 666
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.

[Davide Quack]

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.

[crxor 666]

Post by Davide Quack
Peggio per python. Il mio problema è che sto scrivendo software per
cluster. Questo ovviamente nei ritagli di tempo tra un programma
stupido e l'altro; cioè i programmi che portano i veri soldi in
ditta. Se fare debug di un'applicazione multithread è qualcosa di
tremendo, farlo in un cluster è micidiale.
Riuscire ad avere una infrastruttura "stabile", e poi variare il
codice in base alle necessità esclusivamente agendo su python sarebbe
un passo avanti notevole a livello di debug.

Capisco. Che dire.. Puoi usare in questo modo cPython, tuttavia non ci
sono particolari facilitazioni. So per certo che ci sono persone che
hanno messo in piedi strutture del genere (seppure con finalità
diverse). Mi limito a dire che non è 'banale'.

Post by Davide Quack
Per ora, a livello mentale, non ho risolto come passare il codice
python da un nodo del cluster e l'altro.

Uhm... vuoi passare codice o bytecode?
Comunque è piuttosto facile la cosa.
Che so, la funzione compile (ce ne è una versione migliore, ma non te
la trovo sui due piedi) è in grado di prendere un 'sorgente' (ovvero un
modulo python, uno statement o un'espressione come 'stringa' e ritorna
un oggetto codice che puoi eseguire con eval oppure lo statement exec.

L'oggetto codice è sostanzialmente inviabile via rete senza problemi. A
fare sta struttura per spedirsi codice qua e la ci va mezzo pomeriggio,
non scherzo. Chiaro, poi devi anche avere una struttura per mantenere
lo stato coerente coi vari algoritmi du 2pc/3pc etc etc etc.

Oppure valuti erlang.

Post by Davide Quack
In realtà non è nemmeno questo il mio problema principale oggi. Il
mio problema oggi è mettere su un sistema di test degli applicativi
valido,

Questo è veramente tosto, in effetti. Ma parli di Python (la risposta è
nose) o di C++?

[Davide Quack]

Post by crxor 666

Per ora, a livello mentale, non ho risolto come passare il codice python da
un nodo del cluster e l'altro.

Uhm... vuoi passare codice o bytecode?
Comunque è piuttosto facile la cosa.

Passare il codice è facile, l'integrazione è difficile. L'integrazione
con il codice C++ che farebbe delle cose a prescindere dal python. Poi
il codice dovrebbe essere sparato in cluster di PC che probabilmente
stanno già elaborando qualcosa, quindi bisognerebbe gestire la coda dei
processi. Poi ci sarebbero i PC che diventano partecipi del cluster ad
elaborazione in corso e quelli che si rompono. Non tutti i nodi
dovrebbero eseguire lo stesso codice. Infine tutto deve macinare alla
massima velocità.

Per ottenere quello che mi interessava ottenere è una grande
complicazione. Per ora tutto è scritto in C++ e pedalare in cui in
python c'è solo l'alimentatore dei batch di elaborazione del cluster.

Post by crxor 666
Oppure valuti erlang.

So che esiste e basta. Che vantaggi avrei usandolo? O meglio, perché
devo valutarlo?

Post by crxor 666

In realtà non è nemmeno questo il mio problema principale oggi. Il mio
problema oggi è mettere su un sistema di test degli applicativi valido,

Questo è veramente tosto, in effetti. Ma parli di Python (la risposta è nose)
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.

[crxor 666]

Post by HappyCactus
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.

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.

[Andrea Francia]

Post by Davide Quack

Post by HappyCactus
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.

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".

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/

[Davide Quack]

Post by Andrea Francia
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.

[Andrea Francia]

Post by Davide Quack

Post by Andrea Francia
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.

Di fatti esistono anche i compilatore come gcj che compilano il bytecode
in codice nativo. C'e' chi dice che le prestazioni sono migliori ma non
ho mai visto dei benkmarch. Riguardo al confronto tra Java e DotNet non
so cosa dire in quanto non ne so niente.

Pero' l'articolo che ho citato non si soffermava tanto sull'aspetto
ovvio dell'interpretazione del bytecode ma su altri aspetti rallentanti,
come ad esempio il fatto che in Java tutte gli oggetti sono creati
sull'heap, e dice che le allocazioni sull'heap costano molto di piu' in
termini di tempo rispetto alle allocazioni sullo stack che si possono
fare con il C++.

Io non ne so abbastanza per dire che se sono d'accordo con chi ha
scritto l'articolo o meno. Volevo solo far notare che c'e' chi non pensa
che il JIT possa risolvere tutti i problemi.

Post by Davide Quack
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.

Cosa?

Post by Davide Quack
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.

Non lo do per scontato, quando ho detto "C'e' chi la pensa in modo
differente" mi riferivo a chi ha scritto l'articolo non al mio pensiero.

Post by Davide Quack
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.

Sono assolutamente d'acccordo.

Post by Davide Quack
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.

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.

[Davide Quack]

e dice che le allocazioni sull'heap costano molto di piu' in termini di tempo
rispetto alle allocazioni sullo stack che si possono fare con il C++.

Non ho commentato quella cosa perché mi sembrava una fesseria. Un
programmatore reale, che non fa programmi giocattolo, normalmente, fa
allocazioni sullo heap, pensa solo all'uso dei container std. Con, tra
l'altro tutte le problematiche di gestione delle allocazioni in un
ambiente multithreading, che non ho la più pallida idea del come siano
gestiti in Java o in dotnet. Non ci credo che le allocazioni nello
stack dei dati delle funzioni sia determinante per le prestazioni,
salvo vedere dei test che lo dimostrino.

Capisco che tu dica: c'è chi la pensa diversamente. Quel che dico io è:
non mi basta che uno la pensi diversamente, vediamo perché la pensa
diversamente.

Poi anche sul costano di più, andiamoci piano. Se allochi e disallochi
costano di più. Per quel che ne so il gestore della memoria del
run-time potrebbe essere intelligente ed usare una parte di heap come
una cache. In quel caso non c'è allocazione o disallocazione, ma solo
referenziazione. Non sapendo come funziona "realmente" il gestore della
memoria ci andrei piano che Java è tutto un allocare e un disallocare.
Forse. Però solo chi conosce il motore sotto può dircelo.

framework del vattelapesca language ed esso potrebbe usare il suo
tempo per fare andare un JIT. [..]

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à.

[crxor 666]

Post by Andrea Francia
Pero' l'articolo che ho citato non si soffermava tanto sull'aspetto
ovvio dell'interpretazione del bytecode ma su altri aspetti
rallentanti, come ad esempio il fatto che in Java tutte gli oggetti
sono creati sull'heap, e dice che le allocazioni sull'heap costano
molto di piu' in termini di tempo rispetto alle allocazioni sullo
stack che si possono fare con il C++.

E' vero che in Java è tutto sull'heap (o quasi) e che questo *costa* di
più. E' anche vero tuttavia che spesso anche in C++ ci sono
programmatori che abusano dell'heap (principalmente perchè è più
comodo).

Ma ci sono anche librerie che incoraggiano questa strada. Presente Qt 2
e 3? Praticamente quasi tutto è sull'heap. E hai poco da farci.

Ma roba a *questo* livello di confronto ha senso praticamente solo per
un nucleo di computazione.

Per dire se vuoi fare un'applicazione pesantemente distribuita e usi
Erlang ti mangi sia Java che C++.

Post by Andrea Francia
Io non ne so abbastanza per dire che se sono d'accordo con chi ha
scritto l'articolo o meno. Volevo solo far notare che c'e' chi non
pensa che il JIT possa risolvere tutti i problemi.

Il JIT *non* può farlo. Esattamente come anche oggi per specifici
compiti ci sono buoni motivi per usare il codice macchina. Basta che il
JIT ne risolva 'abbastanza'.

Poi abbiamo Python che *non* ha JIT (in pratica), è tutt'ora veloce
abbastanza e non ti siede una macchina normale (a differenza di Java)
perchè usa la memoria in modo intelligente e non inserisce 28 strati
software fra la macchina e il codice.

Post by Andrea Francia
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.

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.

[Andrea Francia]

Post by crxor 666
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.

Ad esempio?

[crxor 666]

Post by Andrea Francia
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.

[Denis]

Sono perfettamente daccordo su elaborazioni geometriche e' un must il c++

Post by HappyCactus

Post by Nicola Musatti
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.

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.

[?manu*]

Post by Nicola Musatti
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++?

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.

[Davide Quack]

altri faccio notare che se vuoi scrivere codice per dispositivi con risorse
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.

[?manu*]

Post by Davide Quack
In un mondo in cui i cellulari si programmano anche in Java e Python mi
viene da dire che i tempi cambiano.

Purtroppo i cellulari si programmano soprattutto in Java. Forse per
certe applicazioni può andare bene. Io so (grosso modo) come vengono
fatti i giochi J2ME

- usare il numero minimo di classi (2 o 3) per avere una certa
organizzazione del codice.
- usare solo i tipi predefiniti per memorizzare i dati.
- usare solo variabili statiche
(alla faccia della programmazione OO)

Dopodichè il codice va modificato per sostanzialmente ogni cellulare.
Cioè vengono prodotte un centinaio di diverse versioni del codice per
adattarsi alle caratteristiche dei diversi cellulari (alla faccia della
portabilità).

Post by Davide Quack
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.

No, non è così. Far girare codice python ti richiede quantomento molta
più memoria. La memoria costa. Se devi produrre molte macchine da caffè
ti conviene usare un po' di risorse in più per avere dei programmatori
C/C++ (che paghi una volta) invece che spendere meno per la
programmazione e poi avere un guadagno minore per ogni macchina venduta.

Post by Davide Quack
Comunque viene da dire, se questo vincolo non c'è, vale la pensa di
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.

[Davide Quack]

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++?

[pan]

Post by Davide Quack

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.

Non ne sono convinto... vorrei vedere un programma scritto in java o
c# allocare effettivamente un unico array di dimensione > 4G bytes.
Qualora fosse possibile, con qualche accorgimento, vorrei vedere
quanti programmi stanno adottando questi accorgimenti.

Post by Davide Quack
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

[crxor 666]

Post by pan
vorrei vedere un programma scritto in java o
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.

[pan]

Post by crxor 666

Post by pan
vorrei vedere un programma scritto in java o
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.

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

[crxor 666]

Post by pan
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 :)

Ovviamente un programma che alloca un array di 4 GB non è strettamente
parlando portabile, visto che non necessariamente quella quantità di
memoria è indirizzabile. :)

[pan]

Post by crxor 666

Post by pan
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 :)

Ovviamente un programma che alloca un array di 4 GB non è
strettamente parlando portabile, visto che non necessariamente quella
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

[crxor 666]

Post by pan
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?

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).

[crxor 666]

Post by ?manu*
No, non è così. Far girare codice python ti richiede quantomento
molta più memoria. La memoria costa. Se devi produrre molte macchine
da caffè ti conviene usare un po' di risorse in più per avere dei
programmatori C/C++ (che paghi una volta) invece che spendere meno
per la programmazione e poi avere un guadagno minore per ogni
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.

[?manu*]

Post by crxor 666
Certo, su alcuni dispositivi non hai manco C e su altri manco C++. Ma
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.

[crxor 666]

Post by ?manu*
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.

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.

[Manlio Perillo]

Post by ?manu*

Post by crxor 666
Certo, su alcuni dispositivi non hai manco C e su altri manco C++. Ma
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.

Mica è così facile.

Non tutti i processori hanno le stesse istruzioni e il gcc non può
mettersi a supportare tutti i possibili processori.

Dai una occhiata a:
http://pyastra.sourceforge.net/
http://www.gnupic.org/


Come vedi sono implementati linguaggi "semplici" come Forth e Pascal.

Python è una eccezione perchè:
1) la sintassi base di Python è "relativamente" semplice
2) Python include già un analizzatore di sintassi, quindi con
"poco" codice te la cavi.

Post by ?manu*
E.

Manlio Perillo

[?manu*]

Post by crxor 666
Guarda che io vedo sempre più spesso diffondersi Python *anche*
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.

[crxor 666]

Post by ?manu*
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 Python hai completo accesso alle risorse. Se pensi di usare una
Python VM su un coso embedded, fai in modo che ci siano le librerie per
fare tutto quello che è necessario.

BTW, Python *non* è interpretato.

| In

Post by ?manu*
pratica questi dispositivi sono i telefonini e il linguaggio scelto è
il Java.

Non sempre, e non parlavo di telefonini. Non ti so fare esempi più
concreti. Se chiedi nei ng appositi magari qualcuno ti sa rispondere
con maggiore precisione.

Post by ?manu*
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 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.

[Davide Quack]

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.

[Manlio Perillo]

Post by Davide Quack

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.

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



Manlio Perillo

[Davide Quack]

Post by Manlio Perillo
Questo (rapidità di sviluppo) difatti è probabilmente un problema che è
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.

[Barry Lyndon]

Oggi come oggi ha senso scegliere di scrivere un
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,

[crxor 666]

Post by Barry Lyndon
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>>.

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.

[Davide Quack]

Post by crxor 666
Siccome ho speso molti soldi per un buon martello

Usare il cannone per uccidere le mosche suonava meglio :-)

[crxor 666]

Post by Davide Quack
Usare il cannone per uccidere le mosche suonava meglio :-)

Eh, ma il cannone le abbatte le mosche :)

[Carlo Milanesi]

Post by crxor 666

Post by Davide Quack
Usare il cannone per uccidere le mosche suonava meglio :-)

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.

[Barry Lyndon]

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.

Nell'ambito della programmazione mi sembra esagerato definire il C++ un
<<martello>>.

[Manlio Perillo]

Post by Nicola Musatti
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.

Io avrei un altra questione: quanto conviene usare *un solo* linguaggio
di sviluppo per progetti non banali?

Post by Nicola Musatti
[...]

Manlio Perillo

[Denis]

Post by Manlio Perillo
Io avrei un altra questione: quanto conviene usare *un solo* linguaggio
di sviluppo per progetti non banali?

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

Denis

[Ugo Mendes Donelli]

Post by Nicola Musatti
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.

[...]

Post by Nicola Musatti
Ciao,
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

[Davide Quack]

Post by Ugo Mendes Donelli
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

Questo non lo avevo considerato, ed è una verità sacrosanta.

[Manlio Perillo]

Post by Davide Quack

Post by Ugo Mendes Donelli
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

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

[Davide Quack]

Post by Manlio Perillo

Post by Davide Quack
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?

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).

[Manlio Perillo]

Post by Davide Quack

Post by Manlio Perillo

Post by Davide Quack
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?

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.

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

[Ugo Mendes Donelli]

Post by Manlio Perillo
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.

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

[Davide Quack]

Post by Manlio Perillo
Nel caso esposto da Ugo Mendes, ad esempio, è probabile che i dispositivi
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++.

[Manlio Perillo]

Post by Davide Quack

Post by Manlio Perillo
Nel caso esposto da Ugo Mendes, ad esempio, è probabile che i
dispositivi con cui ha dovuto interfacciarsi non esistano più in
futuro.

Se cambiano, cambiano per tutti i linguaggi. Pace, non ci si può fare
nulla.

Si, infatti.

Post by Davide Quack
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.

Ti faccio un contro esempio con PostgreSQL.
Il protocollo usato per la connessione al backend è praticamente stabile
(attualmente è alla versione 3.0, a partire dalla versione PostgreSQL
7.4).

Di contro, MySQL ha cambiato moltissime volte il suo protocollo.


Alla fine dipende dalla qualità delle persone che ci stanno dietro.
(ed io ho ormai diversi dubbi sulla qualità degli architetti MS).

Post by Davide Quack
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.

Questa è una malattia abbastanza grave.
Personalmente non riuscirei a stare dietro a tutte le ultime novità: io
per assimilare una nuova tecnologia ci messo mesi.

Post by Davide Quack
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++.

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