Newsgroup: it.comp.lang.c++
Titolo: C++11 pare che ci siamo

Ho letto le novitï¿œ nell'articolo qui sotto.
http://www.softwarequalityconnection.com/2011/06/the-biggest-changes-in-c11-and-why-you-should-care/
Cosa ve ne sembra? Personalmente mi aspettavo di piï¿œ, dopo tutto questo
tempo. Mi pare che abbiano incluso poca roba nuova e ottimizzato quello
che c'era giï¿œ. Le lambda e la STL rivista e aggiornata mi sembrano le
due novitï¿œ maggiori.
La nuova modalitï¿œ di inizializzazione e nullptr, a confronto, sono due
cosettine, perï¿œ mi dï¿œ molta soddisfazione veder confermate le mie
opinioni da sï¿œ gran consesso di sapienti :-)
Una domanda l'avrei: perchï¿œ non stabiliscono uno standard binario anche
per il C++ come fu fatto per il C a suo tempo, in modo che si possano
distribuire librerie statiche scritte in C++?

 Una domanda l'avrei: perché non stabiliscono uno standard binario anche


 distribuire librerie statiche scritte in C++?
Cioï¿œ parli di bytecode o roba simile a Java? O altrimenti fino a che 
punto ti spingeresti con lo standard binario? Il codice binario ha 
troppe dipendenze, dall'architettura, dal compilatore. Verrebbero meno 
tutte le caratteristiche di efficienza a cui si puï¿œ arrivare con 
implementazioni del caso.

 [...]
Ciao  Manlio

 
Per ora il GCC (dalla versione 4.3 in su) è quello che supporta più
features. MSVC 2010 e l'Intel compiler seguono a ruota.
Ecco una bella tavola sinottica:
http://wiki.apache.org/stdcxx/C++0xCompilerSupport

 punto ti spingeresti con lo standard binario?
No, no. Non ci siamo capiti.
Quello che ha il C, e che invece il C++ non ha, ï¿œ il fatto di poter
compilare sorgenti con compilatori diversi e di ottenere file oggetto
che possono poi essere linkati insieme senza problemi: una cosa cosï¿œ,
con i file generati dai compilatori C++, NON la puoi fare.
Questo impedisce di distribuire librerie C++ che non siano DLL oppure
codice sorgente da compilare, open source. Una bella seccatura.
E infatti troverai in giro, precompilate, solo librerie scritte in C.

 niente sull'introspezione dinamica ?
Ci sono i template variadici, sï¿œ.
C'ï¿œ l'autodeduzione dei tipi a partire dai valori dati come
inizializzatori, che suppongo sia quello che intendi tu... oppure c'ï¿œ il
decltype, che ï¿œ una funzione che ritorna il TIPO di una espressione, da
usare nei typedef.
Ma forse non ho capito bene cosa intendi.

 distribuire librerie statiche scritte in C++?
class Pippo
{
};
Pippo due[2];
const Pippo * Pluto(const Pippo * p, size_t pos)
{
	return (p+pos);
}
Const Pippo * crash_test = Pluto(due, 1);
Ora se Pluto è dentro un "modulo" compilato con il compilatore X, e chi 
chiama è dentro un modulo compilato con il compilatore Y, dove c'è la 
garanzia che:
sizeof(Pippo del compilatore X) == sizeof(Pippo del compilatore Y)
In verità il problema c'è paro-paro in C.
C'è poi la rogna di chi alloca e chi disalloca avendo moduli 
"distribuibili" in c++. Anche con compilatori dello stesso "costruttore" 
ma con diversa versione ci si fa del male.

 Ma forse non ho capito bene cosa intendi.
Intendevo un ragionevole (anche scarno) sottoinsieme delle 
caratteristiche del system::reflections di dot net.
che poi non penso di essere l'unico a cui piacciano i lussi 
eh :-)
ciao
Soviet

 distribuire librerie statiche scritte in C++?
Ma quale standard binario? Per ogni architettura di processore e per 
ogni sistema operativo c'e' almeno un formato di libreria statica in 
linguaggio macchina. Solitamente il formato prevalente e' quello del 
compilatore C utilizzato (e spesso anche prodotto) dall'organizzazione 
che produce il sistema operativo.
Quello che invece sarebbe auspicabile e' uno standard di codice 
intermedio distribuibile, simile al bytecode di (in ordine temporale) 
Smalltalk, UCSD Pascal, Java, .NET, LLVM.
Tale codice binario indipendente dalla piattaforma potrebbe essere poi 
compilato in linguaggio macchina in fase di installazione, in modo 
ottimizzato per la macchina destinazione. Ovviamente il sistema 
operativo dovrebbe avere integrato il traduttore dal codice intermedio 
al linguaggio macchina.
Questo renderebbe possibile:
- distribuire una sola versione di software, installabile su piu' 
piattaforme, senza distribuire i sorgenti;
- ottimizzare il software per ogni piattaforma attuale e futura;
- velocizzare l'installazione, rispetto a dover ricompilare i sorgenti.
-- 
Carlo Milanesi
http://carlomilanesi.wordpress.com/

 intermedio distribuibile, simile al bytecode di
