Newsgroup: it.comp.lang.c
Titolo: C, C++, Linux e Windows [was Re: Qualche domanda su C++ : mi levo i dubbi e poi incomincio ...]

 alla lunga, coloro che cadono nella sua trappola.
Questi sono pareri personali. Il mio e` che l'idea di vedere oggetti ovunque 
non mi piace. Puo` essere stilisticamente piu` carino e aiutare la 
manutenibilita`, ma usarli sempre e comunque non mi piace.
Giulio
[cross-post nei gruppi interessati]

manutenibilita`, ma usarli sempre e comunque non mi piace.
Il C++ non ti obbliga ad usarli -- puoi limitarti ai casi in cui li ritieni
utili; d'altra parte, ti offre invece comunque tanti altri vantaggi, come
il GP e quelli dell'elenco suaccennato -- a fronte di NESSUNO
svantaggio (del linguaggio in quanto tale; se un dato compilatore
é per qualche verso una ciofeca, questo é un altro discorso).
Alex

 é per qualche verso una ciofeca, questo é un altro discorso).
dal momento che compila il codice C non puo` avere svantaggi per 
definizione, e mi pare quindi inutile continuare a dirlo.
Il discorso e` solo sulla effettiva utilita` di usare *tutte* le 
caratteristiche peculiari del C++ *sempre e comunque* 
Giulio
p.s. ripeto: non ho nulla contro il C++ quando effettivamente serve

> piccolo e veloce,
G> che pero` il loro os stronchera` allegramente di tanto in tanto :-)
Sul piccolo e veloce ho molto da ridire.
Al MIT, nei laboratori di Teoria della Computer Science usano C. E non C++.
Perche`  ? Perche`  *E`  +  LENTO*. Sopratutto  quando  cominci a  far
lavorare in  maniera pesante il  runtime support con  metodi virtuali,
template e ammenicoli simili.
Il C++  e` comodissimo per  programmare sotto Win32 finche`  non trovi
qualche simpatica vaccata  nelle classi... (e se mi  chiami ad oggetti
le porcherie fatte da MS con le MFC...)
o   oooooo	Gian Uberto Lauri        "So, are you working on finding
      o    o	
sa...@dei.unipd.it
        that bug *now* or leaving it until
     o o				  later?" - "Yes!" 

 writes:
AM> No.  Il rapporto di superioritá tecnica dei linguaggi é: somma
AM> pesata dei casi in cui si puó lavorare meglio in C++, diviso somma
AM> pesata dei casi in cui si puó invece lavorare meglio in C; il
AM> denominatore é ZERO, e quindi il rapporto é appunto infinito.
######  ####### ####### #
#     # #     # #       #
#     # #     # #       #
######  #     # #####   #
#   #   #     # #       #
#    #  #     # #       #
#     # ####### #       #######


 Giulio
La condizione di parere personale rende forse piu' accettabile quello
che affermi, dato che comunque la disputa fra linguaggi e metodologie e'
associabile piu' ad una guerra di religione che ad una discussione tra
persone in grado di accettare l'opinione altrui qualora si rivelasse
oggettivamente piu' valida.
Alla fine della giostra tu continuerai a programmare 80% C e 20% C++
mentre io continuero' a programmare 95% C++ e (sigh !) 5% C, ed entrambe
saremo contenti della nostra reciproca condizione.
Comunque e' divertente partecipare a queste dispute leggermente
polemiche, se non altro mantiene in allenamento la mente.
massimo



 
Nessuno ha il coraggio di definire OO le MFC (sono semplicemente un
mega-wrapper), e sicuramente non e' comodo programmare OO sotto Win32
perche' sei costratto a porre delle interfacce tra il codice inerente il
dominio dell'applicazione e le MFC stesse (e' una forma di assicurazione
per la salvaguardia del proprio codice).
Anche programmare OO per domini real-time fuori Win risulta molto
pratico e valido (telefonia, process control, imaging e altro...).
Mi sembra limitativo l'approccio che alcuni partecipanti alla
discussione hanno nei riguardi di C++ e OO. Io ho avuto una certa
esperienza di C a cui e' seguito il passaggio al C++. Certo il C++ non
e' OO puro, ma gli altri linguaggi OO che ho provato hanno un'area di
applicabilita' ristretta alle applicazioni di 'business transaction'.
Il C mi piaceva molto, ma il C++ e le metodologie OO sono piu' intuitivi
sia per chi progetta un programma che per chi dopo debba mantenerlo.
Anche i tool di progettazione OO (es. Rose della Rational) permettono di
gestire il ciclo di progettazione con maggior criterio e forniscono in
automatico la documentazione relativa al progetto. In C non ho mai avuto
la fortuna di lavorare con tool di questo tipo.
massimo

 polemiche, se non altro mantiene in allenamento la mente.
il bello e` tutto qui (e il segreto e` non prendersela troppo :-)
Giulio

le porcherie fatte da MS con le MFC...)
Considero MFC una libreria di cattiva qualita', soprattutto perche`
ha chiaramente e clamorosamente "cambiato direzione nel bel mezzo",
passando da una concezione di "straterello sottilissimo sulle API"
(discutibile, certo, ma anche difendibile come scelta architetturale)
a una di "framework onnicomprensivo" (architettura che di per se
sarebbe pure difendibile) -- la mistura delle due (questa, si`, assai
incoerente) abbassa la qualita' del tutto.
Le incoerenze e le debolezze delle MFC, tuttavia, sono da nulla
rispetto a quelle delle "nude API", pensate e fatte per il C...!  Ancora
una volta, dunque, questa non e' una questione di linguaggio: non
esiste linguaggio che impedisca ad un incapace di fare un cattivo
progetto -- e ne` il C, ne` il C++, ci provano neppure (hanno in comune
la filosofia di "tutto il potere al programmatore", a differenza di altri
linguaggi piu` rigidi -- e magari, per questo, piu` difficili da abusare,
ma, mai "impossibili"...).
Alex

Sul piccolo e veloce ho molto da ridire.
nel caso particolare di Windows ti consiglio di visitare
http://www.relisoft.com
Ti consiglio inoltre di imparare come ci si rivolge a persone che sono qui
solo per confrontare le proprie idee e non certo per bersi tutto cio' che un
non ben identificato ed autoproclamato guru scrive :-)
A presto :-)
Marco Abis su IRCnet #C++Warriors
http://welcome.to/C++Warriors
 sito interamente dedicato al C++
http://www.geocities.com/SiliconValley/Foothills/6336
  dedicato al C++
ab...@mv.itline.it

Alex Martelli (
mart...@cadlab.it
) wrote:
: Gian Uberto Lauri wrote in message ...
[ snip ]
: al vertice della risibilita'; e, fra i linguaggi alternativi "piu` ad
: alto livello e piu` facili" rispetto al C++, in linguaggio C, in
: particolare, non trova alcun posto -- se l'unica alternativa da
: considerare per un dato problema e' quella fra C e C++, e i
: compilatori disponibili presentano la stessa qualita` nel loro
: trattamento dei due linguaggi, allora sara' sempre il C++ il 
: preferibile fra i due.
Infatti il C e' un linguaggio a basso livello ;). In quest'ottica, se tu
dovessi fare una piccola utility (100-200 righe), in modo che l'eseguibile
*linkato staticamente con la libreria* sia il piu' piccolo possibile,
cosa sceglieresti ?
 
[ snip ]
: >Sul piccolo e veloce ho molto da ridire.
[ snip ]
: scritto.  Non molto tempo fa fui "sfidato", su it.comp.lang.c++ mi pare,
: a portare un certo programma C++ "sotto la soglia X" (la dimensione 
: che occupava la versione C del programma) -- ebbene, fatto il
: porting a C++ Standard (dal dialetto originalmente usato), e compilato
: il tutto col compilatore piu` diffuso sul mercato con lo switch apposito,
: risulto' codice di circa UN DECIMO di X.
Curiosita': nel calcolo hai contato anche le librerie ?
[ snip ]
: >lavorare in  maniera pesante il  runtime support con  metodi virtuali,
: >template e ammenicoli simili.
[ snip ]
: In codice C++ ben scritto, la chiamata ad un metodo
: virtuale prende il posto di quello che in C sarebbe una chiamata
: indiretta attraverso un puntatore -- senza overhead ne` nulla di
: "pesante" --
Ahem, l'overhead, rispetto ad una normale chiamata di funzione, e' dato
*proprio* dall'indirezione ;)
Ciao ciao
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

sia per chi progetta un programma che per chi dopo debba mantenerlo.
Qui mi trovo a dissentire da te (ma é bello vedere che ci sono ancora
persone civili, da cui si puó dissentire con reciproca cortesia e senza
per questo dover litigare!); secondo me, il C++ non é affatto "intuitivo" --
POTENTE, sí (chi lo metterebbe in dubbio?), ma questa potenza si
paga in termini di complessitá e difficoltá.  Altri linguaggi OO píu semplici
(e la metodologia OO in generale) possono, questo lo ammetto, avere
aspetti intuitivi -- ma ci sono parti della "semantica soggiacente" all'OO
(algebra di Liskov, ho sentito alcuni cominciare, un po' impropriamente!,
a chiamarla) che tutto sono meno che intuitive... e qui non é questione
di linguaggio, é proprio "realtá sottintesa" dal linguaggio stesso.  Ho
passato un tot oggi pomeriggio a spiegare a uno dei miei giovani
colleghi piú brillanti e diligenti il perché e il percome delle regole di
covarianza e contravarianza della (cosiddetta) algebra di Liskov, e
relative concretizzazioni in C++ -- perché un X* si puó passare dove
é richiesto un const X*, ma NON un X** dove é richiesto un const
X** -- ma SÍ dove é richiesto un const X* const* ... "intuitivo"?!  Solo
se sei fra quei rari geni per cui sono "intuitive" la topologia generale,
le algebre di Lie, e la teoria delle funzioni ellittiche, direi...!-)
[La matematica soggiacente ai database relazionali, che ho sentito
chiamare, altrettanto impropriamente, "algebra di Date", e', sono il
primo ad ammetterlo, non meno complessa e anti-intuitiva... non c'é
rimedio: per la maggior parte di noi, la matematica avanzata, per
quanto sia affascinante, e magari anche utile, resta astrusa...!-)].
Alex

partire con un po' di anticipo.
Su questo mi trovi completamente d'accordo -- penso che in effetti,
se e quando fattibile, valga la pena di partire dalle cose semplici e
immediatamente usabili (USARE un ben definito e corretto framework,
prima che non progettarne uno ex novo...!) -- alcuni di noi non dormono
sonni tranquilli sino a quando non capiscono esattamente come si
incastrano fra di loro "gli ingranaggi" delle tecnologie usate, ma questo
tipo di "cultura di base" si puó piú costruttivamente formare col tempo,
parallelamente all'affinamento delle competenze spicciole/specifiche.
Alex

 [etc...etc...etc..]
Ho l'impressione che per te sia molto piu' facile rispondere con facili
ironie che motivare con convinzione le affermazioni che fai riguardo
l'argomento in discussione ;-)
massimo

 >sia per chi progetta un programma che per chi dopo debba mantenerlo.
Bug fix: "Il C mi piaceva molto, ma (il C++ e) le metodologie OO
permettono, se capite ed applicate con correttezza, di ottenere una
maggiore semplicita' di gestione del programma con sia per chi lo
progetta che per chi dopo debba mantenerlo.
Precisazione. Io ho riscontrato, nel passaggio da progetti non-OO a
progetti OO, un tale miglioramento nella qualita' del risultato che non
ho il minimo dubbio nel consigliare le metodologie OO rispetto a quelle
utilizzate normalmente per sviluppare progetti in C (ad esempio).
Sicuramente, una persona che si avvicina per la prima volta alle
metodologie OO, specie se considera le MFC come un esempio, puo'
sviluppare codice ad oggetti molto peggiore del corrispondente codice
non ad oggetti, ma questo penso accada per qualsiasi neofita in
qualsiasi settore.
Purtroppo, in passato ho avuto un momento di 'rilassamento mentale' e
per un certo periodo ho avuto l'ardire di apprezzare le MFC. Oggi ho la
tendenza a considerare quel periodo come un'epoca oscura della mia vita
(Medioevo :-), comunque l'importante e' essere in grado di riconoscere i
propri errori e partire verso nuove avventure ;-)
massimo


 cosa sceglieresti ?
Perche' deve essere il piu' piccolo possibile ? Forse parli di
applicazioni real-time ? Dopotutto, MS con la crescita continua dei
programmi e la richiesta di risorse sempre maggiori sta spianando la
strada a tutti noi facendo in modo che il PC base abbia comunque un
processore veloce, molta ram e ancor piu' HD. Quindi la mia sensazione
e' che, a parte settori particolari, la generalita' delle applicazioni
non richieda eseguibili che siano il piu' piccolo possibile'.
massimo

 l'argomento in discussione ;-)
no, e` solo che non mi va di continuare a ripetere sempre le stesse
motivazioni per altri 7 post (leggi i miei precedenti, penso di aver
gia` espresso con chiarezza tutte le mie opinioni)
l'hai detto tu stesso, alla fine tanto rimarremmo tutti e due con le 
nostre idee. :-)
Giulio.

