Newsgroup: it.comp.lang.c++
Titolo: Qualche domanda su C++ : mi levo i dubbi e poi incomincio ...

Salve a tutti,
vi chiedo subito di perdonarmi se le mie domande potranno sembrare (o
essere) un pò stupide ma così facendo mi leverò gli ultimi dubbi x
iniziare a imparare C++. Premetto che ho già iniziato a sfogliare un
paio di manuali che ho trovato in biblioteca e, a prima vista, sembra
che qualcosa  riesca a capirci. Allora:
1) Che tipo di applicazioni si possono creare con C++? Mi potete fare
qualche esempio di applicazioni usate comunemente e costruite con C++?
Che grafica si può inserire in questi programmi?
2) Per imparare a fare dei programmi di una certa complessità occorre
conoscere molto bene delle nozioni di matematica? Quali?
3) I videogiochi con che linguaggio sono programmati?Si possono creare
con C++ dei buoni ( buona grafica, ecc)  giochi?
4) In biblioteca ho preso anche un libro sul C. In questo libro viene
ripetutamente detto che, una volta imparato C, si potrà studiare più
facilmente C++. Voi che mi consigliate? Quanto viene utilizzato oggi C
rispetto a C++?
5) Mi sopportate ancora? ;-)
Okay, se avete avuto pazienza non posso far altro che esservi
grato!!!!!
Ora avete fatto 30.... fate 31
RISPONDETEMI !!!!!!
GRAZIE, THANK YOU, MERCI, OBRIGADO, ecc..
Ciao
paoCI...@iol.it
--------------------------------------------------------------------------
Per rispondere togliere CIAO dall'indirizzo e-mail
--------------------------------------------------------------------------

5) Mi sopportate ancora? ;-)
Certo :-)
Visita anche il mio sito dove troverai tantissime informazioni sul C++
(anche un tutorial)
A presto :-)
Marco Abis su IRCnet #C++Warriors
http://www.geocities.com/SiliconValley/Foothills/6336
  dedicato al C++
ab...@mv.itline.it

rispetto a C++?
Molto del C++ che viene scritto e' praticamente "C appena appena
rimasticato" (o neppure rimasticato...!), perche` il C e` in giro da
molto piu` tempo, ed e` STABILE da molto piu` tempo (lo standard
C ha quasi 10 anni, quello C++ pochi mesi -- sino a Novembre
scorso, la definizione del C++ cambiava in continuazione).  Questo
non vuol dire che convenga studiare prima il C -- secondo me, non
conviene affatto.  In C mancano tante cose che il C++ ha, per cui
devi imparare delle tecniche per supplire a queste mancanze --
tecniche che in C++ non ti serviranno (e invece i programmatori
che vengono dal C continuano a usare, per abitudine -- e fanno
male!).  Se mai, la migliore propedeutica al C++ sarebbe un qualche
linguaggio orientato ad oggetti, e ragionevolmente rigoroso, come
Java, o Sather, o Eiffel (non Smalltalk -- troppo "lasco"!); le parti
piu` complesse e intricate del C++, che derivano dal suo voler
mantenere compatibilita` con C, verrebbero cosi` temporaneamente
evitate/rimandate.
Alex

 rispetto a C++?
il C viene ancora usato per le missioni piu` "critiche", quando le 
prestazioni (memoria/velocita`) sono un obiettivo imprescindibile: 
la maggior parte dei kernel degli o.s. (da windog a linux passando per 
i vari unix) e` scritto totalmente in C, non certo in C++.
Pensa che alcuni compilatori C++ si limitano a convertire il codice C++ in 
C e poi compilano il C (in realta` in questi casi si parla piu` propriamente
di preprocessori C++).
Il fatto che un linguaggio sia piu` "produttivo" non significa 
necessariamente che sia migliore... e` semplicemente di piu` facile 
utilizzo: perdi meno tempo per ottenere quello che vuoi (spesso a scapito
delle prestazioni: vedi java).
Giulio

i vari unix) e` scritto totalmente in C, non certo in C++.
Questo solo perche'  quando hanno incominciato a sviluppare Winzozz e Linux
il C++ non era ancora cio' che oggi e' !!!!. Sicuramente non centra nulla
l'efficienza (ultimamente gli eseguibili generati da compilatori C++ "seri"
sono piu' efficienti di quelli C).
Marco Abis su IRCnet #C++Warriors
http://welcome.to/C++Warriors
 sito interamente dedicato al C++


 sono piu' efficienti di quelli C).
trattando bene le inline e il resto puoi forse arrivare all'efficienza del c,
ma superarla... 
secondo te in un futuro prossimo cominceranno a scrivere kernel in c++?
(e intendo vero c++, non codice "c" piu` qualche spruzzatina di "++" ;-)
io ne dubito fortemente....
 