Scusa, ma lo standard del C++ dice da qualche parte che il risultato
di una compilazione deve essere codice macchina o bytecode?
Direi comunque che questo si può fare già oggi, ma usare il C++ per
generare bytecode non credo sia un problema sentito.
Almeno non mi pare che sotto windows sia una pratica diffusa, e lì si
può fare da svariati anni.

 "distribuibili" in c++.
Questa e' una rogna che (per quanto mi risulta) esiste solo
in Windows e solo con tipi diversi di librerie (release/debug/
monothread/multithread). Usando lo stesso tipo di libreria chi
alloca e chi dealloca non e' un problema.
C:\iao Angelo

 [...]
Ciao  Manlio

 linguaggio macchina.
Vedi la mia risposta ad Anonymous, che poneva la stessa domanda


CUT
ciao
Soviet


Pardon.
Confesso di non conoscere il D e di conoscere molto poco anche il 
Fortran. In un primo tempo avevo scritto "al C e al Fortran", poi ho 
pensato di aggiungerci il D, senza verificare se rimaneva vero quello 
che avevo scritto.


 che avevo scritto.
Il D ha anche altre funzionalità interessanti, sviluppate per la versione 
2.x.
Ciao  Manlio

 sofisficate.
gui sta per GRAPHIC user interface... Veramente, a me non pare che cin e
cout siano "graphic" in qualunque senso le si voglia intendere :-)
Comunque, a me sembra che la GUI sia un pï¿œ fuori dal seminato del C++.
La considero piï¿œ una cosa da linguaggi ad alto livello: il fatto che
praticamente tutti quelli che programmano in C++ per una GUI (windows,
ma pure KDE, Gnome ecc.) usino un framework significa che il C++ ï¿œ
PROPRIO TANTO lontano dalla programmazione GUI... troppo "di basso
livello", per riprendere un termine giï¿œ usato. Se uno ci metteva dentro
librerie per le GUI, allora finiva per metterci pure il garbage
collector, i socket e dio sa cos'altro, ma a quel punto il C++ sarebbe
assomigliato piï¿œ alle Qt o tcl/tk o Java/swing che a un linguaggio di
programmazione normale.
Oddio, potrebbe anche darsi che i "linguaggi di programmazione normali"
siano... come dire? Obsoleti? Meno utili di prima? Puï¿œ anche darsi... ma
comunque il C++ ï¿œ uno di questi :-)

 pu� fare da svariati anni.
Oggi si puo' usare un compilatore C++ per generare codice intermedio, ma 
se poi si installa quel codice intermedio sul computer dell'utente, chi 
lo compila in linguaggio macchina? Devi installare anche il compilatore, 
e dato che per ogni accoppiata architettura di CPU/sistema operativo 
c'e' bisogno di un compilatore diverso, perdi il vantaggio di avere una 
sola versione installabile ovunque.
Sotto Windows non e' molto sentito da chi sviluppa software per una sola 
piattaforma, come la maggior parte dei programmatori. Ma gia' il 
passaggio a 64 bit e' un problema per molti, e poi il software embedded 
o quello per dispositivi smart-phone o tablet spesso deve essere portabile.
Adesso sono emersi due standard di codice intermedio: Java e .NET. Ma 
non mi risulta che ci siano compilatori C++ che generano bytecode Java 
ne' che ci siano compilatori C++ che, partendo da un programma scritto 
in C++ standard, generano codice .NET che funziona anche su Unix (fatemi 
sapere se non e' vero quello che ho scritto).


 comunque il C++ è uno di questi :-)

 In verità il problema c'è paro-paro in C.
Ni. A livello di linguaggio si. A livello di piattaforma ci sono (e
funzionano) una serie di convenzioni ABI, convenzioni di chiamata etc
etc etc per cui le cose funzionano.
In C++ questo non accade *nella pratica*. Quindi al di la del fatto che
in C le cose 'potrebbero' non funzionare, in pratica funzionano perche'
si e' voluto che funzionino.
Per esempio mi risulta che alcuni compilatori C++ fra loro *siano*
compatibili. Perche' si e' voluto fare cosi'.
-- 
-riko
http://www.enrico-franchi.org/
http://rik0-techtemple.blogspot.com/

 Chi ne ha pesantemente bisogno dovrebbe passare a Java o a C#.
Questi sono i classici problemi di "come intendo il linguaggio". Io non
ci entro particolarmente...
GUI sono d'accordo che stia bene *fuori* dal linguaggio. Su
garbage-collection, in pratica aggiungendo gli smart-pointers hanno
aggiunto una forma di garbage-collection (ovvero reference counting) a
richiesta dell'utente. E mi sta bene. 
Avere full garbage-collection non credo che di per se sia un problema:
semmai il punto e' che tende ad essere fuori dal modello di uso del
linguaggio (che ragiona a RAII, quindi si tende a volere predirre
deterministicamente il ciclo di vita degli oggetti). 
Socket e IPC? IMHO una libreria *standard* opzionale ci starebbe
benissimo. Non necessariamente da parte di chi fa il linguaggio. Ma non
credo che si scarti C++ per questo: se uno la vuole la va a prendere,
per dire, da Qt. E' una questione piu' di libreria che di linguaggio,
insomma.
Reflection? Io la trovo *molto* comoda. Al solito, formalmente in C++
esiste, non si usa molto, fa poco o nulla e non saprei nemmeno come si
potrebbe farla funzionare. 
Io personalmente sento sempre meno il bisogno per C++. E' veramente
schiacciato in mezzo a C e a linguaggi di piu' alto livello che stanno
diventando sempre piu' efficienti. Alla fine certo, i videogiochi
vengono sempre in mente. 
Quello che continua ad infastidirmi e' il modo complesso e macchinoso in
cui interagiscono polimorfismo statico e polimorfismo dinamico.


 potrebbe farla funzionare.