*proprio* dall'indirezione ;)
Se l'indirezione "non serve", cioé se la situazione é tale che
si puó determinare a tempo di compilazione esattamente cosa
vada chiamato (e magari, se del caso, espanderlo in linea), e
se l'overhead dell'indirettezza é rilevante nel caso specifico
(presumibilmente una funzione molto "leggera" -- se la funzione
esegue per un milione di cicli-macchina, un paio di cicli macchina
in piú all'ingresso sono irrilevanti), allora un "codice C++ ben
scritto", in collaborazione con un compilatore semi-decente, puó
sempre evitare questo overhead (e in effetti, grazie all'inline,
spesso evitare addirittura TUTTO l'overhead della chiamata --
se sono rilevanti il paio di cicli in piú che possono essere dati
dall'indirettezza, a maggior ragione lo saranno la decina o la
ventina di cicli consumati da preparazione di stack/argomenti,
chiamata, ritorno!).
Si tratta, in realtá, di casi piuttosto rari nella maggior parte delle
applicazioni -- il meccanismo di indirettezza utilizzato dal C++
é estremamente veloce, potenzialmente piú veloce di quello
che un programmatore potrebbe scriversi in C (parlo dell'uso
di "thunk" in linguaggio macchina generati "al volo" per questo
specifico scopo).  Ma nel caso su cento in cui puó diventare
comunque importante, il C++ dá gli strumenti necessari, e/o
permette al compilatore le ottimizzazioni cruciali (ma qui si
comincia a richiedere un compilatore un poco piú che non
solo "semi"-decente).
Il C++ si distingue fra tutti i linguaggi ad oggetti proprio per
la sua _maniacale_ attenzione alle prestazioni, specificamente
alla possibilitá per un programmatore altrettanto monomaniaco,
e di grandissima abilitá, di spremere ogni byte, o ogni ciclo di
macchina, dal suo codice (secondariamente, alla possibilitá
per un compilatore di eseguire ottimizzazioni aggressive e
spinte -- su questo fronte, ci sono limiti dovuti alla decisione
di mantenere compatibilitá col C; il maggior limite, in comune
con il C, é il rischio di aliasing dei puntatori, che impedisce ad
un compilatore ISO C e ISO C++ puro di sfruttare le unitá di
calcolo vettoriale con la stessa efficienza con cui potrebbe
farlo un compilatore Fortran -- spesso, infatti, si vedono delle
estensioni non-standard, come #pragma, switch di compilazione,
eccetera, per aggirare questo specifico problema).
Alex

 
Giusto anche in questo caso. Ho avuto modo di partecipare a progetti OO
con programmatori freschi, freschi nella metodologia OO dopo, ad
esempio, un corso di 4-10 gg. Un dramma, un sacco di tempo perso a
cercare di far capire i principi basilari e l'utilizzo dei pattern, ad
eliminare la dipendenza ciclica tra i diversi moduli e cosi via...
Questo e' decisamente il motivo determinante nella scelta di molte
aziende di continuare a mantenere il codice 'legacy' senza prevedere il
passaggio a nuove metodologie e/o nuovi linguaggi. Sicuramente, dal
punto di vista della sopravvivenza della azienda una scelta di
cambiamento puo' risultare molto delicata. Lakos e' arrivato a scrivere
un libro grazie all'esperienza che la sua azienda si e' fatta nel
portare i propri progetti verso il paradigma OO. Cio' a dimostrare che
quanto affermi e' innegabile. Innegabile e' anche il fatto che superati
i problemi iniziali, avendone le risorse adeguate, i risultati futuri
sono sicuramente paganti in tutti i termini.
massimo

>  Il C++ e` gia` in partenza un idea nata male.
m> Dato il successo che riscuote, vorrei averne di idee nate male come
m> questa.
Lo Hennessy -  Patterson (ma a proposito dell'HW)  dice chiaro e tondo
che non  e` vero  che una cattiva  architettura non avra`  successo, e
cita ix86 e IBM360... 
m> Nessuno ha il coraggio di definire OO le MFC (sono semplicemente un
Proprio nessuno no. Diciamo nessuno che desideri non fare una figuraccia.
m> Il C mi piaceva molto, ma il C++ e le metodologie OO
m> sono piu' intuitivi sia per chi progetta un programma che per chi
m> dopo debba mantenerlo.  Anche i tool di progettazione OO (es. Rose
m> della Rational) permettono di gestire il ciclo di progettazione con
m> maggior criterio e forniscono in automatico la documentazione
m> relativa al progetto. In C non ho mai avuto la fortuna di lavorare
m> con tool di questo tipo.
Questo e` un discorso sensato  che dice perche` in certe situazioni il
C++ e` preferibile... 
Io scindo cio` che mi piace da cio` che conviene usare...


 writes:
AM> Spiega dunque un poco a noi bovini, dall'alto della tua infinita
AM> saggezza, cosa ti fa pensare che B. Stroustrup "non abbia ancora
AM> capito come funzionano i puntatori del C"
secondo te, come legge il compilatore 
	char* a;
/* la cosa non me la sono inventata io ma e` decisamente vecchiotta.
   anche se con la tua prosopopea non la hai ancora trovata */


> piccolo possibile, cosa sceglieresti ?
m> Perche' deve essere il piu' piccolo possibile ? Forse parli di
m> applicazioni real-time ? Dopotutto, MS con la crescita continua dei
m> programmi e la richiesta di risorse sempre maggiori sta spianando
m> la strada a tutti noi facendo in modo che il PC base abbia comunque
m> un processore veloce,
Scusa,  ma qualcosa di  diverso dai  pc lo  hai mai  usato ?  Scusa la
domanda ma e` per inquadrarti meglio.
Comunque anche  coi PC c'e' gente  che sviluppa sw da  usare (i.e. con
Linux, Open/Free/Net BSD)  con un sistema nudo e  crudo che e` partito
con boot da floppy, niente shared libraries. E li` lo spazio e poco.
Portarsi dietro un runtime troppo grosso puo` essere un problema ancor
piu` grosso.
Per non  parlare di  quelli che cercano  di ridurre le  dimensioni per
avere piu` alta probabilita` di avere il codice in cache...


 writes:
AM> si tratta dell'oggetto che fa da "base" ad un
AM> altro (ereditá).
Questa e`  l'unica a  cui un programmatore  normale come me  non aveva
pensato.


> Sul piccolo e veloce ho molto da ridire.
MA> nel caso particolare di Windows ti consiglio di visitare
MA> 
http://www.relisoft.com
 
Controllero`, grazie (c'e' sempre roba che non si e` vista al nuovo).
Quanto  a Windows,  per una  dozzina d'anni  ho  potuto fortunatamente
vivere senza -  o.k. la pacchia sta` per finire -  e l'unica volta che
ho sviluppato sotto  quel sistema (anche se mi  sono divertito a conti
fatti) ho dovuto usare un compilatore cosi` malfatto... Insomma non ho
mai cercato maestri guardando verso MS :)
(I miei guru li proclamo io ;) ).


tendenza a considerare quel periodo come un'epoca oscura della mia vita
Qui mi sembra di sentire un EX-fumatore che parla degli orrori
del tabacco... sono tendenzialmente  peggio di chi non ha fumato
mai!-)  Comunque, tutto dipende da quali alternative uno ha... e
in molti casi, oggi, l'alternativa e', o MFC, o API Windows nude
(conosco, e rispetto, alcuni "API Wizards", che _amano_ le API
nude di Windows, le usano in preferenza a *qualsiasi* altra
alternativa, e sono incredibilmente produttivi nel farlo -- ma si
tratta senza dubbio di mutanti, o, forse, replicanti ben mascherati,
e personalmente, pur conoscendo le API stesse a menadito, io
seguo il principio "se le conosci le eviti -- se le conosci non ti
uccidono"... eccetto, al limite, quando programmo qualche piccolo
ActiveX con ATL, nel qual caso, almeno, ho il "sottile strato di
incapsulamento" che ATL offre su di esse).
Alex

sono sicuramente paganti in tutti i termini.
Amen!  Al di la' delle sfumature di espressione, che possiamo
scegliere differentemente, siamo "ferocemente d'accordo" su
queste opinioni di fondo.
Alex

Alex Martelli (
al...@magenta.com
) wrote:
[ snip ]
: >Infatti il C e' un linguaggio a basso livello ;). In quest'ottica, se tu
: >dovessi fare una piccola utility (100-200 righe), in modo che l'eseguibile
: >*linkato staticamente con la libreria* sia il piu' piccolo possibile,
: >cosa sceglieresti ?
: Sicuramente il C++, specificando l'attributo inline per tutte
: quelle funzioni che verranno chiamate in un punto solo -- se
: il programma é cosí piccolo come tu dici, quasi tutte le
: chiamate a funzione saranno di questo tipo, quindi, perché
: sprecare i parecchi byte di codice macchina necessari per
: la chiamata?  (Non sono solo le istruzioni macchina di CALL
: e RET -- c'é anche il passaggio di argomenti, eventualmente
: la manutenzione di stackframe).
Ti faccio notare che *qualsiasi* buon compilatore C con le ottimizzazioni
attivate fa la stessa cosa ;)
Io intendevo:
[bigfok@fokhouse bigfok]$ cat testcpp.cpp
#include <iostream>
void main(void)
{
        cout << "Ciao" << endl;
}
[bigfok@fokhouse bigfok]$ g++ testcpp.cpp -o testcpp -static
[bigfok@fokhouse bigfok]$ strip testcpp
[bigfok@fokhouse bigfok]$ ls -l testcpp
-rwxrwxr-x   1 bigfok   bigfok     204976 Sep 23 16:48 testcpp*
                                   ^^^^^^
[bigfok@fokhouse bigfok]$ cat testc.c
#include <stdio.h>
int main()
{
        printf("Ciao\n");
        return 0;
}
[bigfok@fokhouse bigfok]$ gcc testc.c -o testc -static
[bigfok@fokhouse bigfok]$ strip testc
[bigfok@fokhouse bigfok]$ ls -l testc
-rwxrwxr-x   1 bigfok   bigfok      97908 Sep 23 16:50 testc*
                                    ^^^^^
E' piu' chiaro adesso ?
[ snip ]
: Il C++ si presta, meglio del C, a questo tipo di "risparmio assoluto 
: e senza compromessi".  
: Ti faccio solo un esempio.  In C, *ogni* oggetto DEVE, per
: regola assoluta del linguaggio, occupare spazio -- almeno
: un byte (bit, per i bitfield); senza eccezioni.  In C++, per
: compatibilitá, vale la stessa regola per oggetti che svolgono
: ruoli analoghi a quelli C -- ma esiste in C++ anche un ruolo
: "nuovo", che non ha analogie dirette in C, e per il quale,
: quindi, il C++ ha potuto ammettere la "occupazione di
: zero byte" (se il compilatore é ben ottimizzante)... si tratta
: dell'oggetto che fa da "base" ad un altro (ereditá). 
Che in quanto tale, se ho ben capito, non verra' mai utilizzato
direttamente, ma solo per derivare gli altri oggetti, giusto ?
OK, carino, ma ti renderai conto che non e' sensato come paragone:
qualsiasi oggetto che viene utilizzato dal programma in modo
concreto occupa spazio, sia in C che in C++.
[ snip ]
: >: il tutto col compilatore piu` diffuso sul mercato con lo switch apposito,
: >: risulto' codice di circa UN DECIMO di X.
: >
: >Curiosita': nel calcolo hai contato anche le librerie ?
: Sí, sia per C sia per C++ -- si tratta in sostanza delle stesse librerie
: runtime (il programma doveva cercare file all'interno di directory, una
: funzionalitá non offerta dalle librerie standard ISO né in C né in C++,
: e quindi in entrambi i casi implementata con chiamate dirette al
: sistema operativo, cioé la Win32 API in questo caso specifico).
Cioe' non usavano *assolutamente* le librerie standard, ma solo le
chiamate alle Win32 ? O avevano comunque bisogno delle libc e libg++, o 
loro equivalenti ?
: >: In codice C++ ben scritto, la chiamata ad un metodo
: >: virtuale prende il posto di quello che in C sarebbe una chiamata
: >: indiretta attraverso un puntatore -- senza overhead ne` nulla di
: >: "pesante" --
: >
: >Ahem, l'overhead, rispetto ad una normale chiamata di funzione, e' dato
: >*proprio* dall'indirezione ;)
: Se l'indirezione "non serve", cioé se la situazione é tale che
: si puó determinare a tempo di compilazione esattamente cosa
: vada chiamato (e magari, se del caso, espanderlo in linea), e
: se l'overhead dell'indirettezza é rilevante nel caso specifico
: (presumibilmente una funzione molto "leggera" -- se la funzione
: esegue per un milione di cicli-macchina, un paio di cicli macchina
: in piú all'ingresso sono irrilevanti), allora un "codice C++ ben
: scritto", in collaborazione con un compilatore semi-decente, puó
: sempre evitare questo overhead (e in effetti, grazie all'inline,
: spesso evitare addirittura TUTTO l'overhead della chiamata --
: se sono rilevanti il paio di cicli in piú che possono essere dati
: dall'indirettezza, a maggior ragione lo saranno la decina o la
: ventina di cicli consumati da preparazione di stack/argomenti,
: chiamata, ritorno!).
Hmmm...stai dicendo che talvolta se il compilatore e il programmatore 
sono decenti si riesce ad eliminarlo, ma resta il fatto che in generale 
l'overhead *c'e'*.
[ snip ]
: Il C++ si distingue fra tutti i linguaggi ad oggetti proprio per
: la sua _maniacale_ attenzione alle prestazioni, specificamente
: alla possibilitá per un programmatore altrettanto monomaniaco,
: e di grandissima abilitá, di spremere ogni byte, o ogni ciclo di
: macchina, dal suo codice
Meglio di un adeguato mix assembly-C ?


massimo (
tecn...@interbusiness.it
) wrote:
: Andrea Foco wrote:
: > Infatti il C e' un linguaggio a basso livello ;). In quest'ottica, se tu
: > dovessi fare una piccola utility (100-200 righe), in modo che l'eseguibile
: > *linkato staticamente con la libreria* sia il piu' piccolo possibile,
: > cosa sceglieresti ?
: Perche' deve essere il piu' piccolo possibile ? Forse parli di
: applicazioni real-time ? Dopotutto, MS con la crescita continua dei
: programmi e la richiesta di risorse sempre maggiori sta spianando la
: strada a tutti noi facendo in modo che il PC base abbia comunque un
: processore veloce, molta ram e ancor piu' HD. Quindi la mia sensazione
: e' che, a parte settori particolari, la generalita' delle applicazioni
: non richieda eseguibili che siano il piu' piccolo possibile'.
Ahem...scusa ma che c'entra ? Dai l'impressione di non voler ammettere che 
esistono casi in cui si puo' tranquillamente preferire il C.


una "virata" trasformandola in un "vero framework".  Sigh.
Non era la 2.0, ma la seconda versione. Come avevo scritto su Dev qualche
mese fa narrando la storia di MFC, la prima versione fu cestinata da
Microsoft stessa. La seconda (di nuovo 1.0!) era uno thin wrapper, e la
terza (in verita' 2.0) era quasi come oggi, a parte i common controls e
ODBC/OLE -- dettagli a parte :)
Davide Marcato.
----------------------------------------------------
| -- Freelance International Consultant
| -- Win32/MFC/COM Development & Training
| -- Technical Writer & Speaker
----------------------------------------------------
| -- Email: 
mar...@programmers.net
| -- Web: 
http://www.DavideMarcato.com
----------------------------------------------------

 uccidono"...
Ripeto, io utilizzo le MFC quotidianamente, ma resto insoddisfatto. Non
vedo alternative a breve termine quindi va bene cosi. Pero' se qualcuno
alla Ms, quando e' stato deciso lo sviluppo della prima versione delle
MFC avesse approfondito maggiormente la progettazione/programmazione OO
seguendone i principi guida forse ora noi avremmo un fw un tantinino
piu' accattivante.
massimo

 Io scindo cio` che mi piace da cio` che conviene usare...
Anch'io. Se ti rileggi la frase dice che il C mi piaceva molto, ma per
convenienza e praticita' sono passato al C++ (e quindi alla OOA/D/P...)
Noto che sei all'UniPD. Dato che vengo anch'io dalla UniPD e ho un certo
feeling con quell'ambiente posso capire il tuo rifiuto del C++ e quindi
delle metodologie OO. A suo tempo (dottorato di ricerca) ho avuto varie
esperienze con persone per le quali descrivere come 'oscuro' il codice C
che producevano era come fargli un complimento. Penso che sia l'aria che
si respira nei corridoi ;-)
massimo

 [bigfok@fokhouse bigfok]$ g++ testcpp.cpp -o testcpp -static