Oddio, a dire il vero c'era anche un progetto per fare un sistema tutto 
col java ("jos") ma...........
Giulio
p.s. non ho niente contro il c++ in particolare, e` solo che non amo 
troppo l'oop ad oltranza ;-)
 

troppo l'oop ad oltranza ;-)
Il C++ non é SOLO oop; uno dei principali contributor allo standard
C++, Alex Stepanov, é il profeta di un altro e ortogonale paradigma, il
Generic Programming, che infatti, grazie anche a lui, ha trovato posto
d'onore nello standard, poiché su esso si impernia il grosso della
libreria standard del C++ (quello che un tempo si chiamava la STL,
Standard Template Library, termine oggi obsoleto e non piú usato).
OOP e GP non si escludono a vicenda, anzi, si complementano spesso
molto bene; e C++ é insolitamente completo e rigoroso nel suo supporto
OOP rispetto a quello mediamente offerto in altri linguaggi basati su
OOP ma con supporto anche GP, come Eiffel e Sather (Haskell e ML
rappresentano un altro punto di vista completamente diverso sul GP, e
merita studiarseli per cultura personale, ma purtroppo non hanno oggi
alcun impatto concreto in campo commerciale).
Alex

 alcun impatto concreto in campo commerciale).
Gia`.. l'ultima volta che ho usato l'ML era per un esame all'universita`, 
3 o 4 anni fa... e penso che attualmente sopravviva solo in quegli 
ambienti :-)
Giulio

ambienti :-)
Non proprio, ma quasi.
Alex

 invece molto piú usabili.
questo e` vero, anche se su egcs c'e` ancora da lavorarci un po'...
Giulio

 perche` mi rendono la vita meno pesante.
Non e' detto che l'OO sia valido solo in grossi progetti. Anche un
progetto che nasce piccolo puo' in seguito diventare sufficientemente
grande da rendere piu' valida la gestione secondo metodologie OO (e io
mi sono trovato piu' volte ad eseguire 'refatoring' di progetti che
erano troppo cresciuti rispetto alle aspettative iniziali e quindi
risultavano ormai ingestibili).
Chiaramente la minore gestibilita' di progetti non OO (quando sia
dimostrata) non e' legata all'utilizzo di metodologie non OO, ma
probabilmente alla mancata applicazione di quelle che sono le tecniche
base di 'software engineering'.
L'esperienza che ho vissuto personalmente nel portare da C a C++ alcune
applicazioni che avevano ormai raggiunto la non invidiabile qualifica di
'spaghetti_code' mi ha dimostrato che l'applicazione di tecniche OO, se
utilizzate correttamente, permette, a fronte di uno sforzo iniziale
sicuramente maggiore, un notevole miglioramento nelle successive fasi di
crescita dell'applicazione sia per quanto riguarda i tempi necessari
allo sviluppo delle modifiche che per quanto riguarda la riduzione del
numero di errori introdotti con il nuovo codice.
Ho passato circa 4 anni a programmare in C e ormai sono 5 anni che
programmo in C++ (con 3 anni di esperienza in codice 'veramente' OO) e
posso affermare che mai tornerei indietro alla
progettazione/programmazione pre OO. Non fosse altro che per la maggiore
eleganza intrinseca del codice OO.
massimo

questo e` vero, anche se su egcs c'e` ancora da lavorarci un po'...
Soprattutto in termini di qualita', e specificamente di MOLE, del
codice generato.  Se l'hacker Linux medio la pensa come te, ovvero
non e' convinto che C++ e' un linguaggio infinitamente superiore a
C in tutto e per tutto, difficilmente dedichera' il suo tempo e la sua
attenzione a ristrutturare il generatore di codice di egcs per Linux;
e cosi` mille altri hacker, vedendo egcs generare programmi grossi
a fronte di sorgenti C++ standard, si convinceranno erroneamente
che questo sia un difetto del linguaggio, mentre e' strettamente solo
un difetto del compilatore (e/o sue librerie).  Nel frattempo, sotto
Windows, dove la concorrenza morde, e morde duro, i compilatori
C++ continueranno a generare codice sempre piu` piccolo e veloce,
Questo puo` generare, in prospettiva, un circolo vizioso tale da
rendere totalmente irrilevante l'entusiasmo e la capacita' dell'hacker
medio in questione, auto-ghettizzatosi in tecnologie obsolete come
il C, mentre il mondo dello sviluppo commerciale marcera' sempre
di piu` a tappe forzate di template, OO, eccetera.  Il C++ ed il C sono
tali da occupare esattamente la stessa "nicchia ecologica", in
termini di caratteristiche tecniche (quella C++ e' piu` ampia, ma
ricopre totalmente quella C -- in altri termini, dati compilatori
altrettanto capaci, come e' vero oggi in Windows, non c'e` mai
nessuna possibile ragione tecnica per scegliere C invece di C++).
La stragrande maggioranza delle applicazioni, come ho piu` volte
affermato, sono meglio svolte in linguaggi piu` ad alto livello, meno
vicini alla macchina, e meno complicati ed astrusi; nei casi in cui
le prestazioni (o la necessita` di fare a meno di supporti runtime)
rendono desiderabile il C, il C++ gli e' tecnicamente superiore (come
e' facile vedere, poiche` puo` fare tutto quello che puo` fare il C,
PIU` un buon tot di altre cose).  Un acquisito sociologico che vada
controcorrente a queste realta' tecniche non puo` che emarginare,
alla lunga, coloro che cadono nella sua trappola.
Alex

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

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

 pratica, oggi, la OWL e' "in pensione").