Quindi NON la usi.
Scusa ma che cosa intendi con "reflection", e che cosa usi di essa?
Io per reflection intendo la possibilita' di chiamare una funzione 
avendo una stringa che ne contiene il nome. Per esempio:
   function_from_name("f")(3);
sarebbe equivalente a:
   f(3);
Inoltre intendo la possibilita' di ottenere a run-time la lista delle 
funzioni definite in un file o in una classe, o la lista dei parametri 
di una funzione.
Tutto cio' non mi pare che esista attualmente in C++, e neanche che sia 
stato seriamente discusso nel comitato di standardizzazione.
Tutto ciï¿œ secondo me ï¿œ contrario alla buona ingegneria del software 
applicativo.
Effettivamente risulta molto utile per costruire sistemi di testing, 
debugging, logging, compilatori just-in-time e altri manipolatori o 
analizzatori di programmi, ma non per scrivere programmi applicativi.


 sapere se non e' vero quello che ho scritto).
LLVM non ha moduli per la generazione di codice intermedio  simil-bytecode?

 analizzatori di programmi, ma non per scrivere programmi applicativi.
Dipende dalla definizione di "programma applicativo". Certo, tutte le
cose la sopra non lo sono ed e' comodo usare reflection.


Secondo me il motivo percui GUI, Socket e garbage collection non fan 
parte della libreria standard o del linguaggio al momento ï¿œ la scarsitï¿œ 
di tempo a disposizione per concepirli. Semplicemente sono argomenti 
troppo complessi perchï¿œ possano essere affrontati all'unisono ed in 
breve tempo in maniera confacente ad uno standard di qualitï¿œ. Si sarebbe 
rischiati di rimandare tutto di dieci anni ancora, quando magari i 
thread sarebbero eran giï¿œ pronti da un bel pezzo. Questo non giustifica 
che non si possa tentare, ma in un secondo momento, nell'ordine giusto: 
per ora ci teniamo i thread e sopra questi domani ci faremo la GUI.


Qui il produttore  di codice c' entra ben poco
E' possibile costruire analizzatori di sorgenti per poter fare queste cose

 E' possibile costruire analizzatori di sorgenti per poter fare queste cose
Infatti adesso si fa cosi', ma si tratta di un lavoro molto difficile, 
che verrebbe semplificato dalla presenza di informazioni di reflection.
Alternativamente, si salvano tali informazioni in un file affiancato al 
file oggetto, in un formato documentato.
A me sembra sufficiente, e non ritengo opportuno inserire in tutti gli 
eseguibili le informazioni di reflection.


 piuttosto spesso.
Scusate ma di cosa stiamo parlando?
Mai sentito nulla degli "oggetti funzione"? Quella di Java č una 
porcheria perchč non supporta il sovraccaricamento degli operatori!!
operator()() in questo caso.

 monothread/multithread).
Non è quello il problema, così come è non sono sempre una passeggiata 
gli shared object sui vari *nix.


Parlavamo di questo:
http://it.wikipedia.org/wiki/Riflessione_%28informatica%29
che non ha niente a che vedere con gli oggetti-funzione.


 compatibili. Perche' si e' voluto fare cosi'.
gcc sotto windows riesce ad essere compatibile con alcune convenzioni 
microsoft, però già a livello di run-time non c'è storia. Ognuno usa il 
suo. Cosa accettabile in C visto che è normale pensare di passarsi delle 
variabili di tipo const char *, meno in C++ dove può far comodo avere 
una dll o shared object che accetta come paremetro una bella std::string& .


Ti risulta male. Scaricati un banale visual studio express. 
L'attivazione è gratuita. Se ti sta sulle balle la Microsoft allora 
prova questo 
http://www.mono-project.com/CPlusPlus

 Tuttavia e' possibile costruirsi qualcosa che fa una roba del genere
Non esiste, punto. Qualcosa si può fare con le estensioni del 
compilatore. Ma da qui a scoprire a run-time le funzioni di una istanza 
ce ne passa. Qualcosa si può fare con i template con la deduzione dei 
tipi al momento della compilazione.
Comunque io non sento per niente la mancanza della Reflection quando 
programmo in C++.
 > Quando invece davvero *tutto* e' non
 > un oggetto[0] (e si semplifica la fastidiosa dicotomia fra oggetti e
 > oggetti) segue banalmente che anche classi e funzioni sono oggetti.