Dipende anche dalle opzioni di compilazione e dal compilatore che usi.
Nell'esempio che hai fatto, puoi compilare con
g++ -fno-rtti testcpp.cpp -o testcpp -static
strip testcpp
ed escludi il supporto RTTI, che infatti nel tuo sorgente non usi.
In questo modo le dimensioni dell'eseguibile sono paragonabili a quelle del C.
Se usi EGCS puoi escludere anche il supporto alle eccezioni, se non ti serve e
riduci ulteriormente il codice.
Ciao.
-- 
   Andrea
   mailto:
a.sor...@mclink.it

 writes:
AF> Ti faccio notare che *qualsiasi* buon compilatore C con le
AF> ottimizzazioni attivate fa la stessa cosa ;)
Yep, concordo. Ho rifatto le prove e rispolverato una vecchia idea...
foocpp e fooc sono i tuoi programmi...
barc e` il risultato della compilazione di bar.c :)
main()
{
        write(2,"Ciao\n",5);
        return 0;
}
e barc1 e` barc con main di tipo void...
-rw-r--r--   1 saint    sysadmin      44 Sep 24 10:20 bar.c
-rwxr-xr-x   1 saint    sysadmin   44480 Sep 24 10:20 barc
-rwxr-xr-x   1 saint    sysadmin   44464 Sep 24 10:20 barc1
-rw-r--r--   1 saint    sysadmin      79 Sep 24 10:14 foo.c
-rw-r--r--   1 saint    sysadmin      73 Sep 24 10:12 foo.cpp
-rwxr-xr-x   1 saint    sysadmin  141764 Sep 24 10:14 fooc
-rwxr-xr-x   1 saint    sysadmin  200412 Sep 24 10:13 foocpp
Ovvero meno runtime richiedi...
AF> Meglio di un adeguato mix assembly-C ?
Magari per le dimensioni no. Per la velocita` invece...
Al MIT  hanno, ad  esempio, tirato fuori  una libreria per  il calcolo
della   FFT   (fftw,   Matteo   'Athena'  Frigo   e   Steve   Johnson,
http://theory.lcs.mit.edu/~fftw
) che  ha battuto molte  altre librerie
native,  e  non contiene  una  singola riga  di  assembler  (solo C  e
bytecode MH[?]).  La  libreria in pratica non fa  altro che trovare la
migliore sequenza  di "codelet" C per  la soluzione di una  FFT di una
certa  taglia. Questo perche`  con la  complessita` delle  CPU odierne
diventa arduo  (forse solo per il  peso della cosa)  creare il "codice
piu` veloce".
In precedenza Frigo aveva fatto  generare a Perl una serie di sorgenti
C  per  lo srotolamento  del  loop  interno  della moltiplicazione  di
matrici ed  aveva ottenuto un  sorgente C che,  dato in pasto  al gcc,
aveva prestazioni di poco inferiori  (6.4 contro 7 MFLOP[?])  a quelle
di un programma in assembler puro.
Senza  contare  che,  almeno  su  Sparc,  puoi  prevedere  "abbastanza
facilmente"   le  istruzioni  macchina   che  verranno   generate  dal
compilatore  per una  certa riga  di codice.  Su Intel  i386  la cosa,
almeno per me che non li ho programmati molto, e` gia` piu` ostica.


 esistono casi in cui si puo' tranquillamente preferire il C.
ahem...:-), solo l'impressione ? Ne sono convinto.
Si puo' tranquillamente preferire il C al C++, nessun problema, ma la
ragione e' legata alla presenza di 'legacy code', di esperienza dei
programmatori a disposizione etc.. e non a motivazioni legate a
prestazioni, codice "il piu' piccolo possibile (sempre che non sia
real-time, ovviamente) o che altro.
massimo

>  Io scindo cio` che mi piace da cio` che conviene usare...
m> Anch'io. Se ti rileggi la frase dice che il C mi piaceva molto, ma
m> per convenienza e praticita' sono passato al C++ (e quindi alla
m> OOA/D/P...)
Su questo concordiamo :)
m> Noto che sei all'UniPD. Dato che vengo anch'io dalla UniPD e ho un
m> certo feeling con quell'ambiente posso capire il tuo rifiuto del
m> C++ e quindi delle metodologie OO. A suo tempo (dottorato di
m> ricerca) ho avuto varie esperienze con persone per le quali
m> descrivere come 'oscuro' il codice C che producevano era come
m> fargli un complimento. Penso che sia l'aria che si respira nei
m> corridoi ;-)
Vediamo un  po' con le  iniziali... R.T. ?  M.F. ? (risposte  a questa
domanda al limite per e-mail)
No, non  ho un  rifiuto delle tecnologie  OO, sopratutto se  usate con
intelligenza  e  senza  fanatismo.   Possono  semplificarti  la  vita,
aiutarti a coordinare il lavoro... 
Poi che alcuni  compilatori C++ siano migliori di  altri e ottimizzino
meglio di altri, no doubt.
Che da qualche parte i compilatori C/C++ siano dei compilatori C++ che
compilano anche il C e da  qualche altra parte il C++ sia fatto ancora
come add on sul C e quindi  sia piu` lento, o che sia tanto piu` lento
il runtime  non ci piove nemmeno su  questo. Bisognerebbe confrontarne
l'output con un compilatore C puro.
Quello che  trovo risibile e` che  qualcuno dica che  un qualcosa nato
come compilatore+preprocessore (C++ e` nato  cosi`, i primi C++ che ho
visto avevano bisogno di  un compilatore C separato) e` "infinitamente
superiore" al  compilatore con tono  di chi possiede  verita` assolute
(che non esistono, sopratutto in informatica). Una frase del genere fa
pensare  ad un  furto nell'esame  base di  informatica teorica  :) :),
anche se con  ogni probabilita` e` solo una  frase malformulata -causa
presunzione  ??- che  esprime il  fatto che  per gli  usi e  scopi del
formulante il C++ e` di gran lunga piu` adatto...
Personalmente trovo il C++ una brutta idea. Utile ma brutta. Un kluge,
un  ibrido. 
Ad esempio puoi  fare la tua bella classe con  i tuoi elementi privati
per i controlli, distribuire header  e oggetto, ma nessuno impedisce a
qualcuno di rendere pubblico il  privato e di aggirare i controlli. Se
non  fosse  che  sono  utili  per  farsi  aiutare  dal  compilatore  a
controllare il codice, sarebbero inutili.
Quanto a Sturmtruppen  che non sa come funzionano  i puntatori (questa
frase ripeto non e` mia e ci ho messo un po` a capirla...), dipende da
questo:
	Stroustrup scrive sempre "type* object" sottintendendo
	che c'e' un tipo "puntatore a type".  Falso. Esiste il
	tipo type e gli oggetti  "type" e "puntatore a type" e
	Bjorne  gioca  sul  fatto  che  in C  puoi  anche  non
	metterli   gli  spazi   nella   dichiarazione  di   un
	puntatore...
Ci sono arrivato la volta che nella fretta ho scritto un char* a,b;...
(A me la grafia "type* object"  non era mai piaciuta... Presa la palla
al balzo).


> [bigfok@fokhouse bigfok]$ g++ testcpp.cpp -o testcpp -static
AS> Dipende anche dalle opzioni di compilazione e dal compilatore che
AS> usi.  Nell'esempio che hai fatto, puoi compilare con
AS> g++ -fno-rtti testcpp.cpp -o testcpp -static 
AS> strip testcpp
Mi spiace deluderti,  ma con egcs-2.91.57 su Solaris  2.6 non ho alcun
miglioramento. Con lo stesso compilatore  su Solaris 2.5.1 ho un lieve
(4 byte) peggioramento


 ...e di aggirare i controlli. Se non  fosse  che  sono  utili  per  farsi  


,
: 	
big...@fokhouse.tin.it
 (Andrea Foco) writes:
: > [bigfok@fokhouse bigfok]$ g++ testcpp.cpp -o testcpp -static
: Dipende anche dalle opzioni di compilazione e dal compilatore che usi.
Ovvio...ma in linea di principio le librerie del C++ sono piu' pesanti.
: Nell'esempio che hai fatto, puoi compilare con
: g++ -fno-rtti testcpp.cpp -o testcpp -static
: strip testcpp
: ed escludi il supporto RTTI, che infatti nel tuo sorgente non usi.
: In questo modo le dimensioni dell'eseguibile sono paragonabili a quelle del C.
Non direi proprio !
Ma hai fatto delle prove, prima di scrivere ?
[bigfok@fokhouse bigfok]$ g++ testcpp.cpp -o testcpp -fno-rtti -fno-exceptions -static
[bigfok@fokhouse bigfok]$ strip testcpp
[bigfok@fokhouse bigfok]$ ls -l testcpp
-rwxrwxr-x   1 bigfok   bigfok     204912 Sep 24 14:59 testcpp*
                                   ^^^^^^
Per tua norma e regola, io queste le avevo testate *prima* di scrivere il
mio precedente messaggio. Mi sono reso conto che la differenza era irrisoria e
non le ho messe per non scrivere troppe cose...forse sbagliando.
 
: Se usi EGCS puoi escludere anche il supporto alle eccezioni, se non ti serve e
: riduci ulteriormente il codice.
Capperi! Una manciata di byte in meno...;)


> impedisce a qualcuno di rendere pubblico il privato...
m> ???
Banalmente ci ho provato e il riuscirci non mi ha fatto piacere.
Ho fatto  una banalissima classe  con funzioni per leggere  e scrivere
una variabile privata.  Compilato l'oggetto dell'implementazione della
classe. Preso lo header che  la definisce e trasformata in pubblica la
variabile privata. Usato per creare un programma che alloca un'istanza
di tale  classe e che  accede direttamente alla variabile  che avrebbe
dovuto essere  privata.  Tutto perfettamente  funzionante.  Almeno con
g++.  Ora visto che  non posso  distribuire un  header senza  i membri
privati (almeno con g++), la cosa  non serve molto almeno dal punto di
vista dello hiding...


 Ma hai fatto delle prove, prima di scrivere ?
Certamente. Sotto FreeBSD 2.2.7, egcs 2.91.50 (snapshot del 15/07/1998),
sorgente che hai dato tu:
~/src $ g++ -static -o testcpp testcpp.cc
~/src $ strip testcpp
~/src $ ls -l testcpp
-rwxr-xr-x   1 mc4469  users  69632 Sep 24 21:59 testcpp*
/src $ g++ -static -fno-rtti -fno-exceptions -o testcpp testcpp.cc
~/src $ strip testcpp
~/src $ ls -l testcpp
-rwxr-xr-x   1 mc4469  users  36864 Sep 24 22:08 testcpp*
Saluti.
-- 
   Andrea
   mailto:
a.sor...@mclink.it