[scusate se rispondo solo su it.comp.lang.c++]
Che OWL sia in pensione questo e' poco ma sicuro, visto che la stessa
Borland (masochista come mai) si e' scavata da sola la fossa, evitando di
migliorare un framework (spero che OWL possa essere veramente chiamato
cosi'!!) gia' abbastanza decente, evitando di dare un certo feedback ai
programmatori di OWL, facendo invece pagare (che vergogna) tutti i
tips'n'tricks su questo framework a caro prezzo, quando invece MFC conta di
un supporto ottimo (MSDN e' anche in linea) e di una buona base di
programmatori che sviluppano classi non comprese nel framework standard.
Con il Builder si e' voluto creare un RAD abbastanza potente con una
libreria presa pari pari dal Delphi, evitando OWL, facendo si che la VCL
vada nel mercato consumer, mentre si considera OWL per il mercato
professionale, cosa che effettivamente, a mio modesto parere, ha affossato
ancor di piu' OWL, anche perche', tornando al paragone di prima, MFC viene
usato anche da programmatori non professionali, e nonostante cio', ha un
buon supporto. A me dispiace che Borland abbia diviso il suo target C++ con
due framework completamente diversi fra loro, e, onestamente parlando, mi
ha lasciato di sasso il fatto che il Builder 3 (ma non la prima versione)
contenga anche il CD del Borland C++ 5.02, come per dire noi abbiamo
provato a sviluppare VCL per gli appassionati di informatica, pero' vi
diamo il C++ 5.02 se volete presentare qualcosa di piu' professionale ai
vostri utenti. Almeno cosi' ho capito io, o mi sbaglio?
Bye.
-- 
Jo Parrello - OWL/C++ Programmer (
jopa...@tin.it
)
http://space.tin.it/computer/giparrel

...
:     [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/

professionale, cosa che effettivamente, a mio modesto parere, ha affossato
Su questa analisi, invece, non mi trovo d'accordo; VCL, grazie anzitutto
a Delphi, ma anche intrinsecamente, non mi pare debba essere visto
come limitato al "mercato consumer".  E' invece, oggi, "il" framework
di Borland/Inprise -- OWL resta in giro solo per compatibilita`, cioe` per
permettere a chi ha gia` applicazioni basate su di esso di continuare a
manutenerle, mentre VCL e` consigliato per nuove applicazioni.  Non
e` tanto un "affossare" OWL ma un prendere atto del verdetto del mercato
(dovuto certo a tutto il complesso di fattori di cui sopra, non solo alla
qualita` intrinseca delle librerie): VCL vive e fiorisce, OWL riposi in pace
(portare avanti molteplici prodotti che ricoprono le stesse identiche aree
di mercato e si fanno concorrenza fra loro e` una strategia molto costosa
per qualsiasi produttore, quindi non posso dar torto a Borland se ha visto
di dovere fare una _scelta_ -- o investire per il futuro su VCL, oppure su
OWL -- e ha scelto VCL, visto che tra l'altro dagli introiti di Delphi dipende
tanto del suo business).
Come dicevo, io spero ardentemente che un domani la situazione in
Microsoft diventi analoga, con MFC "supportato solo per ragioni di
compatibilita`" e WFC come unico framework primario (la recente
"stabilita`" di MFC, che continua a consolidarsi in termini di bug fix ma
aggiunge ben poche nuove feature e nulla in particolare che sia molto
innovativo, lascia ben sperare da questo punto di vista, almeno se VJ++6
e le WFC avranno veramente il successo che Microsoft chiaramente
spera che abbiano -- adesso l'esigenza numero uno e` un consolidamento
di WFC, con miglioramento di prestazioni e riduzione di bug, ma questo
e` lecito sperarlo, trattandosi della direzione piu` abituale nel passaggio
dalla "1.0" alla "1.1" di qualsiasi programma [MS puo` anche chiamarlo
"6.0" se vuole, ma e` ovvio che oggi WFC e` appunto una "1.0"...]).
Alex

oggi svolge un ruolo importante nei kernel Microsoft; 
Seguo ta tempo quello che succede nell'SDK della Microsoft. L'unica vera
novita' mi sembra che hanno incominciato ad usare il compilatore Microsoft.
I programmi tecnicamente migliori sono ancora scritti da persone abituate a
pensare in C. Le poche classi usate decentemente (anche per OLE!) non sono
ovviamente ne MFC ne ATL. Il programmi con le MFC non sono di solito un gran
che tecnicamente,
Cutler, capo progettista di NT (ex-Digital), fino alla versione
3.51considerava il C++ una jattura, perche' non garantiva al programmatore
una comprensione efficace di cosa succede (fonte: libro "I guerrieri del
Software"). Non credo che abbia cambiato idea visto il successo della
architettuera del S.O. L'architettura del kernell non ha subito cambiamenti
infatti ad tutt'oggi.
Se poi usano i template bisogna vedere che compilatore usano. Non certo
versioni fino al VC 4.2 (molto deludente). Il VC 5.0 ha raggiunto la decenza
con i template. Basta usare le classi innestate pero' che il VC va in crisi
profonda. Io faccio un grande uso delle classi innestate per dividere gli
oggetti membro di una classe in categorie di appartenenza (quando superano
un certo numero n.d.p.). Questo limite per me e' grave.
Puo' anche essere che i progettisti Microsoft siano tornati ad usare
compilatori non Microsoft, pero' mi sembrerebbe strano. Sospetto che NT 5.0
sia sotto Cutler, e mi meraviglierei, se avesse deciso di rende imbrido il
kernel usando anche il C++. Pensare il C++ e contemporaneamente in C non e'
facile per nessuno.
+++
Non ho dubbio che il gruppo che fa capo a Jim Allchin usa, e tanto, il C++.
Pero' quel gruppo, dopo il kernel Mach, non mi risulta che abbia prodotto
piu' niente. Sono una vita che lavorano su Cairo, ovvero un progetto che e'
tutto e niente.
+++
Forse il gruppo che lavora su NT 5.1. Forse chi sviluppa COM+.
+++
Probabilmente chi lavora su NT 6 lavora in C++. Li possono rifare
praticamente da zero il S.O.
+++
Sul gruppo che ha fatto CE non so assolutamente nulla.
--- (Elimina il papero per le repliche) ---

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

 infatti ad tutt'oggi.
Dati l'elenco quasi infinito dei problemi di NT, non ritengo di
considerare l'affermazione di Cutler (che resta comunque un grande) da
accettare ad occhi chiusi.

 
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

Salve,
scusate se mi intrometto solo ora (e` da un po' che seguo questa
discussione, ma per esperienza sono restio a partecipare a discussioni
simili almeno fino a quando non mi accerto del tono costruttivo che
qui mi sembra rispettato).
Desideravo ribattere ad argomentazioni che sono saltate un po' qua e
un po' la, e magari aggiungere qualche mia personale considerazione.
In primo luogo vorrei smentire l'idea di compilatori C++ che in
realta` prima traducono in C e poi compilano... Oggi questo non e`
piu` vero gli attuali compilatori producono direttamente codice
macchina, solo i primi compilatori si comportavano diversamente.
Si trattava sostanzialmente di una fase di transizione in attesa dei
primi compilatori nativi, era molto piu` semplice passare dal C++ al C
che dal C++ al codice macchina, questo approccio inoltre e` molto
diffuso nel mondo Unix (e cloni) per i linguaggi meno diffusi (es.
Lisp, Pascal...) sostanzialmente per ragioni di convenienza...
Per quanto riguarda il confronto nelle prestazioni tra C e C++ ci sono
diverse cose da tener presente:
1) Il C++ non introduce alcun overhead addizionale sul C, nel senso
che i costrutti C del C++ non costano una virgola di piu` di quelli
nativi C;
2) I costrutti innovativi del C++ derivano da tecnologie che mirano a
risolvere i problemi di manutenibilita` del software, problemi che
alla nascita del C++ si andavano manifestando nei linguaggi
procedurali (in testa il C): il famoso concetto di scatola nera si e`
rivelato un sostanziale fallimento.
Questi costrutti non aggiungono overhead gratuitamente...
l'overhead addizionale e` il prezzo da pagare a fronte ad esempio
della flessibilita` offerta dal polimorfismo, se non ci credete
provate a implementare il polimorfismo in C e ditemi se potete
fare a meno del livello di indirezione aggiuntivo.
Controesempio: avete mai provato a scrivere un programma di
IA (secondo la teoria classica) sia in C++ (o C) che in Lisp?
Quale dei linguaggi vi ha reso la vita piu` facile?
3) Ricerche dimostrano che le tecniche di ottimizzazione tipiche dei
linguaggi procedurali falliscono con i linguaggi ad oggetti e fino a
qualche tempo fa tutti i compilatori C++ utilizzavano le stesse
tecniche utilizzate nel C (non una virgola in piu`, ne una di meno).
Nei linguaggi ad oggetti molte ottimizzazioni potrebbero essere
fatte durante il linking, ma il linker C++ per molto tempo e` rimasto
lo stesso di quello C!!!!
Quante ad affermazioni sulla jattura di quel dato linguaggio, ci
penserei almeno due volte prima di prenderle sul serio. Ho avuto
modo di provare diversi linguaggi nel corso dei miei studi
(Basic,Pascal standard, Turbo Pascal, Lisp, Galileo, qualcosa di
Prolog, C++) ed ho imparato che per valutare attentamente un
linguaggio ci vuole molto tempo e soprattutto la capacita` di pensare
secondo la sua filosofia. Non si puo` apprezzare un linguaggio
funzionale se si pensa "procedurale", mi sembra ovvio!
Spesso chi viene dal C si trova male con il C++ perche` applica ancora
il suo vecchio metodo, ritenendo che la similarita` sintattica (e in
parte semantica) tra i due linguaggi significhi che il C++ e`
semplicemente un Super-C!!!!!!
Niente di piu` sbagliato. La tecnologia ad oggetti sposta molto del
tempo di sviluppo di una applicazione nella fase di design, piu` di
quanto non lo imponessero le precedenti tecnologie (di cui il C e`
figlio).
Certo potete continuare ad utilizzare il C++ come un C migliore, cosi`
come io preferisco la OOP alla programmazione generica prendendo da
quest'ultima solo cio` che ritengo valido.
Ormai mi dedico da qualche tempo solo al C++, ma solo lontano dal
pensare che esso sia la cura di tutti i mali, non credo di essere
l'unico a sostenere che il paradigma ad oggetti del C++ non sia esente
da problematiche anche grosse. E neanche` STL a prima vista mi sembra
un granche`. Tuttavia al momento lo preferisco per molte cose a
qualsiasi altro linguaggio.
Concludendo (scusate se sono stato prolisso) vorrei aggiungere che  e`
sbagliato porsi la domanda "Questo linguaggio e` migliore di
quell'altro?", la domanda corretta e` "Nell'ambito del problema che
devo risolvere (e cercando di considerare possibili risvolti futuri),
quale strumento (linguaggio) mi conviene utilizzare?"
Se cio` che conta per voi sono le prestazioni, non credo che
scrivereste quella data funzione in VB, probabilmente se necessario
potreste anche decidere di scendere fino all'assembler!
Saluti,
Paolo

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

potreste anche decidere di scendere fino all'assembler!
Ma, in generale, e per decisioni di maggior respiro rispetto a "come
scrivo adesso questa singola, specifica funzione", e` invece molto
importante capire quali limiti, ad esempio di prestazioni, possono
derivare solo da difetti dello strumento (compilatore, ecc), e quali
invece sono intrinseci al linguaggio in quanto tale.  Questo non e`
molto rilevante per il VB, linguaggio proprietario che quasi si identifica
con la sua unica implementazione, se non per i vincoli che la
compatibilita` col passato potra` per sempre imporre al suo futuro
sviluppo; e` invece cruciale per linguaggi non proprietari, come C,
C++, Java, eccetera.  Java presenta alcuni "overhead intrinseci",
ad esempio, che e` molto importante studiare e capire bene, per
rendersi conto degli ambiti nei quali altri linguaggi come il C++ gli
resteranno sempre superiori -- ma non vanno confusi con gli
overhead *occasionali e perfettamente superabili* dovuti solo al
fatto che, ad esempio, una data implementazione Java sceglie di
usare bytecode invece di codice macchina nativo.
C++ non presenta nessun overhead intrinseco rispetto al C, e
quindi, paragonando i _linguaggi stessi_ e non due particolari
compilatori, si possono notare solo le superiorita` del C++ e le
ragioni per queste superiorita`.  Poi, naturalmente, i linguaggi
possono evolversi e influenzarsi a vicenda (ad esempio, il C
ha copiato dal C++ il concetto di prototipi di funzione, quello
di const, eccetera), e un linguaggio puo` introdurre a un certo
punto un costrutto o meccanismo i cui vantaggi e svantaggi
vanno ben compresi (ad esempio, per il prossimo standard
del C, si parla molto della possibilita` di array automatici ma
dimensionabili al momento della creazione -- questa, che gcc
ha implementato da anni, e tante versioni non-standard di C
e C++ presentano con "alloca" ovvero "_alloca", e` una
estensione la cui presenza nello standard di un linguaggio e
non di un altro puo` fare, in certi casi specifici, una notevole
differenza relativamente alle prestazioni).  Se si rinuncia a
porre confronti e contrasti fra i linguaggi, magari solo per
amor di pace e per evitare le polemiche, si sacrifica un
importante canale di apprendimento e approfondimento.
Ebbene, che i polemisti per partito preso vadano allora a
farsi friggere, dico io, e non me ne lascio certo spaventare.
Alex

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

importante canale di apprendimento e approfondimento.
E` proprio dai confronti che nascono nuove idee, l'importante e` evitare di fare polemica
fine a se stessa, non ha senso e non e` costruttiva.
Paolo

senso sceglierebbe il secondo. Ma fattori quali i difetti
dell'implementazione diventano
A buon senso vien fatto di pensare cosi`, ma... non e` detto:
c'e` un ottimo controesempio, dovuto mi pare a N. Myers,che
porta a riflettere sul cosiddetto assioma che "la cosa piu`
importante e` che un programma sia corretto, farlo veloce
e` una considerazione secondaria".
Supponi di potere scegliere fra due compilatori per lo
stesso linguaggio C.  Il compilatore A e` solido e robusto,
e compila un tipico programma di 1000 righe in circa 20
minuti, producendo codice che gira attorno a 1 mega
operazioni al secondo.  B ha un baco malnato: se mai
si trova una lettera o cifra come primo carattere di una riga,
va in crash, con un messaggio d'errore sballato sul fatto
che manca spazio di memoria a quella riga.  Se tutte le
righe iniziano con spazi o punteggiatura, pero`, e` un
lampo -- compila lo stesso programma di 1000 righe in
circa 5 minuti, e produce codice che gira attorno a 2
mega operazioni al secondo grazie a un ottimizzatore
di tutto rispetto.
Quale dei due compilatori sceglieresti di usare: quello
decente, o quello bacato...?
La maggior parte dei programmatori sceglierebbero
quello bacato, magari tirando moccoli ogni volta che
si scordano di inserire spazi all'inizio delle righe, ecc
ecc; la combinazione di velocita` di compilazione, e
eccellenza di ottimizzazione, e` troppo accattivante...!
Evitare i bachi e` dunque, si`, importante, ma non ha
_assoluta_ priorita`, in molti casi, sulla velocita` di
elaborazione e qualita` del processing effettuato.
Non a caso le software house, che rispondono al
mercato, tante volte in un rilascio successivo di un
programma hanno inserito feature, o, a volte,
accelerato un certo tipo di passaggi, a prezzo di
lasciare nel programma alcuni bachi che gia` si
conoscevano dal rilascio precedente...
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

conoscevano dal rilascio precedente...
Pero` le software house ragionano in termini di guadagno...
Saluti,
Paolo

Pero` le software house ragionano in termini di guadagno...
Appunto: alla fine, il guadagno, a lungo termine, si fa fornendo
prodotti e servizi che corrispondano ai desideri ed esigenze
dei clienti; questi, a loro volta, essendo i clienti, mediamente,
operatori economici razionali, non sono "a capocchia", ma
legati alle effettive condizioni in cui operano.
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

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.