Allora usa Python, dove il dizionario è la base di tutto. Per me Python 
è decisamente migliore di un linguaggio in cui tutto è "un oggetto". 
Puoi fare cose simili:
class Pippo:
	pass
def Pluto():
	return Pippo()
a = Pippo
b = a()
a = Pluto
c = a()
e sia a che c contengono un'istanza di Pippo. In un linguaggio ad 
oggetti "vero" non credo sarebbe possibile fare una cosa simile. Il C++ 
non si riesce semplicemente a fare una cosa simile.

 prova questo 
http://www.mono-project.com/CPlusPlus
Allora vediamo dove sbaglio.
Ho scritto il seguente programma:
   #include <iostream>
   int main() { std::cout << "Hello, world!" << std::endl; }
Dal prompt dei comandi di Windows scrivo:
 >cl /clr hello.cpp
e ottengo:
Microsoft (R) C/C++ Optimizing Compiler versione 15.00.30729.01
per Microsoft (R) .NET Framework versione 2.00.50727.4214
Copyright (C) Microsoft Corporation.  All rights reserved.
hello.cpp
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.
/out:hello.exe
hello.obj
Poi dal prompt di Linux scrivo:
carlo@Carlo-Mint ~ $ mono /mnt/public/hello.exe
e ottengo:
** ERROR **: Method 
'<Module>:<CrtImplementationDetails>.DoDllLanguageSupportValidation ()' 
in assembly '/mnt/public/hello.exe' contains native code and mono can't 
run it. The assembly was probably created by Managed C++.
aborting...
Stacktrace:
[...]
In sostanza Mono mi dice di non poter eseguire il programma perche' 
contiene del codice nativo.


 
Beh per chi riportava l'esempio "function_from_name("f")(3);" come Java 
reflection, la stessa cosa può essere ottenuta in C++ in modo più sicuro 
con:
template<class F, class T> void function_from_name(F f, T o)
{
	f(o);
}
template<class T>
class F {
public:
	void operator()(T x) {
             std::cout << x;
	}
};
int main(int argc, char**argv) {
     function_from_name(F<int>(), 3);
     function_from_name(F<std::string>(), "C++ reflection?");
     return 0;
}
Cosa c'e' di C++ che non può essere descritto con codice C++ stesso ?
Dove non bastano i template ti scrivi una roba tua... se f(3) la vuoi 
invocare passando a function_from_name() per forza una stringa  (ma a 
che pro?) anzichè un oggetto funzione, non ci vuole niente a costruirsi 
una map che associa stringhe ad oggetti funzione.

 non si riesce semplicemente a fare una cosa simile.
Non conosco Python, magari ti riferisci a qualcosa di particolare che mi 
sfugge, ma perchè non dovresti banalmente riuscirci in C++ ?

 map che associa stringhe ad oggetti funzione.
Evidentemente non hai capito che cosa e' la reflection.
In primo luogo e' una cosa che non c'e' in C++, e quindi non puo' essere 
descritta con codice C++ valido.
In secondo luogo, e' un meccanismo che viene eseguito in fase di 
esecuzione e non in fase di compilazione.
In terzo luogo, e' una cosa implicita nel linguaggio.
Alla chiamata a "function_from_name" devo per forza passare una stringa, 
se tale stringa proviene dall'esterno del programma.
Ovviamente posso risolvere il problema costruendo una mappa che contenga 
tutte le funzioni dichiarate nel programma, ma non e' vero che "non ci 
vuole niente", perche' ogni volta che aggiungo, tolgo, o modifico la 
firma di qualunque funzione del programma, devo ricordarmi di, 
rispettivamente, aggiungere, togliere, o modificare un'istruzione che 
aggiunge una voce a tale mappa. Invece, in un linguaggio che supporta la 
reflection, tale mappa viene generata automaticamente dal compilatore.
Comunque ribadisco che io non sento il bisogno della reflection in C++, 
per i seguenti motivi:
* E' molto meno efficiente, e l'efficienza e' il principale motivo per 
cui si usa il C++.
* Gli errori ortografici non vengono rilevati dal compilatore, e quindi 
sono piu' difficili e costosi da scovare e correggere.
* La molteplicit� di metalivelli (almeno due: codice che manipola i dati 
e codice che manipola il codice) crea maggiore complessita' concettuale.


 che qualcuno le usi massicciamente).
C++ non e' un linguaggio che ha mai teso ad eliminare dallo standard
features potenzialmente pericolose o difficili da usare. In C++ viene
piu' o meno lasciata la liberta' di spararsi spettacolarmente nei piedi
come piu' aggrada.
Aggiungo poi che asserire dedurre dal fatto di usare reflection che il
codice non sia buono e' un poco eccessivo, specie nei confronti di tutti
i progetti la fuori che lo fanno e che *sono* buon codice. 


 una dll o shared object che accetta come paremetro una bella std::string& .
Pensavo semmai all'intel su linux con il gcc. Loro dicono che funziona.


 non si riesce semplicemente a fare una cosa simile.
Vero. Non banalmente almeno. 


 contiene del codice nativo.