>Meglio di un adeguato mix assembly-C ?
Oh, l'assembler, se ti serve (generalmente, a fronte
di inadeguatezze dell'ottimizzatore del tuo compilatore),
puoi sempre scriverlo -- auguri sulla stima delle sue
esatte prestazioni, naturalmente (vedi sopra).  Sempre
che non ti curi della portabilita`, altrettanto naturalmente.
In C, e` possibile scrivere codice sorgente che, pur
rimanendo portatile, avra` ottime prestazioni a fronte
di compilatori semi-decenti; in C++ Standard, ci sono 
ancora _piu`_ possibilita` di scrivere codice sorgente
portatile, e ottimizzato altrettanto _o meglio_.  Sono
proprio le prestazioni (velocita` e dimensioni) che si
possono ottenere da codice ancora portatile, la forza
di questi due linguaggi, rispetto a ogni altro; e, su
questo punto di forza, il C++ e` *piu`* forte -- come
_linguaggio_, intendo, a parte cioe` le possibili carenze
di un dato compilatore, o una data libreria.  Se le
prestazioni importassero poco o punto, come in
effetti poco importano per un numero crescente di
applicazioni, altri linguaggi, piu` facili e di alto livello,
sarebbero secondo me da preferire (salvo, magari,
tenersi da una parte il compilatore C, o _meglio_ C++,
per scrivere quelle poche parti di codice per cui le
prestazioni contano -- un po' come scriverle in
assembler, ma senza perdere la portabilita`). Come
pura "produttivita` del programmatore", in particolare,
e nonostante alcune sue carenze fondamentali, il
Java secondo me e` superiore anche al C++ (la mia
esperienza di Java e' limitata, rispetto a quella di C++,
eppure per una data funzionalita` sono gia` _piu`_
produttivo in Java, nella maggior parte dei casi... se
solo ci mettessero i template, o altre forme decenti di
"generic programming", che "marcia in piu`" avrebbe!).
Ma (ancora, al netto dei difetti degli attuali compilatori
Java) vi sono caratteristiche del linguaggio che non gli
permetteranno mai di ottenere codice altrettanto
ottimale (su CPU general-purpose, naturalmente) di
quel che puo` fare il C++ (gli oggetti "devono" vivere in
memoria dinamica, e "devono" essere gestiti con la
garbage collection -- in C++, posso avere oggetti in
stack, ed evitare l'overhead, piccolo o grande ma certo
non zero, della allocazione dinamica e della garbage
collection).
Il C++ non ha *nessuna* caratteristica che imponga
simili limiti alle ottimizzazioni -- il prezzo per questo si
paga "solo" in termini di difficolta` ad impararlo al meglio, 
e ad usarlo alla perfezione.  Non e' necessariamente un
prezzo da poco (appunto consiglio a chiunque me lo
chieda di imparare e usare Java, non C++...!); ma non
e' nel tornare indietro al C, che la difficolta` di uso cala,
anzi -- la mancanza in C di certi costrutti (eredita`,
template, eccetera) aumenta la difficolta`, ancor piu`
di quanto non riduca le possibilita` di ottimizzazione.
Alex

 writes:
AS> ~/src $ g++ -static -o testcpp testcpp.cc ~/src $ strip testcpp
AS> ~/src $ ls -l testcpp
Interessante.  Ho appena riprovato  (Solaris 2.5.1  e 2.6)  ed ottengo
differenze di poche decine di byte (egcs-2.91.57).
Sotto SunOS  4.1.4 e g++ 2.7.2  non c'e' variazione alcuna  (ma non ho
potuto usare la -fno-exceptions).
Sotto Linux cala di qualche decina di byte.
Morale : 
	Non esiste una verita` assoluta.
	(e comincia ad attirarmi sempre piu` FreeBSD :)




 writes:
AM> Un compilatore semi-decente (il solito VC++)
Accidenti come sei gentile... semi decente ad un compilatore C+....
Forse parli  di una release  > 4, perche`  con quella mi  sono trovato
davanti ad  una carenza  simpaticissima nel supporto  del C++  come lo
descrive Stroustroup,  non compila gli  array di puntatori  a funzione
-not supported-, pero` potresti fargli compilare un array di strutture
con dentro  un puntatore a funzione...  Ma a questo punto  chi si fida
del funzionamento ?
Per il resto un bel post.  Decisamente meglio di una frase dogmatica e
lapidaria. A quelle reagisco in per natura in maniera iconoclastica.
AM> "sacrifici" di funzionalita` cosi` drastici
A me parrebbero piu` che altro "sacrifici" di tempo programmatore...
Cosa  che puo` non  essere cosi`  pesante quando  il tornaconto  e` la
soddisfazione  personale.   Quando i  metri  sono  altri (costo  della
produzione, del test...) indubbio che "il meglio e` nemico del bene".
AM> solo ci mettessero i template,
Non mi sembra  siano cosi` necessari... Se riprendiamo  il tuo esempio
di  quicksort, con  le interfaces  puoi risolvere  il problema  se non
erro. 
Definisci  un'interface  "sortable"  che  preveda un  metodo  "boolean
greather_than(sortable  b)" (scusami,  non mi  piacciono  gli StuRdly-
Caps...), la personalizzazione  nel tuo caso si fa  creando una classe
"Interi extend Integer  implements sortable" (perdona evantuali errori
di  sintassi, son  di fretta)  nella  quale c'e`  implementato il  tuo
metodo   "boolean  greather_than(sortable   right_hand)"   secondo  il
predicato
AM>    -- tutti i dispari sono "minori" di tutti i pari,
AM>    -- fra due dispari, o due pari, vale il normale
AM>         operatore di confronto < fra gli interi
che  si da` in  pasto ad  una sort  che accetta  ingresso un  array di
sortable (scusate lo OT da it.comp.lang.java).
Alla tua  sort puoi  dare in  pasto un array  di oggetti  di qualsiasi
classe implementi l'interface sortable.


...
:     [snip]
: >Ti faccio notare che *qualsiasi* buon compilatore C con le 
: >ottimizzazioni attivate fa la stessa cosa ;)
: Magari "qualsiasi buon compilatore C" fosse in grado di fare
: ottimizzazione interprocedurale -- in realta`, la maggior parte
: di essi compila separatamente ogni sorgente in un oggetto, e
: non riprende i sorgenti in considerazione a tempo di link (le
: ottimizzazioni interprocedurali, in effetti, potrebbero fare
: consumare un tempo enorme su programmi di dimensione
: sostanziale -- sara' per questo che sono poco implementate
: e non particolarmente richieste/usate dove presenti).
Si parlava di un piccolo programma (sorvolo sul fatto che
il compilatore C puo' avere la keyword inline).
[ snip ]
: Comunque -- prendiamo un caso tipico, e vediamo.
: Diciamo che si vuole sortare un array di interi, usando
: come predicato di confronto fra due interi:
:     -- tutti i dispari sono "minori" di tutti i pari,
:     -- fra due dispari, o due pari, vale il normale
:         operatore di confronto < fra gli interi
: Evitiamo, naturalmente, di "reinventare la ruota":
STOP ! Allora prendi un caso diverso: cosi' come lo hai
messo, e' ovvio che la cosa migliore e' scriversi la
funzione di sort...;)
[ snip ]
: In C++, l'approccio tipico e' quello di usare un
: _template_ di sort, e passargli un oggetto comparatore
: (con, ad esempio, un operator() che accetta due int
: e ritorna il risultato bool del loro confronto) -- si puo`
: specificamente richiedere l'inline, ed evitare i vari
: overhead suddetti (indirettezza della chiamata,
: indirettezza degli argomenti, la chiamata stessa).
Si ma io parlavo di un *piccolo* sorgente! Tutto cio' che
hai scritto e' senz'altro corretto, ma perde molto del suo
valore se visto in un contesto in cui la piccola dimensione
del codice non rende assurda l'idea di scrivere funzioni
'ad hoc'.
[ snip ]
: Era chiarissimo anche prima: l'implementazione gcc degli
: iostream _non_ e' ottimizzata per la dimensione (neppure
: quella di stdio e' decente, certo).  Un compilatore semi-decente
: (il solito VC++), su questi stessi sorgenti, genera codice di
: oltre tre volte piu' piccolo -- ed e' tanto lontano dal minimo
: interesse per la riduzione della dimensione di iostream, che
: li implementa _appoggiandosi su stdio_... tanto per garantire
: il massimo di "ingrasso", immagino; come faccia gcc ad
: essere 3-4 volte peggio di cosi', e' davvero una sfida
: all'immaginazione.
OK ma quello che stai dicendo e' che anche sotto VC++ permane
lo scarto in favore del C, in questo caso, giusto ?
[ snip ]
: Quel che e' davvero ridicolo e' che tu, ed altri, possiate
: pretendere di "sparare sentenze" sulle caratteristiche
: del linguaggio C++, basandovi in tutto e per tutto su di
: un certo compilatore (e libreria) che, come dovrebbe
: essere clamorosamente chiaro, di tutto puo` curarsi
: eccetto che di ridurre la dimensione del codice che
: genera (visto che anche le cifre che da' per il C sono
: risibili da questo punto di vista).
Scusa, io cerco di parlare di quel che so ed uso, non tutti hanno
la tua quasi ventennale esperienza. 
La mia, ben piu' limitata, mi dice che le librerie C++ sono generalmente
piu' pesanti, quando vedro' qualcosa di diverso non avro' problemi ad
ammetterlo...
[ snip ]
: In pratica, chi si preoccupa veramente dei requisiti di
: memoria (a parte quelli che, non avendo capito nulla in
: materia, vogliono egualmente a tutti i costi polemizzare
: contro il C++:-), sono gli autori di codice "embedded",
Appunto: l'esistenza dell'Embedded C++ conferma che il
C++, di suo, e' *grossetto* :-)
[ snip ]
: Quante volte hai trovato necessario, nella tua esperienza
: C che immagino enorme visto la sicumera con cui parli,
Quale sicumera ?
: evitare la qsort o bsearch di sistema per ottenere prestazioni 
: molto migliori usando invece un tuo sort, o ricerca binaria, 
: in-linea?  Ecco, questa puo` essere una buona indicazione 
: della frazione di volte in cui troverai necessario operare 
: ottimizzazioni di varia natura per eliminare chiamate virtuali.
Di nuovo: io sto parlando di una *piccola* utility con esigenze
di riduzione di spazio. Tu mi stai dicendo che in generale il
C++ mi offre tutta una serie di strumenti ecc...OK, va bene,
ma che cosa c'entra ?
[ snip ]
: In C, e` possibile scrivere codice sorgente che, pur
: rimanendo portatile, avra` ottime prestazioni a fronte
: di compilatori semi-decenti; in C++ Standard, ci sono 
: ancora _piu`_ possibilita` di scrivere codice sorgente
: portatile, e ottimizzato altrettanto _o meglio_.  Sono
: proprio le prestazioni (velocita` e dimensioni) che si
: possono ottenere da codice ancora portatile, la forza
: di questi due linguaggi, rispetto a ogni altro; e, su
: questo punto di forza, il C++ e` *piu`* forte -- come
: _linguaggio_, intendo, a parte cioe` le possibili carenze
: di un dato compilatore, o una data libreria. 
Ci mancherebbe che il C++, come _linguaggio_, fosse 
inferiore al C !
Inoltre le possibili carenze di compilatori/librerie limitano
le possibilita' *effettive* di ottimizzazione.
: Il C++ non ha *nessuna* caratteristica che imponga
: simili limiti alle ottimizzazioni -- il prezzo per questo si
: paga "solo" in termini di difficolta` ad impararlo al meglio, 
: e ad usarlo alla perfezione.  Non e' necessariamente un
: prezzo da poco (appunto consiglio a chiunque me lo
: chieda di imparare e usare Java, non C++...!); ma non
: e' nel tornare indietro al C, che la difficolta` di uso cala,
Cosa intendi con difficolta' di uso ?
: anzi -- la mancanza in C di certi costrutti (eredita`,
: template, eccetera) aumenta la difficolta`, ancor piu`
: di quanto non riduca le possibilita` di ottimizzazione.
Scusa, qual'e' la difficolta' che aumenta ? di uso ? 
di ottimizzazione ?


,
: 	
big...@fokhouse.tin.it
 (Andrea Foco) writes:
: > Non direi proprio !
: > 
: > Ma hai fatto delle prove, prima di scrivere ?
: Certamente. Sotto FreeBSD 2.2.7, egcs 2.91.50 (snapshot del 15/07/1998),
: sorgente che hai dato tu:
: ~/src $ g++ -static -o testcpp testcpp.cc
: ~/src $ strip testcpp
: ~/src $ ls -l testcpp
: -rwxr-xr-x   1 mc4469  users  69632 Sep 24 21:59 testcpp*
: /src $ g++ -static -fno-rtti -fno-exceptions -o testcpp testcpp.cc
: ~/src $ strip testcpp
: ~/src $ ls -l testcpp
: -rwxr-xr-x   1 mc4469  users  36864 Sep 24 22:08 testcpp*
Interessante! Come avrai visto i miei risultati sono ben diversi...
per curiosita' quali sono i risultati per il codice C sulla tua macchina ?
Su un'altra macchina, che usa una Slack 3.4 (quindi la libc5 e il 
gcc 2.7.2.3), ho ottenuto:
apollo:~$ g++ testcpp.cpp -o testcpp -fno-rtti -static
apollo:~$ strip testcpp
apollo:~$ ls -l testcpp
-rwxr-xr-x   1 fok      users      186484 Sep 25 18:53 testcpp*
Meglio, ma siamo ancora lontani...mah 8-?


 	(e comincia ad attirarmi sempre piu` FreeBSD :)
Io sono un ex-linux user, preferisco FreeBSD perchč...mi fa letteralmente
volare la macchina, anche rispetto a Linux, non solo nel networking (che non
sfrutto a fondo, ho solo un accesso dial-up), ma anche nell'uso normale di
tutti i giorni.
Ti riporto qualche benchmarch, fatti sul pc di casa:
Macchina: P180, 64 mega di ram, 2 dischi IDE uguali, FreeBSD 2.2.7 e RedHat
Linux 5.1 con kernel 2.0.34, quello di serie, configurati entrambi con il
kernel contenente solo i driver necessari al mio hardware, filesystem montati
asincroni, stessa versione di XFree86...insomma, messi ad armi pari.
Compilazione del kernel: Linux 8 minuti e mezzo, FreeBSD 5 minuti 40 sec.
Compilazione Scilab 2.4 (con f2c e stesse opzioni di compilazione, gcc -O3
-fomit-frame-pointer -ffast-math): Linux 2 ore e 47 minuti, FreeBSD 1 ora e 50
minuti.
Da quello che leggo qui sul newsgroup sembra che i kernel 2.2 per linux,
prossimi venturi, riducano il divario di prestazioni (specie nel networking,
di cui pero` non ho esperienza), pero` sulla mailing-list di FreeBSD hanno
annunciato FreeBSD 3.0 per fine ottobre, e quindi il confronto rimane aperto.
Appena saranno disponibili vado a fare acquisti e riprovo. :-))


massimo (
tecn...@interbusiness.it
) wrote:
: Andrea Foco wrote:
: > 
: > massimo wrote:
: > : Perche' deve essere il piu' piccolo possibile ? Forse parli di
: > : applicazioni real-time ? ...
: > 
: > Ahem...scusa ma che c'entra ? Dai l'impressione di non voler ammettere che
: > esistono casi in cui si puo' tranquillamente preferire il C.
: ahem...:-), solo l'impressione ? Ne sono convinto.
Ma va... ;)
: Si puo' tranquillamente preferire il C al C++, nessun problema, ma la
: ragione e' legata alla presenza di 'legacy code', di esperienza dei
: programmatori a disposizione etc.. e non a motivazioni legate a
: prestazioni, codice "il piu' piccolo possibile (sempre che non sia
: real-time, ovviamente) o che altro.
Perche' no ?


 Non esiste una verita` assoluta.