Questa è bella. Ammetto di non avere mai fatto la prova perché davo per 
scontata la cosa. Qui a casa non ho una macchina Linux. Quando sono in 
ufficio berrò un caffè in meno, e ne tempo guadagnato proverò a fare 
l'esperimento.
Non capisco la necessità di avere codice nativo con la compilazione 
managed, ma nel caso ne prenderò atto.

 Non mi e' chiaro cosa sia un linguaggio ad oggetti "vero"
Sono un utilizzatore di linguaggi, e non un esperto sui linguaggi. 
Ignoro la definizione di "linguaggio ad oggetti". Comunque nella mia 
mente Python è un enorme dizionario, e non un linguaggio ad oggetti 
classico. Forse classico esprime di più il concetto che voglio esprimere.
In un linguaggio ad oggetti "classico" è molto importante 
l'ereditarietà, e il concetto interfaccia che ne deriva.
// C++
class PippoBase
{
public:
	virtual ~PippoBase(){};
	virtual void Quack();
};
class PippoDerivato: public PippoBase
{
public:
	virtual ~PippoDerivato(){};
};
PippoBase * p = 0;
p = new PippoDerivato();
p->Quack();
In python puoi usare oggetti e i suoi derivati, ma puoi anche fregartene 
bellamente.
# Python
class  PippoSolitario:
	def Quack():
		pass
class Pluto:
	pass
def GenericQuack():
	pass
pluto_che_si_traveste_da_pippo = new Pluto()
pluto_che_si_traveste_da_pippo.Quack = GenericQuack
pluto_che_si_traveste_da_pippo.Quack()
Non metto in dubbio che dal punto di vista formale sia Python che il C++ 
possano essere definiti linguaggi ad oggetti. Ma di sicuro la mia 
programmazione cambia di parecchio a seconda del linguaggio.
Certo potresti obiettare che Python è un linguaggio dinamico, ed è 
quindi normale che l'istanza di un "oggetto" cambi la sua natura durante 
l'esecuzione del programma. Ma se può "cambiare" allora che cosa è la 
natura intrinseca di un oggetto? Ha una sua identità?
Nella mia testa devo "dirmi" che Python non è un linguaggio ad oggetti, 
ma un linguaggio a firme, altrimenti finirei per programmare python in 
stile C++. Nella mia testa un oggetto è qualcosa di concreto e fisso. Se 
nasci come pippo, allora morirai come pippo. Se derivi da pippo, allora 
pippo sarà sempre in te. Se questo non succede devo dire a "me stesso": 
questo non è un linguaggio ad oggetti "classico" devo cambiare registro 
se voglio sfruttarlo.
Capisco però che è un limite mio.
Probabilmente ho fatto il mio tempo, programmo ancora in C++ :-)

 Rimane la questione aperta: ha senso usare il C++?
Questo e' il domandone! (Come disse Amleto)
Molti pensano che abbia senso, in quanto il C++ e' ancora molto usato 
anche per progetti nuovi, in generale meno usato di Java, in ambiente 
Windows meno usato di C# (e forse anche di VB6 + 
VB.NET
), in ambiente 
Posix e per applicazioni embedded meno usato del C, usato da pochissimi 
per applicazioni Web, ma sicuramente in generale e' uno dei 4 linguaggi 
piu' usati professionalmente nel mondo.
Altri, come Torvalds, ritengono che sia inutile, in quanto sia meglio 
usare il C per le routine che richiedono prestazioni di velocita' o di 
memoria, e usare un linguaggio a tipizzazione dinamica dove non servono 
tali prestazioni.
In effetti l'utilizzo del linguaggio C++ e' in netto declino sia per il 
software applicativo per dispositivi mobili, sia per il software 
applicativo per Windows, Mac o sistemi Posix.
Dove guadagna terreno e' in applicazioni che precedentemente venivano 
scritte in assembly, in C o in Fortran. Si tratta di applicazioni che 
hanno grandi porzioni di codice CPU-bound.
In effetti, C# e Java consentono buone prestazioni con i tipi primitivi, 
e consentono astrazioni, ma se si usano le astrazioni si ha uno 
scadimento di prestazioni. C e Fortran consentono ottime prestazioni con 
i tipi primitivi, ma non consentono astrazioni.
Il vantaggio fondamentale del C++ e' che consente astrazioni che hanno 
le stesse prestazioni dei tipi primitivi. In futuro, solo il software 
che sfrutta tale vantaggio verra' scritto in C++.
Le astrazioni sono molto utili per grandi applicazioni (> 100L linee di 
codice).
Le prestazioni sono utili per software di sistema e per applicazioni 
basate su calcoli complessi, come analisi numerica, crittografia, motori 
grafici, motori di database.
Il discrimine non e' tanto se il codice applicativo usa poco o tanto 
l'I/O, ma se usa poco o tanto la CPU. Le applicazioni che passano la 
maggior parte del tempo a macinare istruzioni di CPU (o di GPU), e che 
sono scritte per un gran numero di utenti, e' sensato scriverle in C++.
Un altro fattore e' l'occupazione di memoria. Se un'applicazione 
embedded o un device driver deve stare il 64 KB di memoria, non e' il 
caso di usare il C++, in quanto e' meglio usare l'assembly o il C. Ma se 
si richiede che un'applicazione embedded o un device driver puo' 
occupare piu' di 64 KB di memoria, ma non dovrebbe usare piu' 1 MB o di 
64 MB di memoria, il C++ e' concorrenziale rispetto a linguaggi basati 
su una macchina virtuale.


 Pensavo semmai all'intel su linux con il gcc. Loro dicono che funziona.