Morale: valutare le capacita' di un linguaggio sulla base del
semplice esame di cosa si ottiene da _1_ compilatore ed _1_
libreria per quel linguaggio e' un'emerita sciocchezza, e chi lo
fa dimostra di non capire davvero molto di informatica (consolati:
negli ultimi anni, con Java, si sono rivelati cosi` incapaci in tanti;
non si possa dire tu abbia _buona_ compagnia, ma, almeno, ne
hai _tanta_, e, si sa, mal comune, mezzo gaudio).
Considerazione meno evidente ma non meno valida: neppure
esaminando l'insieme di _tutti_ i compilatori per un linguaggio
che esistono in un dato istante, si ottiene un quadro totalmente
veritiero delle possibilita' del _linguaggio_ in quanto tale.  {Se in
un linguaggio vi siano o meno, ad esempio, delle caratteristiche 
che impongono inevitabilmente certi overhead, si puo` capire
solo analizzando veramente a fondo la definizione del linguaggio,
sulla base di un'ottima comprensione della tecnologia odierna
di compilatori, linker, sistemi runtime, eccetera  [anche cosi`,
naturalmente, sono possibili "salti tecnologici", invenzioni nuove
che cambiano i parametri in gioco (a meno che le caratteristiche
prestazionali di certi meccanismi non siano state dimostrate in
matematicamente in modo rigoroso) -- nondimeno, secondo me 
e' ragionevole discutere sulla base delle conoscenze tecniche di 
oggi.}  Si puo` ad esempio dimostrare che una certa possibile
ottimizzazione richiede nel caso generale, per essere mostrata
semanticamente corretta, la soluzione dell'"halting problem" --
quando si fa questo, allora si` che si evidenzia un limite che e`
intrinseco al linguaggio... quella ottimizzazione e` infattibile sul
piano teorico.  O, si puo` dimostrare che l'algoritmo che mostra
corretta una data ottimizzazione e` NP-hard -- anche questo e`
un valido modo di evidenziare limiti intrinseci al linguaggio per
quel che riguarda le possibilita` di ottimizzazione.
Il C++, per tutto il lungo corso della sua standardizzazione, e`
stato scrutato e iper-scrutato da questi punti di vista, da parte
di persone e organizzazioni di grande competenza e grande
esperienza, e molto motivate a farne un linguaggio che avesse
il massimo potenziale di ottimizzazione.  Gli unici limiti alla
ottimizzazione sono quelli legati alla compatibilita` con il C:
come e` noto, il problema dell'aliasing e` NP-hard nel senso
di cui sopra, ma, per compatibilita` con il C, non e` stato
rimosso (basterebbe, naturalmente, che il programmatore
avesse modo di _asserire_ la mancanza di certi aliasing --
come, intrinsecamente, fa in Fortran, ogni volta che chiama
un sottoprogramma in certi modi; ma negli Standard C, e
C++, questo concetto pare non voglia proprio entrarci).
E quindi, ribadisco, con particolare gioia perche` so che (a)
e' vero e (b) ti irrita sentirlo dire: avendo a disposizione un
compilatore appropriato, e che sia decente, o anche semi
decente, per ciascuno dei due linguaggi, C e C++, non vi e`
_nessuna_ ragione tecnica per cui una persona sensata, che 
li conosca bene entrambi, possa mai scegliere il C.
Alex

 processore veloce, molta ram e ancor piu' HD. Quindi la mia sensazione
ho impiegato una settimana per convertire un database che girava su CPU
z80, 64K RAM e sistema operativo CP/M. Ora tutti i dati (circa 10-20000 record)
sono gestiti da un programma WIN con interfaccia in VB e il motore di access 2.0
visto che il computer che gestisce il database e` un Pentium (non so i
dettaggli della cfg) mi aspettavo un incremento significativo delle
prestazioni rispetto a quelle del povero z80.
beh, quando ho visto il tutto girare, gi cono rimasto *di m%rda* : le
prestazioni erano paragonabili a quelle dello z80 !!
non credevo che i programmi ms potessero fare tanto.
-- 
Ranger, togli .fr dal mio indirizzo per rispondere
http://ranger-rg.home.ml.org/

oggettivamente piu' valida.
Bah, programmare e' una sorta di arte. Per taluni abbandonare il
fortran sarebbe terribile...
Non mi piace il C++ perche' porta con se' delle incongruenze ( con
l'ereditarieta' virtuale non si capisce bene chi chiama i costruttori
delle classi "ascendenti" ). Forse e' per questo che Jobs peso per il
suo Next al objective-c piuttosto che al c++.
Inoltre non ho un buon controllo di come viene gestita la memoria.
Forse e' piu' una questione psicologica, ma mi turba non sapere bene
dove "punta" un puntatore ... e poi tutti quei tipi di cast ...
Voglio l'assembler :)))) !

 wrote:
E poi a me piacciono tanto i cast bruti del tipo
un_puntatore = (void*)( un-intero )
:)

Voglio l'assembler :)))) !
io no, ho programmato in assembly ma preferisco il C++ :-))
Gianpaolo Bottin
Free Hi Quality Computer Wallpapers
http://members.xoom.com/gpaolo

On Tue, 22 Sep 1998 14:44:51 +0200, massimo

ahhhhh, come soffro..... :) fare cose di questo genere e' come
spararsi nei piedi... valli poi a trovare i bachi. Se fai cose del
genere ci credo che preferisci il C.


 
Anche in VC++ stesso comportamento.
Devo riconoscere che sono perplesso. Anche se non penso sia un evento
che puo' capitare spesso (modificare gli header delle librerie in uso),
l'eventualita' da te descritta e' decisamente fastidiosa.
massimo

> Non esiste una verita` assoluta.
AMF> Morale: valutare le capacita' di un linguaggio sulla base del
AMF> semplice esame di cosa si ottiene da _1_ compilatore ed _1_
AMF> libreria per quel linguaggio e' un'emerita sciocchezza,
Ed io, non pare tu ci sia giunto da solo, non lo ho mai fatto.
AMF> e chi lo
AMF> fa dimostra di non capire davvero molto di informatica
AMF> (consolati: negli ultimi anni, con Java, si sono rivelati cosi`
AMF> incapaci in tanti; non si possa dire tu abbia _buona_ compagnia,
AMF> ma, almeno, ne hai _tanta_, e, si sa, mal comune, mezzo gaudio).
Ho molta  meno compagnia di quella che hai  visto dal tuo trono
d'oro.
AMF> Il C++, per tutto il lungo corso della sua standardizzazione, e`
AMF> come e` noto, il problema dell'aliasing e` NP-hard nel senso di
AMF> cui sopra, ma, per compatibilita` con il C, non e` stato rimosso
Perche` sotto c'e` il C. E` quella fondamentalmente la cosa sbagliata.
Le tue stesse  parole dimostrano che il C++  e` un linguaggio scazonte
perche` ha alcune palle al piede.
AMF> (basterebbe, naturalmente, che il programmatore avesse modo di
AMF> _asserire_ la mancanza di certi aliasing -- come,
Hmmm, intendi lo "assume no aliasing" del VC++ ?
AMF> E quindi, ribadisco, con particolare gioia perche` so che (a) e'
AMF> vero e (b) ti irrita sentirlo dire:
Ti ricordi  vero come avevo  commentato ? E  pensi che una  risata sia
segno di irritazione ? Scendi  dal trono o procurati un buon binocolo,
non mi vedi bene :)
In ogni caso ti dico che c'e' gente che ora e` al MIT a far teoria che
dissente  dalle tue  opinioni. E  sinceramente li  trovo  dei ''guru''
migliori di te. Nonostante il tuo background in big blue.
AMF> avendo a disposizione un
AMF> compilatore appropriato, e che sia decente, o anche semi decente,
AMF> per ciascuno dei due linguaggi, C e C++, non vi e` _nessuna_
AMF> ragione tecnica per cui una persona sensata, che li conosca bene
AMF> entrambi, possa mai scegliere il C.
Se lo hai,  no doubt. Sopratutto se preferisce il  C++. Ma devi essere
certo che il compilatore sia in grado di fare quelle ottimizzazioni.


 writes:
m> Anche in VC++ stesso comportamento.  Devo riconoscere che sono
m> perplesso. Anche se non penso sia un evento che puo' capitare
m> spesso (modificare gli header delle librerie in uso),
m> l'eventualita' da te descritta e' decisamente fastidiosa.
Infatti.  Se  lo scopo  dell'incapsulamento  e`  evitare che  qualcuno
"sapendo  quello  che fa"  faccia  arrivare  valori  imprevisti ad  un
segmento  di   codice,  portandolo  in   condizioni  di  comportamento
scorretto, beh, qui va a quel paese.
Una  soluzione  potrebbe  essere   prevedere  di  includere  anche  le
informazioni sul private/protected/public  nel mangling del nome degli
oggetti. Questo  impedirebbe di soddisfare  a link time i  simboli per
cui il programmatore "disonesto" ha modificato in public un private.


certo che il compilatore sia in grado di fare quelle ottimizzazioni.
Visto che non ho mai detto altro, se non che _come linguaggio_
il C++ e` *sempre* superiore al C -- ed e` questo che ha scatenato
tutta la tua reazione, e la flamewar che hai deciso di scagliare --
sarebbe certamente interessante, sopratuttto per qualche studioso
di psicologia anormale, approfondire l'analisi delle ragioni per le
quali hai ritenuto opportuno attaccarmi per questo.  D'altra parte,
possiamo gia` predirlo, sulla sola base della scuola di appartenenza
dello ipotetico psicologo in questione: se Freudiano, la causa sarebbe
certamente in un conflitto Edipico con la "figura del Padre"; se
seguace di Cesare Lombroso, dipenderebbe dalla conformazione
delle bozze sul cranio; se Junghiano, avrebbe a che vedere col
non essere in buoni rapporti con la propria Ombra; se Reichiano,
tutto verterebbe su aspetti insoddisfacenti della vita sessuale.
Ah, quasi scordavo -- un Marxista, naturalmente, non mancherebbe
di inquadrare il tutto il termini di lotta di classe... e un Ricardiano (se
ve ne fossero fra gli psicologi:-) evidenzierebbe invece il vantaggio
comparativo che alcuni hanno (od opinano di avere) in discussioni
di un certo tenore piuttosto che di un altro...
Alex

>  Hmmm, intendi lo "assume no aliasing" del VC++ ?
AM> Quello, secondo me, e` eccessivo, poiche` e` uno switch che si
[snip ... interessante]
AM> Visto che non ho mai detto altro, se non che _come linguaggio_ il
AM> C++ e` *sempre* superiore al C -- ed e` questo che ha scatenato
AM> tutta la tua reazione, e la flamewar che hai deciso di scagliare
AM> -- sarebbe certamente interessante, sopratuttto per qualche
AM> studioso di psicologia anormale, approfondire l'analisi delle
AM> ragioni per le quali hai ritenuto opportuno attaccarmi per questo.
Perche`  ti sei  espresso con  una frase  che era  risibile  nella sua
tronfieta`.  Invece  che  un  brute  force  sulle  scuole  di  analisi
dell'animo umano potevi partire dalla domanda "perche` cacchio mi ride
dietro ?" (trovare la risposta puo` essere non computabile, anyway...)
Tutte  le ragioni che  hai esposto  sono valide  per sostenere  la tua
tesi. No doubt. Ma  la tua tesi non e` assoluta. E`  un punto di vista
pragmatico  col  quale  si  debbono  fare  i  conti  nella  produzione
industriale di  SW. Ed in quel campo posso essere d'accordo.
Ma siccome per me fare software  non e` solo un mestiere (lo e` quando
me lo chiedono, e se me  lo chiedono programmo in VB, Fortran, Pascal,
C, C++ e anche altro perche` il  nuovo non mi fa certo paura) ma anche
divertimento,  esperienza  estetica,  beh,  allora un  linguaggio  che
(almeno nelle implementazioni che ho visto) si lascia fare "sgambetti"
come quello  dei membri che da privati  diventan pubblici l'esperienza
estetica te la manda a quel paese. Preferisco l'onesta` del K&R :) che
ti dice  "il programmatore sei tu, sei  tu che sai quello  che fai". E
li` gli standard me li faccio io :)


genere ci credo che preferisci il C.
Se c'e` necessita` di "fare cose del genere", ad esempio
scrivendo un sistema operativo, oppure scrivendo codice
per programmi che devono girare "sul ferro nudo", senza
un sistema operativo, non c'e` comunque nessuna ragione
di preferire il C, se e` disponibile un compilatore C++
almeno semi-decente per la configurazione desiderata.
    void* un_puntatore = reinterpret_cast<void*>(un_intero);
E` esattamente altrettanto efficiente dell'equivalente C,
e` molto piu` facile da trovare nel proprio codice sorgente
con un qualsiasi editor grazie al nome reinterpret_cast
che "salta all'occhio" -- e per la stessa ragione non e`
possibile che sfugga a chi esamina, ispeziona, o fa
manutenzione di questo sorgente.
Inoltre: se questo e` il primo punto in cui interessa la
variabile un_puntatore, essa viene dichiarata in quel
preciso punto, e contestualmente inizializzata -- inutile
correre rischi di variabili non inizializzate, mentre il
comune uso C:
    { /* inizio del blocco, qui vanno dichiarate le variabili */
    void* un_puntatore = 0;    /* inizializziamo, non si sa mai */
    /* parecchio codice che NON usa un_puntatore,
        ma calcola opportunamente un_intero */
    un_puntatore = (void*) un_intero;
    }
***spreca un ciclo di macchina*** o giu` di li` (per
mettere "inutilmente" a zero una locazione in stack,
possono volercene anche due o tre!), mentre la
versione equivalente in C++, dove il puntatore e`
dichiarato solo nell'istante in cui serve farne la
inizializzazione e l'uso, *e` piu` efficiente*, proprio
in termini di cicli di macchina e spazio di codice --
oltre a migliorare leggibilita` e manutenibilita` del
programma.
Anche per scrivere programmi di bassissimo livello, che
devono essere "il piu` vicini possibili al ferro" (o silicio
che sia), il C++, come linguaggio, e` sempre migliore
del C.  Ancora una volta, spicca la nullita` tecnica di
quelli che sbraitano che invece va preferito il C, magari
"solo per programmi piccoli" o "per la massima velocita`":
il C++, fra i vari vantaggi, ci permette di risparmiare una
istruzione macchina e un relativo ciclo macchina in
questo caso piuttosto comune.  Normalmente, non fa
nessuna differenza se il nostro programma prende un
qualche nanosecondo in piu` -- ma, se la fa, il C++ e`
il linguaggio da preferire; e, se non la fa, il C++ e` da
preferire lo stesso.  Testa, vince chi usa il C++, coda,
perde chi invece usa il C...:-).
Alex

io no, ho programmato in assembly ma preferisco il C++ :-))
L'assembler ha il suo posto (sempre piu` piccolo col passar
del tempo, certo) -- e` il C che, come linguaggio, ha avuto la
sua "nicchia ecologica" _totalmente_ coperta dal C++... e,
inerzia a parte, sopravvive solo per ragioni non tecniche di
qualita` dei compilatori, come quella che sopra dicevo.  Spero
anzi che il prossimo venturo standard C (speriamo prima
del 2000) cambi le cose, perche` C e C++ potrebbero cosi`
avere un altro "round" di benefica "concorrenza" ed emulazione
reciproca...!
Alex