Ultimamente mi sono imbattuto nella clausola di compilazione dllexport 
del gcc, o qualcosa di simile. Quando l' ho vista mi è anche caduta la 
mascella sulla scrivania. E' ovvio che lo scopo finale e poterci fare 
una dll che possa essere richiamata da un programma compilato con 
prodotti Microsoft.
Non ho approfondito perché non ero interessato alla questione però.

 Questo e' il domandone! (Come disse Amleto)
In un progetto non esiste solo la velocità, che comunque ti può dare 
anche il C. L'astrazione del C++, in se, non è nulla se non "chiacchiere 
e distintivo". E' utile nel momento in cui gli riconosci la capacità di 
permetterti di gestire meglio i progetti di grosse dimensioni. Però dopo 
tanto tempo di template io ci andrei piano a fare queste affermazioni. 
Con la programmazione ad oggetti e la programmazione che utilizza 
algoritmi generici puoi arrivare a progetti
altamente astratti. Ma anche altamente immantenibili. Va via il 
progettista/codificatore, e l'azienda è praticamente a piedi. Direi 
anche giustamente, ma questa è altra questione.
Onestamente non credo che l'astrazione sia un "di più" particolarmente 
discriminante. Per me oggi la discriminante è la velocità con cui riesci 
a fare un prototipo funzionante, che poi deve andare in giro a far bella 
mostra di se. Il C++ non è così male in questo contesto. La velocità è 
qualcosa che viene dopo, se qualcuno darà i soldi perché il progetto si 
faccia.
Poi anche qui. Hai bisogno di più velocità? Costa meno hardware più 
potente, o "mettere" a posto il software con il suo interminabile ciclo 
di test/debug/correzione ?

 se voglio sfruttarlo.
Boh... io non chiamerei C++ classico. Alan Kay (che ha creato il termine
di programmazione ad oggetti) spiega chiaramente che per lui il focus e'
sullo scambio di messaggi (eventualmente mandandoli anche a chi non li
sa ricevere), non sulle classi. 


 contiene del codice nativo.
Pare che sia un problema noto di Visual Studio che di default usa
codice misto.
La cosa è spiegata in 
http://www.mono-project.com/CPlusPlus
:
Questo codice compila con Visual Studio e si esegue sia sotto Linux
che sotto Windows. Noterai che non è possibile usare la libreria
standard del C++, cosa comprensibile visto che non mi risulta che sia
stata migrata in codice .NET puro, e si debbono usare le estensioni
NET del C++.
Detto ciò compilare del codice C/C++ in bytecode portabile sembra
quasi fattibile. Che sia sensato non credo, ma è altra questione.
using namespace System;
#pragma warning(disable:4483)
 void __clrcall __identifier(".cctor")()
 {
 }
int main(array<System::String ^> ^args)
{
    Console::WriteLine(L"Hello World");
    return 0;
}
flag di compilazione:
/GL /D "WIN32" /D "NDEBUG" /D "_UNICODE" /D "UNICODE" /FD /EHa /MD /
Fo"Release\\" /Fd"Release\vc90.pdb" /W3 /nologo /c /Zi /clr:safe /TP /
errorReport:prompt /FU "c:\Windows\Microsoft.NET\Framework
\v2.0.50727\System.dll" /FU "c:\Windows\Microsoft.NET\Framework
\v2.0.50727\System.Data.dll" /FU "c:\Windows\Microsoft.NET\Framework
\v2.0.50727\System.XML.dll"
flag del linker:
/OUT:"C:\sorgenti\ePapero\test\CppClr\Release\CppClr.exe" /
INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Release
\CppClr.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker'
uiAccess='false'" /NODEFAULTLIB /DEBUG /PDB:"c:\sorgenti\ePapero\test
\CppClr\Release\CppClr.pdb" /LTCG /DYNAMICBASE /FIXED:No /NXCOMPAT /
MACHINE:X86 /ERRORREPORT:PROMPT

 limitiamo ad usare il senso comune.
Scusate se mi intrometto, e` solo per aggiungere due centesimi alla 
discussione.
Con la nascita e la diffusione di linguaggi "orientati agli oggetti" che 
hanno un approccio molto diverso dal "classico" (che classico non e`, ma 
solo diverso) di linguaggi staticamente tipizzati con il C++, sono nate 
anche diverse nomenclature.
Infatti, ultimamente riferendo a linguaggi come il java e il C++ sento 
molto piu` parlare di linguaggi "orientati alle classi" o "class based", 
mentre cose come il ruby e il python a "orientati agli oggetti", e 
secondo me non a torto. Cose come il javascript, invece, vengono 
riferite come "object based".
Ora, la guerra sui nomi potrebbe durare anni e non andremmo da nessuna 
parte. Secondo me, nella discussione voi mischiate un po' due concetti 
che stanno a diversi piani:
Analisi del funzionamento (piu` o meno) interno del linguaggio;
Analisi delle logice e dell'apparenza del linguaggio.
Tanto la differenza tra linguaggi dinamici e statici si affievolisce 
(formalmente) sempre di piu` (vedi elementi di dinamismo infilati nel 
C#, e chiacchiere di lambdas dentro al java), quindi io tendo a 
classificare i linguaggi piu` per la logica e l'approccio che 
consigliano ai problemi, piuttosto che al funzionamento.
Il ruby e` un linguaggio dinamico, tutto e` un oggetto e non esistono 
"veri" tipi base, tutto e` astratto e praticamente tutte le operazioni 
si risolvono in chiamate a metodi (o meglio, passaggio di messaggi tra 
oggetti). Bene, OO con elementi di funzionalismo.
In C++, esiste il forte concetto della definizione delle classi 
inalterabili, spinge molto sulla strutturazione delle gerarchie di 
ereditarieta` per il modellamento dei problemi da risolvere, non c'e` 
introspezione e supporta bene il basso livello. Orientato alle classi, 
procedurale.
Il C#. Esistono tipi base ma possono essere packati per sembrare oggetti 
quando ce n'e` bisogno. L'introspezione e il dinamismo sono features, 
possono come non possono essere usate. Hai bene o male a tua 
disposizione gran parte dei paradigmi, se vuoi usarli. Pero` non tutto 
esiste come oggetto, le operazioni a runtime sono limitate (oggetti non 
dinamici). Sicuramente in futuro il dinamismo verra` ampliato. Una via 
di mezzo tra i due?
Ora, si possono trovare anche dei rapporti 1->1 tra le logiche di 
funzionamento e quelle di utilizzo di questi linguaggi:
C++ ---> compilato, statico
ruby ---> completamente interpretato, jit, sua vm
C# ----> codice intermedio, puo` fare di tutto
ma personalemnte, credo che in futuro il funzionamento dei linguaggi 
sara` sempre piu` intrecciato e svincolato dalle logice che vede 
l'utente. E magari cambiera` a seconda di cosa conviene meglio.


 sa ricevere), non sulle classi.
E' una terminologia che non sentivo da tempo. Più che altro io ero 
abituato a "sentirla" quando mi informavo sui S.O., cosa che mi 
interessava di più dei linguaggi in se.
Tutta internet è un enorme scambio di messaggi. Messaggi riccamente 
stratificati. Http è basata su messaggi che "viaggiano" sul TCP, che a 
sua volta è basata su messaggi, che a sua volta ...
I protocolli di Internet sono tanti linguaggi ad oggetti?

 discussione.
Trovo molto interessante quello che dice, però ci devo riflettere sopra.
Non centra niente, ma trovo interessante anche che la necessità di 
estendere il linguaggio per potere avere gli algoritmi generici sia 
tipica dei linguaggi statici. In un linguaggio dinamico non tipizzato 
staticamente gli algoritmi sono sempre generici.
A me questa cosa mi a posto il quesito: quando non bisogno di 
prestazioni ha senso usare un linguaggio non dinamico? Anche perché in 
C++, almeno con il compilatore Microfost, quando c'è un errore nei 
template, io non ci capisco mai nulla dall'errore che mi riporta il 
compilatore. C'è la teoria che un linguaggio fortemente tipizzato sia 
meno sensibile agli errori, o meglio che il compilatore ti elimini un 
bel po' di problemi alla fonte, ma la mia esperienza tende a farmi 
pensare che sia un falso mito.

 pensare che sia un falso mito.
E' una teoria ovviamente errata: sono d'accordo con te, e' un falso
mito. Per un principiante forse e' vero che buona parte dei problemi
sono di sintassi: quando fai sul serio i problemi sono paralare con il
mondo, business logic, etc etc etc.
Tutta questa roba richiede vari livelli di testing (unit, integration,
etc etc etc) a prescindere dal linguaggio. Purtroppo 'compila ==
funziona' e' una chimera perfino in Haskell.
----
[0] a patto che abbia senso usare Haskell tout court


 I protocolli di Internet sono tanti linguaggi ad oggetti?
Ah... questione delicata. Comunque attenzione:
a.foo() 
hai mandato il messaggio foo all'oggetto a. Solo la sintassi e'
'strana'. Gia' scrivendola come objective-C (o smalltalk) sembra meno
strana
[a foo]
Poi no, non direi che i protocolli sono oggetti, sono semmai
'interfacce'. Ma di fatto potresti vedere un server o un client come un
oggetto. Se astraiamo appena appena finiamo nel mondo della
programmazione ad agenti.


 pensare che sia un falso mito.
Hai provato linguaggi tipizzati fortemente come Haskell, SML o OCaml?
Ciao  Manlio

 C# ----> codice intermedio, puo` fare di tutto