estetica te la manda a quel paese. Preferisco l'onesta` del K&R :) che
Ancora una volta mostri la tua pochezza, per non dire
nullita`, tecnica, relativamente alla conoscenza del
linguaggio C++, e degli obiettivi che si pone: in C++,
il concetto di public/protected/private ha come scopo
quello di evitare _incidenti_, *non* di proteggere
checchessia da "deliberati attacchi".  Illustrero`
meglio questo punto in un altro post, ma, per
chiarire: e` come se tu dicessi che l'esistenza di
guardrail sull'autostrada ti disgusta, perche` se uno
va li` con un bel maglio o una fiamma ossidrica non
ci mette niente a tagliarli, e quindi preferisci una
bella autostrada coi lati spalancati verso il burrone.
In Java, public/protected/private _hanno_ il ruolo
di "tener fuori gli intrusi" -- e quindi sarebbe grave
trovare "falle" in questo sistema di protezione, perche`
ad esempio una applet aggressiva potrebbe trarne
vantaggio per danneggiare il sistema su cui gira.
In C++, invece, lo scopo e` quello del guardrail
sull'autostrada: salvare la vita a qualcuno che sbanda
e ci sbatte contro (che se poi quello che sbatte e`
un TIR ai 200 all'ora, vabbe`, non mi sorprende se
il guardrail non regge -- ma intanto ha salvato tanti
altri con mezzi o velocita` piu` "normali" dal peggio).
E` una tesi sostenibile (e discutibile) che Java sia
superiore a C++ per ragioni di sicurezza (puo`
forse esserlo dove e` importante potere girare
codice di cui non ci si fida minimamente, ma sono
queste poi situazioni cosi` importanti...?); non e`
chiaro invece quale "criterio estetico" (sempre a
livello _tecnico_, beninteso -- in pura estetica, tu
puoi anche dire che, visto che Stroustrup ha la
barba e tu esteticamente aborri le barbe, per
questo il C++ e` "brutto"...:-) possa renderti
preferibile cadere nel burrone, se dai una sbandata,
piuttosto che non urtare contro un guardrail che,
se pur non a prova di bombe nucleari, puo` pur
sempre salvarti la pelle (ometto qualsivoglia
considerazione sulla desiderabilita` di quest'ultimo
obiettivo, visto che qui il "tu" e` da leggersi come
"generico" e non va preso come personale:-).
Alex

perde chi invece usa il C...:-).
Ehm... ma non era testa o croce? ;-)
Mi stai convincendo (ammetto che non ci è voluto molto :) il problema
principale del C++ quando lo avevo preso in considerazione erano i
compilatori (Turbo C++ v3.0). Visto che ora c'è anche lo standard penso che
per i nuovi progetti lo prenderò in seria considerazione (sempre di trovare
un compilatore decente per il sistema). 
Un'altra cosa che mi aveva tenuto lontano dal C++ era il fatto che lo vedevo
solo sotto il paradigma O.O. e da quel punto di vista preferisco imparare un
linguaggio come l'Eiffel, non mi servirà ad un tubo per lavorare ma vuoi
mettere! ;°) Non avevo mai pensato al fatto che il C++ è multiparadigma (vado
a prendere la cenere :).
PIETRO
P.S. Dovendomi avvicinare al C++ partendo da una discreta conoscenza C,
quale può essere un buon testo? Il C++ Primer di Lippmann o la 3rd edition
del libro di B. Stroustrup ? 
-- 
Legal Warning: Anyone sending me unsolicited/commercial email WILL be charged
a $100 proof-reading fee.  Do NOT send junk email to me - consider this an 
official notice:
"By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meets the
 definition of a telephone fax machine.  By Sec.227(b)(1)(C), it is unlawful
 to send any unsolicited advertisement to such equipment.  By Sec.227(b)(3)(C),
 a violation of the aforementioned Section is punishable by action to recover
 actual monetary loss, or $500, whichever is greater, for each violation."

 problema...
Ora mi è più chiaro (credo) in che senso il C++ possa essere considerato
una sorta di super-set del C.
Mi resta un dubbio: la tipizzazione-forte (?) che il C++ introduce,
rispetto alla non-tipizzazione (?) del C, non inficia in nessun modo
l'assunto che il "C++ ... abilita e supporta il paradigma di "basso
livello strutturato" del C"?
Il quesito non è semplicemente speculativo. Mi chiedo se anche su
progetti "di basso livello strutturati" il passaggio C->C++ non comporti
comunque una sostanziale revisione del codice (del progetto?) legata,
appunto, alla questione della tipizzazione.
Grazie, julio di egidio
ju...@webzone.it

del libro di B. Stroustrup ?
Io personalmente continuo a preferire il C++ Primer, Lippman e Lajoie, 3rd
Edition; ma anche lo Stroustrup, C++ Programming Language, 3rd edition,
e` un testo degno di tutto rispetto (e io tutto sommato, tanti tanti anni fa,
il
C++ l'ho pur imparato da appunti di Stroustrup sulla base dei quali scrisse
piu` avanti la 1a edizione di questo testo).  Pero` il Lippman e Lajoe mi pare
superiore didatticamente, e la maggior parte delle persone con cui ho
parlato, che hanno provato entrambi i testi, pare d'accordo con me.  E`
anche questione di preferenze: L&L preferiscono piccoli esempi giocattolo
per chiarire i concetti, Stroustrup tende di piu` a espandere invece esempi
"quasi significativi" -- il che puo` coprire gli aspetti linguistici con
quelli
relativi alle problematiche applicative dell'esempio, se e quando queste
ultime sono in se` interessanti.
Non mancare di visitare anche 
www.bruceeckel.com
 e scaricare la beta
di "Thinking in C++" -- man mano che si evolve verso un testo "vero" e
finito, minaccia seriamente di diventare candidato al primo posto...!-)
Alex

appunto, alla questione della tipizzazione.
Il quesito infatti e` tutt'altro che stupido, e merita riflessione; ma la
risposta e` che per passare da C a C++ non e` necessario rivedere
il progetto, ma, al massimo, ritoccare alcuni punti.
Molti dei costrutti in violazione di tipo non sono corretto C ISO; e cio`,
anche se non e` detto che il compilatore C _riesca_ a diagnosticarli.
Ad esempio, supponi di avere in un sorgente pippo.c:
int pippo(int pluto) {
    return pluto;
}
e in un altro sorgente topolino.c:
typedef int (*pfun_t)(int a, int b);
extern int pippo(int a, int b);
extern int minni(int a, int b);
static pfun_t array[2] = { pippo, minni };
int unadelledue(int quale, int a, int b)
{
    return array[quale](a, b);
}
Questo programma NON e` C corretto, perche` viola la correttezza
dei tipi.  La maggior parte dei compilatori C non sono in grado di
diagnosticare questo errore; ma il comportamento del programma
e` *undefined* -- cioe`, a norma di standard, puo` succedere *qualsiasi
cosa* quando il programma ottenuto linkando queste due funzioni,
e altre ancora, viene fatto girare.  Mi pare che fosse Thomson (con
Ritchie co-inventore del C; Kernighan non e` fra gli inventori stessi)
a spiegare "comportamento indefinito significa che quando il tuo
programma gira potrebbe anche far uscire demoni dal naso del
tuo utente".  Ora, questo e` poco probabile che avvenga, ma il punto
e` che lo standard C _non lo esclude_.  Stallman, una volta, in una
vecchia versione del gcc, aveva preso la cosa in parola: a fronte di
una certa violazione delle regole, tale da costuire comportamento
indefinito, faceva partire sulla console il gioco nethack (forse come
implicito suggerimento al programmatore che era meglio che la
smettesse col C e passasse ai giochi...?-); peccato che lo abbiano
poi convinto a togliere questa simpatica feature.
La differenza in questo caso fra il C, e il C++, e` solo che in C++
l'errore del programma _viene doverosamente evidenziato_, al
piu` tardi al momento del link, comunque prima che il programma
venga "costruito" con successo e possa essere fatto girare.
Non e` dunque qui la "tipizzazione" del C++ che impone di correggere
il programma -- quello che fa e` solo garantirti la possibilita di fare
questa correzione il prima possibile, invece di doverti basare su
di un qualche misterioso crash del tuo programma in certi casi (che
magari si verificava solo con un particolare compilatore...).
In altri casi, le dichiarazioni C, del tipo:
int pippo();    /* in C significa che non dico che argomenti prenda */
vanno corrette opportunamente, inserendo i prototipi; ma questa
non e` una revisione "di struttura".  Similmente per altri dettagli,
come il fatto che il C "da per scontato" int in tanti posti dove in
C++, secondo lo standard, lo devi mettere:
pippo(pluto) { return pluto; }
dove e` scontato che pluto sia int e pippo ritorni int, e` C accettabile
secondo lo standard (ma deprecato: potrebbe sparire l'anno
prossimo...!), e invece inaccettabile a standard C++ (e quindi
va corretto, ma, ancora, questo non e` "riprogettare" il programma).
Continuando a riflettere su questi temi, vediamo che tutto sommato
la "tipizzazione stretta" del C++ non e` che la traduzione in norme,
di quella che nella buona prassi C (anche "a basso livello") era gia`
pratica comune; C++ ti obbliga a seguire prassi corrette (tipo avere
gli stessi tipi di parametri nella definizione della funzione e nella
sua chiamata), ma sono prassi che, se non le seguivi in C, anche
li` potevano portarti a remengo.
E` questa d'altronde la linea di tendenza storica dell'evoluzione
di questi linguaggi: il C, tutto sommato, differisce dal BCPL in
primo luogo perche`, in C, le variabili _hanno_ un tipo -- anche
se nel C "prima maniera" esso non veniva preso spesso tanto
sul serio...; in C a standard ISO, il tipo svolge un ruolo gia` piu`
rigoroso; in C++ standard ISO, ancora di piu`; e vedrai se lo
standard C nuovo release, speriamo l'anno prossimo, non
rafforzera` i canoni di correttezza dei tipi rispetto al primo
release dello standard, vietando alcuni dei costrutti gia` ora
deprecati, e deprecandone altri per futura eliminazione.
Alla fin fine, quando _serve_ violare la correttezza dei tipi,
come, in programmi a basso livello, puo` risultare a volte
necessario, entrambi i linguaggi forniscono lo strumento
per farlo: il cast.  Quello C++ e` piu` nitido e preciso, ma
alla fin fine le capacita` semantiche si equivalgono; usato
con parsimonia, e` uno strumento prezioso (ma se si
esagera, naturalmente, puo` dare programmi impossibili
da manutenere efficacemente...!).
Alex

affetto da Logorrea Devastante.
Sospetto, da questo tuo "che vedo qui", che, a meno che
l'inefficienza dei tuoi occhi non sia paragonabile a quella
del tuo comprendonio, tu stia leggendo questo post in
it.comp.linux (gruppo col quale l'intero thread c'entra poco,
anche se il GUL, che amichevolmente vedo che piu` oltre
chiami "Giulio", ha per ragioni sue deciso di ficcarcelo; io,
naturalmente, rispondo agli insulti su tutti i gruppi sui quali
mi vengono lanciati).  Purtroppo, la mia amata macchina
Linux e` spenta da un po', in favore di quella Win32 per la
quale il mercato attualmente mi chiede di sviluppare, quindi
non partecipo a it.comp.linux; se vuoi dare un'occhiata a
www.dejanews.com
, e farti un'idea di cosa posto anche
su it.comp.c, it.comp.java, e sopratutto it.comp.c++, potrai
certamente trovare rassicurante conferma per le tue
valutazioni -- compresa certamente quella di psicopatia.
Lo spero, perche` poche cose nella vita sono cosi` piacevoli
come avere dei nemici del tuo livello; la mia enorme
presunzione si nutre si` del piacere di essere di aiuto
a chi lo merita (il 99% dell'umanita`, dice il mio ottimismo,
e campioni come te e GUL non bastano a spezzarlo),
si` del piacere di essere ammirato da tanti, e ben
considerato da coloro la cui stima ricambio, ma ancor
piu` di quello di essere inviso ad un piccolo ma pur
sempre significativo numero di balordi assortiti.  Vista
la vostra capacita` di infilar fuffole, "caro" mio, piu` mi
detestate, piu` contento sono, e piu` confermato mi
sento nella mia rigonfia stima di me stesso...:-).
Quanto alla logorrea, beh, si dice che anche una scimmia,
che pestasse a caso sui tasti, prima o poi, statisticamente,
dovrebbe necessariamente scrivere qualcosa di vero, e
penso che questa sia la tua quota di verita` per i prossimi
sette anni: fra i miei punti di forza, la concisione non c'e`
mai stata.  "Devastante", eh?  Be`, posso sempre sperare
di avere devastato coloro che piu` se lo meritavano...:-).
Alex

Giulio wrote in message ...
    [snip]
penso che tu abbia ragione, e mi scuso della confusione
Giulio/GUL.
Alex

che puo' capitare spesso (modificare gli header delle librerie in uso),
Traduco dall'Annotated C++ Reference Manual (Stroustrup ed Ellis,
1990, citato anche in C++ Design and Evolution, Stroustrup):
"Qualsiasi linguaggio di programmazione che supporti l'accesso
alla nuda memoria lascia necessariamente i dati aperti a deliberate
manipolazioni in modi che contravvengono le esplicite regole
specificate per un certo elemento-dato", e quindi, visto che il
concetto di permettere l'accesso alla nuda memoria e` una
parte irrinunciabile degli obbiettivi del C++, "Il meccanismo di
controllo d'accessi del C++ fornisce protezione contro gli
incidenti -- NON contro la frode".
Java adotta altri obbiettivi, e infatti (poiche` la sua esecuzione
e` specificata in termini della Java Virtual Machine, che e` gia`
un ambiente "controllato" rispetto a un vero processore che
esegue nude istruzioni macchina) proibisce l'accesso alla
nuda memoria, e puo` garantire la privacy dei dati privati anche
contro deliberati attacchi (a prezzo, naturalmente, di limiti
posti alle performance "di basso livello" dei programmi in
certi casi).  Notiamo che l'uso di metodi nativi nell'ambito
di un programma compilato a normale EXE permette di
aggirare queste garanzie del linguaggio Java (cosi` come
permette di ottenere migliori prestazioni in certi casi).
Un sistema di esecuzione C++, ipoteticamente, _potrebbe_
(se gira su di un hardware, e sistema operativo, che lo
permetta) implementare un piccolo "sistema operativo
interno al suo spazio di indirizzi", girando un grosso strato
di codice "supervisore" in modo hardware privilegiato, a
fronte del codice "utente" che gira in modo hardware non
privilegiato, e gestendo le eccezioni e le commutazioni
di contesto necessarie.
Il costo in termini di prestazioni sarebbe pauroso.  Anche
con hardware ad hoc.  L'intel, un tempo, investi` un mucchio
di soldi in un chip, Apx432 se ben ricordo, fatto proprio
per implementare questo tipo di cose (soprattutto per
Ada).  Risultato di mercato: fallimento abissale; tutti
quei transistor spesi a implementare protezioni, anche
interne a un singolo programma, rendevano il chip troppo
piu` grosso, costoso, e lento, rispetto ad altri di pari
tecnologia ma con architettura piu` "disinvolta"... che
i transistor li "spendevano" per eseguire le operazioni
di effettivo interesse dell'utente, alla massima possibile
velocita`, invece che per "protezioni"...
Alex

reciproca...!
No. Il C ha una sua precisa filosofia e nicchia. Il c++ ne' ha
un'altra ! Sono due linguaggi che condividono una sintassi simile. Ma
e' un grave errore che C++ possa sostituire il C.

del C.  
Se io devo fare un programma del tipo hello world, non mi e'
necessario portarmi appresso tutta l'iostream, quando mi basta una
printf. Ma nella prima si parla di c++, nella seconda di c.
Anche se la seconda puo' essere compilata da un compilatore c++,
sempre di c si parla.

sempre di c si parla.
Solo se il programma in questione non fa uso di
nessuno dei tanti piccoli vantaggi C++ -- perfino
la sintassi dei commenti con "//", ricorda, *NON*
e` Standard C...!  E perche` mai uno dovrebbe
privarsi di tutti questi piccoli vantaggi, senza
*NESSUNA* contropartita, per non usare C++?!
Alex

 writes:
AM> soprattutto per un principiante, o per chi abbia seri, magari
AM> semi-repressi dubbi sulle proprie effettive capacitá, puó essere
Questa mi sembra molto tirata per i capelli. Tralasciando il fatto che
un  buon programmatore  e`  un buon  programmatore  sempre comunque  e
dovunque  (magari  non  afferma  "sono  un buon  programmatore"  ai  4
venti...), si puo` fare programmazione OO anche in C -volendolo fare-.
La cosa non  e` produttiva, ma mi pare sia stata  fatta. Qui non posso
essere certo  perche` raccolgo la  testimonianza di chi si  e` trovato
sotto un sorgente in C che, a suo dire, era OO (e incasinato).
(lo so, arriva  in ritardo, ma oramai per me le  news sono qualcosa di
semiirraggiungibile...)


e' un grave errore che C++ possa sostituire il C.
E` un pezzo che tu e tanti altri ASSERITE questo, ma
non avete ancora portato UN argomento tecnico sulla
qualita` dei due linguaggi, che abbia retto MEZZO SECONDO
alle piu` semplici "controdeduzioni".  Il C++ ha una nicchia
che *ricopre interamente* quella del C (basando questa
valutazione sugli standard validi _oggi_ per entrambi i
linguaggi); penso di averlo ampiamente dimostrato con
grande dovizia di argomenti tecnici, a fronte di nude
asserzioni non dimostrate, vaniloqui di "filosofia", e
varie scemenze che non dimostrano altro che chi le
asserisce non sa quasi nulla di C++, che si sono
affastellati, assieme a cose anche peggiori, da parte
degli "avversari" che continuano, senza piu` un mezzo
straccio di base semi-credibile, ad asserire il contrario.
Alex

semiirraggiungibile...)
www.dejanews.com
 (e, almeno per i gruppi it.comp.*,
anche 
www.mailgate.org
) offrono possibilita` di
accesso ragionevolmente comode alle news, a 
chiunque abbia accesso al Web (e, nel caso di
mailgate, puo` bastare l'e-mail, almeno per scrivere).
Alex

straccio di base semi-credibile, ad asserire il contrario.
Un po' meno retorica, ed un po' piu' di umilta' ( per non parlare di
rispetto ) sarebbero graditi.
Ciao.

Interessante ...
Ok, interessante, ma posso umilmente chiedere perche' ad oggi mi sono
scaricato 5826 righe di interessanti argomentazioni su c, c++, oggetti,
metodi privati e pubblici, anche su it.comp.linux?
Lo capisco e lo apprezzo sui gruppi it.comp.lang, su cui propongo di
limitare la pubblicazione, ma qui???
Ciao e scusatemi.roberto
[snippone]
-- 
Save our planet!
Save wildlife;
For your E-MAIL use only recycled Bytes !!
roberto poggi  
rpo...@usa.net

se ne stupisce?!  
Esatto. Per esempio sul tema di "Volare", "OO" ci sta benissimo.
che diamine vuol dire "OO"?
E Linux non e' un personaggio dei fumetti?
Schillogeno
------------------
"Well, i'm the slime from your video
 Oozin' along on your living room floor
 I am the slime from your video
 can't stop the slime, people, look it me go"
 Frank Zappa, 1973

cioe' utilizzare un bazuka per abbattere una mosca.
  Ok ragazzi, seguire la vostra discussione e' davvero interessante, ma non
potete mica continuare a fargli sempre le stesse obiezioni ad Alex, no?
Cosi' il discorso diventa noioso. E poi rischiamo di farlo impazzire sul
serio (oops non vorrei avervi rovinato il piano ;> ).
  Ormai (e seguo il ng solo da 15 giorni) l'ho capita anche io la differenza
tra C e C++ nell'esempio dell' "Hello world":
1)essendo il c++ pensato e concepito per non creare overhead per risorse non
utilizzate, se della iostream usiamo solo cout, solo quella verra'
effettivamente inclusa nell'.EXE. Si lo so, mi esprimo in modo barbaro, ma
il concetto e' questo no?
 2)al contrario, in c devo comunque includere stdio.h (tu non l'hai fatto eh
furbacchione?). Siccome il c non e' stato pensato per tutta questa manfrina
degli overhead, e' proprio in c che mi trascino dietro _tutta_ la stdio.h
Quindi il bazooka lo uso in C, mentre in C++ si usa uno schiacciazanzare. :)
Ciao,
  Mabu.

Quando includi stdio.h o qualsiasi header file non ti porti dietro
nell'eseguibile tutte le funzioni dichiarate.
I simboli da risolvere esternamente sono tra gli altri le funzioni chiamate
e non quelle dichiarate.
Il fatto che l'eseguibile diventi inutilmente grande dipende dalla
granularita' della libreria del C e dalla capacita' del linker di estrarre o
meno singole funzioni dalla libreria.
Per esempio se printf e' stata scritta in un modulo.c compilato in
modulo.obj e poi inserito in una libreria.lib insieme a scanf ed il linker
non e' capace di estrarre printf da questo modulo il tuo eseguibile
conterra' anche scanf.
Se, invece, il linker sa fare questo lavoro oppure se printf era stata
scritta come unica funzione del suo unico.c allora il tuo eseguibile
conterra' solo quella funzione.
Ciao.
--
Antonio Donatiello








Ciao Antonio,
grazie del chiarimento, sei stato esauriente.
Ma allora la questione e': in C mi porto dietro printf, in C++ mi porto
dietro cout.
Non e' la stessa cosa? Perche' cout dovrebbe voler dire "portarsi dietro
tutta la iostream.h"?
Nel peggiore dei casi siamo pari, ma (probabilmente) il C++ ottimizza di piu
proprio perche' e' "++" :) cioe' e' stato _concepito_ per questo, no?
Ciao,
Mabu.


Nonostante che mi affasciniate con l'ars programmatoria in cui sono
un'analfabeta integrale mi permetto di far notare 2 cosine:
1) Si pone il caso che questo newsgroup tratti di Linux e *non* di c o c++
(vi e' gia' stato fatto notare da altri ma evidentemente la foga della
discussione vi ha distratto :-)
2) Dal momento che per convinzione (personale) non uso prodotti MS,trovo
disdicevole dover scaricare via modem (ingrassando Telecom) triple copie
dello stesso post dovute a malfunzionamenti di un certo software,
Ora quando il post viene da fonti cosi' autorevoli mi vedo costretto a
chiedere se lor signori al fine di dimostrare la loro ovvia superiorita'
intellettuale non sarebbero almeno in grado di correggere il loro
news-reader al fine di non inzozzare il nostro newsgroup con multiple copie
di messaggi tra l'altro O.T.
                      Ciao,  Tino
 

Chiedo scusa,
non mi ero accorto di spedire la risposta a piu' di un newsgroup (la domanda
era stata spedita a 3 newsgroup).
Io il newsgroup di linux neanche lo leggo.
Ciao.
Antonio Donatiello

Ciao e scusatemi.roberto
Scusaci tu, poiche` hai perfettamente ragione.  Non fui io a
includere i.c.linux nella lista dei gruppi, ma dopo quest'ultimo
messaggio faro` del mio meglio per ricordarmi di toglierlo da
ogni ulteriore followup su questo thread, e lo stesso invito
rivolgo ad amici e nemici che su di esso postano.
Alex