Vorrei poi far notare che parlare di linguaggio statico (staticamente
tipizzato) ha senso. Parlare di linguaggio compilato/interpretato e
combriccola non ha il minimo senso, a meno che nella specifica del
linguaggio ci sia qualche elemento (e a me non risulta).
Per esempio un interprete C e' un'implementazione assolutamente valida
di C. Ne esistono. Allo stesso modo per molti linguaggi ci sono piu'
implementazioni (codice nativo, bytecode, interpretato puro).
In fine, non ha esattamente senso fare differenza fra python e Java, per
esempio, visto che per entrambi l'implementazione di default genera
bytecode. La differenza e' che in java fai una compilazione esplicita
(in python e' implicita). In Java suddetta implementazione ha un JIT, in
Python devi usare pypy. Per dire... 
Mi sa che sta discussione rimarra' congelata per un po' da parte mia
perche' potrei avere connessione ballerina.



Traslasciamo il codice a supporto per il debugging.
Usare la reflection significa generare codice per la classe da 
sottoporre a reflection
L' obiettivo primario del C++ è generare codice efficiente unito alla 
programmazione obj
Tutto è a tempo di compilazione, unica eccezione la RTTI ed il binding 
dinamico sui metodi di classe, che , notare bene, per default non sono 
abilitati.
E' certamente possibile per il compilatore generare codice di reflection 
da abilitare quando voluto, ma non sembra voluto dal comitato.
Personalmente aggiungerei le interfacce simil java; mi piace la 
progettazione a interfacce, e non andrebbe contro la generazione di 
codice efficiente

 Hai provato linguaggi tipizzati fortemente come Haskell, SML o OCaml?
No, mai. Non avendolo fatto da giovane, dubito che potrei farlo adesso 
da vecchio. Dal momento che non ho voglia di "portare" in azienda un 
altro linguaggio, non ho voglia di impararlo. Impararlo per il gusto 
impararlo, senza poi usarlo, non mi sembra il caso. Piuttosto gioco a 
palla con i figli.
A suo tempo ho portato in ditta Python dando il mio contributo (non 
usandolo) alla morte aziendale del PHP e del Perl. Ma già adesso sono 
pentito di averlo fatto. Io spingo per usare Python 3.2, mentre quei 
quattro gatti che lo usano sono fermi al 2.5.x. Questo ha creato un 
problema di versioni fino a quando non ho scoperto come far convivere 
più versioni di python sotto windows. Quel giorno mi sono complimentato 
con chi ha creato Python per l'ottimo e incredibile lavoro.
Poi c'è una grossa parte che della ditta che per imposizioni dei clienti 
usa Java, e "non saperlo" è fonte di sopravvivenza. Già adesso essere il 
"guru" aziendale di Python non è un gran vivere. Anche se la nomea di 
scorbutico rompicoglioni aiuta ad essere poco interpellato.
Su input del capo ho guardato F# ma non ne ho capito il senso nel poco 
tempo che ci ho dedicato. LINQ, che tecnicamente non è un linguaggio, 
invece mi è sembrata una cagata pazzesca.

 programmazione ad agenti.
Sono interfacce perchè non si istanza un "protocollo" ma è solo una 
"lingua" per comunicare messaggi. In questo senso non so se è giusto 
chiamarle interfaccie. Una interfaccia è una lingua?
In effetti se parli di sistema basato sui messaggi ci sono tre "attori". 
Quelli che si spediscono i messaggi, il mezzo con viaggia il messaggio, 
e il protocollo con cui è codificato il messaggio.
Un server web, o un browser, si potrebbe però definirlo un oggetto ad 
alto livello.
La programmazione ad agenti mi fa venire il film "Ghost in the Shell", 
tra l'altro in quel film non c'è la certezza che il comandante Motoko 
Kusanagi sia mai stato cyborg con un anima "umana".
Film a parte mi sembra roba da marketing. Già con DCOM della Microsoft 
potevi far girare remotamente dei programmi. Si può fare in .NET. Ho 
provato a darci una scorsa con google. A me sembra roba indebaggabile. 
La programmazioni ad agenti potrebbe interessare una nicchia 
incredibilmente ristretta di problematiche, ma in generale mi sembra un 
ottimo modo per darsi una zappa sul piede. Non definirei un app che gira 
su un cellulare un esempio di programmazione ad agenti, ma solo un 
classico applicativo client/server come ce ne sono da 50 anni.

 tempo che ci ho dedicato. 
F# e' della stessa famiglia di sml e ocaml. Il senso lo ha eccome, poi
magari puo' non piacere.


 classico applicativo client/server come ce ne sono da 50 anni.
Quella di cui stai parlando non e' programmazione ad agenti.
Fortunatamente i framework ad agenti diffusi hanno strumenti di debug
eccellenti che rendono complessivamente molto piu' semplice il debug
delle applicazioni a livello di agente (perche' hanno il livello di
astrazione giusto per il livello a cui si sta ragionando, quindi ti
fanno vedere messaggi, behavior e compagnia).
Purtroppo la programmazione ad agenti e' tutt altro che marketing. Ha
avuta la solita bolla del cazzo, promesse immantenibili non mantenute,
tracollo dell'IA, etc etc etc. Oggi ci sono un sacco di cose che la
richiamano o sono proprio sistemi ad agenti tout court, solo che per
marketing vengono chiamati diversamente. 
Ma stiamo divagando.