Quindi il bazooka lo uso in C, mentre in C++ si usa uno schiacciazanzare. :)
In teoria, e in un certo senso (anche se non e` il .H il
problema, in termini di snellezza ed efficienza del programma
eseguibile risultante), hai ragione.  Anche in questo, il C++,
come linguaggio, e` e rimane superiore al C (al peggio, pari,
in questo caso, se i paladini del C a tutti i costi conoscessero 
il C stesso abbastanza bene da usare "puts" -- ma, come
abbiamo visto, usano invece il "bazooka" di printf, mostrando
che non conoscono/usano al meglio NEPPURE il linguaggio
che sostengono di preferire...!-).
Alex

e non quelle dichiarate. [snip del resto, tutto OK]
Ancora giusto, con un "sottile cavillo": non le funzioni
"chiamate" nel senso che effettivamente SIANO chiamate,
bensi` quelle che "potrebbero" essere chiamate per quel
che ne sanno compilatore e linker.
Facciamo un esempio per chiarire questa sottigliezza,
che puo` essere importante in certi casi; supponiamo
che ciascuna di queste funzioni sia definita in un file
sorgente .C di egual nome, e dichiarata da qualche
parte (come giustamente fai rilevare, la dichiarazione
non importa molto da questo punto di vista):
int a(int x1) {
    return b(x1>23);
}
int b(int icas) {
    switch(icas) {
    case 0: return c();
    case 1: return d();
    case 2: return e();
    case 3: return f();
    default: return g();
    }
};
Qui, analizzando la situazione, vediamo che se l'unica
chiamata a b() e` quella fatta da a(), allora le "funzioni
chiamate" sono solo a, b, c, e d; infatti l'espressione
"x1>23" puo` tornare solo 0 oppure 1, quindi le funzioni
e, f, g non sono "chiamate"... pero`, puoi scommettere
che nell'eseguibile ci vanno a finire lo stesso, perche`
in pratica nessun compilatore/linker fa una analisi
semantica cosi` dettagliata e raffinata (la cosiddetta
"analisi intra-procedurale", condizione necessaria ma
non sufficiente per questo tipo di ottimizzazione, puo`
richiedere risorse di tempo e spazio crescenti in modo
esponenziale con la complessiva grandezza del
programma analizzato, quindi e` "concretamente" non
fattibile).
Questa considerazione e` importante perche` ci
invita ad evitare, quando possibile, questo tipo di
costrutti; se e, f, e/o g sono "grosse", e` un vero
peccato dovercele "tirare dentro" inutilmente.
Purtroppo, la libreria Standard del C presenta proprio
un esempio di questo tipo di funzione: e` la printf.
Una implementazione standard di printf deve essere
in grado di formattare tutti i tipi di dati che ammette
(stringhe, caratteri, interi, floating...) e in tutti i vari
modi (decimali, esadecimali, ottali...); essa, ahime`,
non e` progettata in modo da permettere una fine
granularita` di link.
Questo, come ho piu` volte affermato, non e` molto
importante nella pratica (poiche` ormai le librerie
standard "vivono" comunque in DLL, o "librerie a
caricamento dinamico" che dir si voglia, comunque
presenti nel sistema), ma e` una considerazione che
dovrebbe tenere presente chi invece, contro ogni
"verita` tecnica", insiste che stdio e` "leggera" mentre
l'equivalente C++, iostream, sarebbe "pesante"...
Alex

proprio perche' e' "++" :) cioe' e' stato _concepito_ per questo, no?
In teoria, si`.  In pratica, naturalmente, ogni dato compilatore
"fa quello che vuole" (sinche` i clienti continuano a comprarlo,
o, nel caso di compilatori gratis, a scaricarlo...:-)...
Alex

Probabilmente questo messaggio e' gia' arrivato sul newsgroup. Non ne sono
sicuro perche' ho avuto problemi con Outlook Express.
Nel caso del C++ c'e' la particolarita' che tutti i metodi definiti virtual
vengono linkati al programma anche se non chiamati all'interno del
programma.
Questo perche' il simbolo esterno viene creato a livello di dichiarazione
della classe in quanto e' necessario avere l'indirizzo del metodo
all'interno della tabella utilizzata per la gestione dei metodi virtuali.
Ciao.
Antonio Donatiello

Quindi il bazooka lo uso in C, mentre in C++ si usa uno schiacciazanzare. :)
Dunque sul mio sistema i due programmini occupano ( compilati con
l'opzione --static, quindi includono tutto quello che usano )
76K e 163K rispetticamente per quello scritto in C e quello scritto in
C++.
Un rapporto 1/2 credo che non lasci dubbi tra chi sia il BAZUKA e lo
SCHICCIAZANZARE :)
Ciao.
-

proprio perche' e' "++" :) cioe' e' stato _concepito_ per questo, no?
Io per il mio codice scritto in C ( compilato con l'opzione --static,
cosiche comprendesse tutte le ruotine che usava ) ho ottenuto i
seguenti risultati :
C++ ( cout )		163K
C   ( printf )		 76K
Il c++ e' senz'altro piu' complesso e sofisticato. Ma la libreria in
effetti deve essere ancora ottimizzata ( e non so quanto poi sia
possibile ... )
NB
Ho tolto il cross-post da it.comp.linux. Poiche seguo solo questo ng,
se volete replicarmi, mandatemi mail
Ciao

possibile ... )
Possibilissimo, e come dimostrazione vediamo cosa succede
con Windows98 e Visual C++ 5, una combinazione non
particolarmente nota per eseguibili snelli.  Tutte compilazioni
senza uso di DLL, e chiedendo le dimensioni minime possibili.
Anzitutto le dimensioni su disco:
HELLOW~1 EXE        30,208  10-17-98  9:39a hellow1_c.exe
HELLOW~2 EXE        26,624  10-17-98  9:41a hellow2_c.exe
HELLOW~3 EXE        36,352  10-17-98  9:44a hellow3_cpp.exe
HELLOW~4 EXE        64,000  10-17-98  9:42a hellow4_cpp.exe
e poi l'output del programma "size" su questi EXE;
   text    data     bss     dec     hex filename
  16384   12800       0   29184    7200 hellow1_c.exe
  13312   12288       0   25600    6400 hellow2_c.exe
  22016   13312       0   35328    8a00 hellow3_cpp.exe
  45056   17920       0   62976    f600 hellow4_cpp.exe
"hellow1_c.c" e` il programma che stampa hello world con
printf; "hellow2_c.c" fa la stessa cosa con puts.  In C++,
"hellow3_cpp.cpp" usa <iostream.h>, una vecchia libreria
di I/O, mentre "hellow4_cpp.cpp" usa <iostream>, la nuova
libreria standard (quindi il primo fa "cout<<", mentre il
secondo fa ("std::cout<<").
Studiando le differenze di dimensione, notiamo che: la
prima e` chiarissima e probabilmente non soggetta a
gran che di ulteriori guadagni -- 3k in piu` per tutte le
capacita` di formattazione di printf, benche` non usate,
sembra sin poco.  I 23k in piu` fra la vecchia iostream
e la nuova sono altrettanto chiaramente ingiustificati,
visto che le funzionalita` sono sostanzialmente eguali;
qui e` chiaro che la aderenza allo standard e` stata il
solo interesse degli autori della libreria (PJ Plauger, il
segretario del comitato librerie dello standard, e la
sua gente alla Dinkumware, da cui Microsoft ha scelto
di acquistare la libreria), senza alcuna cura (rispetto
all'I/O) per le dimensioni (evidentemente sulla base
del fatto che tanto, in pratica, le librerie standard oggi
vivono in DLL).
Usando le normali DLL di sistema, la dimensione
del codice delle versioni C++ di hello world scende
a 512 o 1024 byte (dice la "size"; 2560 o 3584 byte
di spazio occupato sul disco, dice la "dir"), e penso
che sia abbastanza chiaro perche` a questo punto
ne` i fornitori di compilatori, ne` i loro clienti (cioe`
gli sviluppatori), abbiano il minimo interesse a
dedicare altro lavoro per comprimere ulteriormente
le dimensioni del codice generato per le librerie
standard -- al di la` delle polemiche sui newsgroup,
chi e` che, scrivendo un programma per Win98, si
preoccupa veramente di 512 byte di codice in piu`
o in meno...?  Anche la versione C con puts usa
1024 byte di codice e 3584 su disco, e quella con
printf 512/2560 ("il mondo alla rovescia..."!-); su
tagli del genere, dove chiaramente il Kbyte o il
mezzo Kbyte e` comunque l'"atomo di granularita`"
del generatore di codice e/o del linker, succedono
anche anomalie del genere.
Quindi, riassumendo: certo, sono possibili ulteriori
clamorose ottimizzazioni in termini di dimensioni
del codice (soprattutto rispetto a quel disastro che
e` il compilatore/linker/libreria usato da GB, in questi
termini); e` pero` molto improbabile che le vedremo
(almeno in Visual C++), considerando quanti compiti
piu` importanti, piu` urgenti, e di maggior interesse
reale per gli sviluppatori, i produttori di sistemi di
sviluppo hanno oggi di fronte a se`.
Alex

SCHICCIAZANZARE :)
Presumibilmente questo "mio sistema" di cui parla GB e` Linux.  Su
Windows98, con Visual C++ 5, e le piu` normali opzioni di compilazione,
abbiamo pure un rapporto 1 a 2: 512 byte (BYTE, *non* K) per una
versione C++, 1024 (sempre byte) per una C (altre versioni C usano
512, e altre C++, 1024).  Chi legge questo sul gruppo Linux, ed e`
interessato a maggiori dettagli, e` pregato di vedere il mio recente
post in merito sui gruppi C e C++ (
www.dejanews.com
, con opzione
Power Search, rende molto agevole trovare post passati su di un
qualsiasi gruppo).
Il fatto su cui questi numeri davvero "non lasciano dubbi" e` che le
dimensioni del codice "static" su Linux sono una vera vergogna: le
equivalenti dimensioni su Windows98 con VC++5 (scegliendo per
qualche misteriosa ragione di non usare le librerie di sistema ma
tirare "tutto" dentro all'eseguibile) sono (usando come GB lo
spazio occupato su disco, notoriamente una misura grossolana;
si usi il comando "size" su Linux per maggiore precisione) 30k
in C (con printf), 36k in C++ (con iostream.h).
Se, a sentire GB, "un rapporto 1/2 ... non lasci[a] dubbi", che dire
di un rapporto 76:30, o meglio ancora, di uno 163:36...?  Secondo
la sua logica, dunque, sarebbe forse un grandissimo errore quello
di usare Linux, invece che Windows98, visto che gli eseguibili statici
di "hello world" sono 2 volte e mezza, ovvero quasi 5 volte, piu`
grossi sul disco...?!
Sarebbe, ovviamente, una conclusione quasi altrettanto ridicola
quanto quella che GB trae sull'uso di C++ rispetto a C.  L'unica
conclusione sensata: gli strumenti di compilazione C e C++ che
GB usa su Linux sono del tutto inadatti alla generazione di
codice piccolo e compatto -- obbiettivo d'altronde spesso
considerato poco degno d'attenzione oggi, a torto o a ragione.
Nessuna ulteriore conclusione e` giustificata dai dati presentati.
Alex

vengono linkati al programma anche se non chiamati all'interno del
In generale si`, e la ragione puo` essere concettualizzata
facilmente: infatti, quando un metodo e` dichiarato virtual,
_l'indirizzo_ di quel metodo viene normalmente posto in
una apposita tabella.  In C, come in C++, se si prende
l'indirizzo di una funzione (che poi quel puntatore sia o
meno usato in seguito per chiamare la funzione), non e`
spesso facile per il compilatore (e linker) determinare se
c'e` bisogno di quel codice, per cui, nel dubbio, viene
incluso.
La specifica ottimizzazione che sarebbe necessaria per
omettere alcuni metodi virtuali mai chiamati e` in teoria
piu` semplice di quella occorrente per gestire funzioni
di cui viene preso l'indirizzo, poiche` l'uso dei virtual e`
piu` specifico e ristretto di quello dei puntatori a funzioni.
In pratica, giudicando da un dibattito di un paio di mesi
fa su comp.std.c++, pare che quasi nessuno la faccia;
apparentemente, autori e venditori di compilatori e
linker sono poco motivati dal "mercato" (in senso lato,
includendo anche quello per strumenti gratuiti) a fare
sforzi particolari per ridurre la dimensione del codice.
Si pensi anche, ad esempio, che solo una minoranza
dei linker fa la pur ridotta fatica necessaria a togliere
dall'eseguibile funzioni non usate ma poste entro lo
stesso sorgente di funzioni che sono usate... l'IBM un
tempo rilascio` un linker simile per la sua versione di
Unix, chiamata AIX, ma al release successivo gli
affianco` [causa clamori dei clienti per averlo] un "turbo
linker" molto piu` semplice e becero ma estremamente
veloce, e in pratica, a quel che so, il turbo linker fu
quello usato nella grande maggioranza dei casi -- un
link piu` veloce venendo preferito dagli sviluppatori
rispetto ad uno piu` "accurato", ma piu` lento.
Alex

rispetto ) sarebbero graditi.
Da questo lato, invece, sarebbe gradita un poco piu`
di tua competenza tecnica relativamente alle aree sulle
quali fai affermazioni perentorie su cosa "ha senso" e
cosa non ne ha.  Sospetto che entrambi i "gradimenti"
resteranno abbastanza insoddisfatti.
Alex