Newsgroup: it.comp.lang.c++
Titolo: quasi OT: perchè ancora C?

PREMESSA
Non voglio assolutamente sollevare un vespaio e iniziare un thread inutile di
discussioni. La mia domanda è pura e semplice curiosità e voglia di imparare,
senza intento polemico :-)
DOMANDA
Perchè il linguaggio C è ancora così diffuso (soprattutto su Linux) quando il
C++ (che è appunto un'evoluzione del C) permette di fare le stesse cose in modo
più elegante e semplice?
Ciao a tutti
Anto

 più elegante e semplice?
Si e' discusso piu' volte di questo argomento, ed ogni volta non mi sono
lasciato persuadere dalle affermazioni dei sostenitori del "vecchio" C (I
Love C++!)
Ho da poco letto un'intervista fatta a Linus Trovald, il creatore di Linux,
o meglio, del Kernel di Linux, il quale ha affermato che il C e' piu' maturo
e puo' contare su compilatori piu' perfezionati per cui, rinunciando alle
funzionalita' proprie del C++ (programmazione generica, programmazione ad
oggetti ecc.), e' possibile sviluppare codice piu' semplice e contare su un
piu' leggibile resoconto di warning ed errori da parte del compilatore.
Pare infatti che se si usano i templates in modo molto spinto, si puo'
incorrere in errori infimi e subdoli difficilmente scovabili dal
programmatore e, ahime', dal compilatore...
Avevo poi sentito qualche commento riguardo un "presunto" maggiore overhead
del codice C++ rispetto a quello C, ma non ricordo se si parlava di Compile
Time o Run Time.
Certo e' che se Windows, Unix, Linux e non so quali altri O.S. sono scritti
in C, qualche motivo, che a noi poveri mortali magari sfugge, ci sara'...
Cedo la parola ad Alex Martelli: lui non e' un povero mortale...
Ciao, Davide.

 Cedo la parola ad Alex Martelli: lui non e' un povero mortale...
Sono in effetti un mortale discretamente benestante, ma non vedo
bene come il mio status finanziario mi aiuti a discernere le ragioni
richieste.  Presumo che, a parte l'inerzia che e` sempre una forza
potente, la qualita` degli ottimizzatori dei compilatori in gioco
(gcc, nel caso di Linux) debba essere la causa fondamentale; ma
non e` che un'ipotesi.
Alex

programmatore e, ahime', dal compilatore...
Urgh... ed io che pensavo fosse l'esatto contrario !!! 
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
---------------------------------------------
#exclude <windows.h>

 Anto
Non intendo rispondere a cotanta domanda.
Ipotesi, solo ipotesi.
Se fosse possibile metterei un IMHO grande come una casa come intestazione 8-)
Mia opinione, spassionata e scanzonata ...
Piccola premessa sulla diffusione del C.
Fintanto che il C restò all'università andava tutto bene: i vantaggi della programmazione procedurale erano chiari, la potenzialità
del linguaggio palesi. Ma quando si è trattato di infilarlo nel "mondo reale" le cose sono andate diversamente.
Molto diversamente.
I programmatori erano così assuefatti a ragionare in termini di "words", "bytes, "registri" e sub-routines che non capivano la
necessità delle funzioni, della strutturazione. Il ragionamento suonava "Ho fatto un programma in C invece che in ASM. Non vedo
alcun miglioramento, se non un leggero degrado delle prestazioni".
Il "programma C" era la traduzione pedissequa in C di quello che aveva pensato in assembler. Ovviamente la colpa era del C.
Ma allora, quando si è affermato il C ?
Quando i programmatori sono stati _costretti_ ad utilizzare un costrutto procedurale.
Cosa gli ha costretti ?
Le richieste: volevano programmi sempre più grandi, volevano "controllare il processo di sviluppo",  volevano che il codice fosse
portabile, volevano interventi di manutenzione a costi ragionabili, volevano ....
Il programmatore si è trovato di fronte alla _necessità_ di utilizzare il C. Lo scopo delle cose che prima gli sembravano "una
inutile complicazione" è diventato chiaro.
Solo la pura necessità muove questo genere di cose.
La storia si ripete.
Molti programmi C++ che vedo sul lavoro non hanno nulla a che fare con l'OO. Sono programmi procedurali scritti con il C++. Tanto
vale scriverli nel linguaggio che meglio supporta il costrutto che si è utilizzato nel progetto e con il quale si ha più
familiarità: il vecchio C.
A ben pensarci, non si tratta di una scelta così sbagliata: ho gia` tanti problemi con il progetto X, perchè devo infilarmi nel
tunnel di un linguaggio nuovo, con compilatori che non conosco (o che non controllo perfettamente), pieno di cavilli che per me non
hanno alcuno scopo ?
Quando la _necessità_ impone (imporrà) i costrutti OO, è (sarà) naturale utilizzare il linguaggio appropriato.
Provate ad utilizzare il C per scrivere un pattern o a realizzare un progetto sviluppato secondo una metodologia OO. Una fatica
enorme ed inutile. Uno spreco.
Pensierino.
Certo che chi non sarà in grado di cogliere il cambiamento si troverà un po' spaesato ;)
TaZ++

 Ci sei arrivato da solo ? :)
Si !
Dopo profonda riflessione e senza averci provato ;)
In puro stile OO.
Non male, vero ?
8-))
TaZ++

Una fatica enorme ed inutile. Uno spreco.
Ci sei arrivato da solo ? :)


piů elegante e semplice?
Principalmente per inerzia... c'e` molto codice C in giro e lo standard
del C++ non e` ancora corretttamente implementato dai principali
compilatori.
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

Grazie a tutti per le numerose risposte. Io resto della mia idea: sono giovane
e ho imparato dal BASIC ma dopo aver letto uno o due libri di C++ e OOP ormai
mi viene più naturale *pensare* ad oggetti che non in modo strutturato (inteso
come programmazione tipo C o PASCAL). Se a tutti i nuovi programmatori verrà
insegnato il C++ *senza* passare prima per il C faremo passi da gigante :-)

...

Tieni presente che, come ti ha gia' segnalato qualcuno, l'inerzia non e'
solo dei programmatori.
Per alcune piattaforme un compilatore C++ non esiste.
Per altre quelli che ci sono sono piuttosto lontani dallo standard oppure la
qualita' e' talmente
scarsa da scoraggiare anche il piu' entusiasta.
In altri casi la proposta di investimento per il compilatore C++ viene
respinta perche' sono
gia' stati fatti grossi investimenti per il C (tools di sviluppo,
addestramento del personale,
codice gia' scritto. Non sempre (quasi mai) chi paga e' una persona
sensibile alle tematiche
OO, SW engineering ecc.
F.


Esatto! Purtroppo in moltissime software house al capo non gliene può
fregà de meno se la programmazione ad oggetti C++ è pura ed inviolata
dal C...
Luc.

Purtroppo [..] se la programmazione ad oggetti C++ è pura [..]
Purtroppo, o per fortuna, ad un capo progetto delle cosidetta purezza
del linguaggio XXX non deve fregarne un bel nulla.
Un conto e' partire con un progetto nuovo con programmatori che
conoscono ugualmente bene C che C++, e hanno esperienza con ambedue i
linguaggi. Un conto e' la realta'.
Data una libreria in C che e' costata parecchi anni uomo, che
funziona, che e' conosciuta bene aziendalmente, rifarla "solo" perche'
C++ e' bello, e' semplicemente una cosa stupida. Se ci sono vantaggi
"operativi" a sviluppare un progetto in Cobol invece che in C++, la
cosa giusta e' svilupparla in Cobol.
Una delle fortune del C++ e' proprio la possibilita' di convivere con
il passato piu' o meno negletto, e la possibilita' di adottare
tecniche di programmazioni impure.
Un esempio. Riscriviamo tutti gli Unix in C++, perche' C++ e' meglio?
Le parti "nuove" forse, ma per il codice in eredita' che senso avrebbe
un simile porting? Invece di fare quel porting non sarebbe meglio di
occuparsi di altre cose?
-- 
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero
Recensioni Papere su 
http://www.komix.org

 occuparsi di altre cose?
Sono abbastanza d'accordo con te, pero' quello di riscrivere Unix in C++
e' stato per anni uno dei progetti nel cassetto di Bill Joy, tra gli
autori di BSD e stratega tecnologico della Sun. Poi si sono dati a
Java...
Ciao,
Nicola




A scopo di chiarimenti (chiedo anche a tutti quelli che seguono il C) è
vero che non si usa più exit(0) nei programmi perché rimossa dallo
standard?
Dove ho letto io si diceva che era stato fatto per compatibilità con codice
C++, ma di solito non è il contrario, ovvero compatibilità C++ con il C? 

 controllo dell'hardware ecco che il C la fa ancora da padrone.
E' tutto da dimostrare, secondo me.
EMG

Non è affatto vero. Nessuno mi vieta di usare la programmazione strutturata
in C++.
int main() {
     return 0;
}
Secondo te è un codice  C o un C++?
Cmq per velocità di esecuzione un programma in Assembly è ancora il
migliore ed ancor meglio sarebbe il linguaggio macchina. 
Inoltre seguendo il tuo ragionamento mi verrebbe voglia di tornare a
010100010001  così almeno recupero in prestazioni.

 standard?
La funzione exit() mi risulta continui come sempre a far parte della
libreria standard del C, usabile anche in C++.
EMG

Secondo te è un codice  C o un C++?
C++
Se fosse C equivarrebbe a
int main(...) {
	return 0;
}
che e' diverso da
int main(void) {
	return 0;
}
--
 (o-  | Un OS per domarli, Un OS per trovarli,
 //\  | Un OS per ghermirli e nel buio incatenarli
 V_/_ | 
http://pinguin.linuxave.net
 r.salmaso(at)
flashnet.it

semplice ma appesantisce il codice oggetto prodotto.
[...]
questo e` falso, in C++ non paghi cio` che non usi e i costi
che eventualmente avresti sono inerenti al meccanismo
utilizzato (vedi polimorfismo).
Anzi in alcuni casi certi costrutti ti forniscono prestazioni migliori
che in C


migliore ed ancor meglio sarebbe il linguaggio macchina. 
Beh, questa è proprio GROSSA, ti rendi conto che hai scritto una cosa
tipo: "Il linguaggio ABC è più veloce del linguaggio ABC"
Linguaggio Macchina=rappresentazione numerica binaria del linguaggio
Assembly.
Torna a programmare in C/C++ 8-)
Luc.

standard?
Che io sappia exit esiste ancora ed e` standard!
E non e` stata introdotta per compatibilita` col C++...
(che io sappia)


 che in C
Verissimo!  E di questo i compilatori cominciano a trarre pieno
beneficio, per fortuna.  Ad esempio, i vincoli semantici relativi
al polimorfismo ('vptr' invariante per un oggetto) consentono di
generare per un caso come il seguente codice migliore di quanto un
compilatore C non potrebbe fare senza eventuali analisi globali per
un codice grosso modo equivalente:
    void f(C* pc) {
        pc->a();
        pc->b();
        pc->c();
    }
Queste tre chiamate indirette (supponendo si tratti di metodi
virtuali) usano lo *stesso* immutabile virtual-pointer e quindi
possono 'pagare' la indirettezza stessa una volta sola.  La
'traduzione' alla C:
    void f(C* pc) {
        pc->vptr->a(pc);
        pc->vptr->b(pc);
        pc->vptr->c(pc);
    }
non e` altrettanto ottimizzabile senza analisi globali, non
potendosi esprimere il concetto "nulla puo` cambiare pc->vptr
fra l'una e l'altra di queste tre chiamate", per cui esso
dovra` essere ricaricato memoria->registro tre volte invece
di una.  Giusto per dare un esempio elementare... in questo
caso e` chiaro che il programmatore C potrebbe simulare la
condizione copiando pc->vptr in una variabile locale una
volta per tutte all'inizio della funzione.  Ma in vari altri
casi meno elementari e piu` sottili non esiste un'esatta
equivalenza che permetta ottimizzazioni altrettanto spinte.
Alex

Prova a fare un programma in C++ ed uno in Assembly. Io provato a copiarne
uno che faceva "hello world" in Assembly ed un altro in C++ con analogo
uso. (entrambi erano per il dos).
Il risultato era che il programma Assembly faceva comparire la suddetta
frase con una media di  0.4 secondi di anticipo. (ho provato diverse
volte).
Inoltre se io scrivo un programma in linguaggio macchina le dimensioni
dell'eseguibile sono nettamente inferiori a quelle dei linguaggi ad altro
livello e ciò permette una maggiore velocità in esecuzione.
Però trovo assai scomodo fare un applicativo in Assembly o in linguaggio
macchina.
Cmq il discorso delle prestazioni è iniziato a causa di quel apprezzamento
errato verso il C e spero che anche  tu lo consideri tale.
Come posso però tornare a programmare in C++ se lo uso costantemente?
(seguendo la tua ultima frase).
PS: Forse è vero, ho fatto un paragone sbagliato. Ma bisogna anche rendersi
conto che in Assembly vado ancor più a basso livello del C++ e con
linguaggio macchina vado al massimo. 

Appunto. Io volevo far capire che le differenze tra programmazione
strutturata C e C++, a parte le aggiunte, sono solamente delle
sottigliezze. 
Perň volevo farmele dire da Giuseppe. (Non che io non apprezzi le tue
risposte, tutt'altro).

linguaggio macchina vado al massimo. 
Hai un attimo una falla nella conoscenza dei linguaggi a basso
livello, ad esempio:
- LINGUAGGIO MACCHINA
68 1F 00 02 00
- ASSEMBLER i386
push 2001Fh
SONO LA STESSA COSA ALLA FINE!!!!!!!!!!!!!!!!!!!!!!!!
Luc.

Finche si tratta di programmi molto semplici puo' essere vero.
Altrimenti, esprimere un problema complesso in Assembly e' un compito al
di la' delle capacita' della maggior parte dei programmatori, anche se
avessero padronanza del linguaggio. La "teorica" soluzione di un
problema in Assembly e' piu' efficiente della "teorica" soluzione dello
stesso problema risolto in C++. E' tutto da dimostrare che nella pratica
sia davvero cosi' e che l'aumento esponenziale dello sforzo valga il
risultato.
Ciao,
Nicola

 libreria standard del C, usabile anche in C++.
Vero. In C++ pero' va usata con estrema cautela perche' scavalca la
distruzione degli oggetti allocati sullo stack.
Ciao,
Nicola

Lo confesso, ho avuto a che fare solo con Java, C++, Visual Basic e
qualcosa di C e Pascal (tutti linguaggi ad alto livello).
Cmq mi consolo perché nella scuola superiore che sto frequentando ti
insegnano a programmare in Pascal senza insegnarti ad usare il dos.
Incredibile.
Inoltre si arriva in quinta senza saper usare nessun browser internet.
Pensate che una volta ho domandato a mia cugina che ormai era alla fine
della quinta quali linguaggi avesse fatto e lei mi ha risposto "Abbiamo
fatto tutti i migliori e recenti linguaggi. Ovvero Pascal e sql"
Cmq avevo intenzione di studiare Assembly ma non credo che sia ancora il
momento. 
(Al 5% dei casi non riesco a rimettere a posto il mio computer, quindi
lasciamo perdere Assembly).
Secondo voi nell'informatica è ancora necessario conoscere Assembly e
linguaggio macchina?
PS: Complimenti Luc, dimostri un ottima padronanza dei linguaggi a basso
livello. Quanto vorrei essere come te.

Dopo tutto hai ragione, lavorare con i registri della CPU per fare un SO mi
intimorisce abbastanza.
Saluti.

C'e' un'altra considerazione.  L'assembler tout court non esiste...
Quello che indicate con questo nome e' un insieme di mnemoniche in
corrispondenza (generalmente) biunivoca con il set di istruzioni
macchina, per cui bisognerebbe parlare di assembler per una certa CPU.
A suo tempo anche io usavo l'assembler; ho uasto prima quello della
famiglia HP 2100, poi quello della famiglia Cyber 6000, poi quello dei
PDP, e dopo di quello cominciato a guardare quello dei VAX - ma non ho
mai terminato.  Mi sono chiesto se valeva la pena di studiare
linguaggi che diventano morti con la morte della CPU.  E la risposta
e' stata no.
Non so set il set di {istruzioni macchina | mnemoniche assembler} sia
lo stesso per ogni chip della Intel (ma suppongo di no); pensate cosa
accadra' ai complicatissimi programmi dell'esperto di assembler di un
certo chip Intel quando quel chip Intel sara obsoleto ...  o quando
tutti useranno Alpha ... o ...
Your mileage may vary, come dicono gli americani...
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it

Molti anni fa (nel senso naturale dell'espressione, non intendo ai tempi
del 286 :-), quando non c'era altro che il linguaggio macchina,
L'Olivetti si rivolse ad uno psicologo per individuare dei criteri volti
a selezionare le persone piu' adatte all'attivita' di programmazione.
Questi ci penso' un po' su e alla fine rispose che andavano cercate
persone appassionate di enigmistica. Fu compiuta un indagine interna e
risulto' che la maggior parte dei programmatori era effettivamente
appassionata di enigmistica.
Ciao,
Nicola

 }
Anche in C si può omettere il void nella dichiarazione della main(), mi
sembra.
EMG

Your mileage may vary, come dicono gli americani...
And you turn the volant... 8-)


Sono sempre stato il primo in 'Sistemi' all' ITIS 8-)
Comunque era quasi tutto 'autodidattico', il mio C64 tremava quando
caricavo l'assemblatore ^_____^ bei tempi...
Luc.

 linguaggio macchina?
Dipende da cosa intendi per necessario: se il tuo lavoro non lo
richiede, non *serve*. Cio' non toglie che l'arricchimento della propria
cultura e' sempre una cosa positiva, e puo' risultare utile in modo
trasversale, ovvero puo' darsi che l'esser venuto a conoscenza di
problemi particolari ti porti per analogia ad individuare soluzioni
migliori per i problemi che affronti tutti i giorni.
Per guidare la macchina non occorre sapere come funziona, ma sono
convinto che Schumacher conosce ogni vite della sua Ferrari.
Ciao,
Nicola

 sono sempre le stesse cose)
Non sono molto d'accordo.  Finche' rimani nella stessa _famiglia_ di
processori non cambia molto; ma passare da un Intel a un PDP non credo
sia facile.
HP e Compass ad esempio non avevano il concetto di stack.  I primi HP
2100 avevano solo due registri dati, A e B; dai 21MX in poi comparvero
due registri X e Y con un subset delle istruzioni di A e B, ed alcune
aggiunte per gli indirizzamenti con offset (prima sconosciuti).
Per l'HP, conoscevo a memoria il codice numerico della maggior parte
delle istruzioni; se mi serviva un valore numerico (ad esempio 10) che
corrispondeva ad una istruzione gia' usata, labellavo con D10
l'istruzione ed usavo poi la label per i calcoli ...  Per gli altri
assembler non sono mai arrivato a tanto (il primo amore non si scorda
mai).  E se mi serviva una memoria dove storare dati, la label
relativa era sempre su una istruzione macchina che veniva eseguita una
volta sola, per risparmiare spazio (specialmente nei drivers era
importante).
Il Compass era piu' artistico: le parole erano di (credo, non sono
sicuro) 48 bits, e le istruzioni macchina di 12, 24 o 48 bits (o
comunque di 1/4, 1/2 e 1 parola).  Bisognava cercare di riordinare le
istruzioni in modo che le relative lunghezze si sommassero a una
parola tonda tonda; infatti, se rimanevano buchi, venivano riempiti
con dei NOP e la lunghezza del programma aumentava.  Ah, che salti
mortali per risparmiare una parola...
I VAX avevano istruzioni studiate in modo da ottimizzare l'uscita dei
compilatori FORTRAN; mi ricordo una istruzione unica che aveva tutta
la funzionalita' di un DO I=I1,I2,I3 ... ENDDO.  E che richiedeva
un mucchio di parametri.
Beh, siamo _ampiamente_ OT (non piu' solo quasi); smettiamola.  Ma
sai, la nostalgia ...


 wrote in message
news:39507D71...@flashnet.it...

main e` sempre un caso particolare.  Raramente si dichiara main; ci si
limita invece a definirla, come e` fatto in tutti questi casi.  "()",
due parentesi con nulla in mezzo, in C hanno semantica diversa se usate
in una dichiarazione di funzione o invece nella sua definizione; in C++
hanno invece la stessa semantica nei due casi (benedetta semplificazione!).
Trattandosi qui non di dichiarazioni ma di definizioni, C e C++ sono
equivalenti da questo punto di vista.
Alex

 sottigliezze.
Non sono d'accordo.  In C (standard ISO/ANSI esistente; non so del
nuovo) devi dichiarare tutte le variabili all'inizio del blocco cui
appartengono, ad esempio; in C++ puoi dichiararle in qualunque
istante precedente al primo uso, e lo stile che cio` vuole fortemente
incoraggiare e` la dichiarazione "il piu` tardi possibile" e sempre
o quasi sempre accompagnata da inizializzazione.  E` tutt'altro che
una sottigliezza.
Alex

Allora sono proprio messo male.
Cmq che modo carino di selezionare la gente...
Saluti.

Io le considero piccole varianti, ma dato che  dici questo sarà
sicuramente così.
Grazie Alex

Io sto frequentando l'IGEA, ma lasciamo perdere per i motivi già descritti
in
precedenza.
Avevo chiesto quali linguaggi venivano affrontati a persone che frequentano
l'ITIS più vicina e mi hanno risposto qbasic(che non è nemmeno un
linguaggio) fino in quinta.  
Scusate, ma alle superiori non si fa mai C / C++ o cmq qualcosa al di fuori
del BASIC e del Pascal?
Saluti a tutti.

 Cmq che modo carino di selezionare la gente...
Il punto e' che allora programmare era un'attivita' cosi' astrusa, che
ci volevano persone gia' appassionate da problemi del genere...
Ciao,
Nicola

 linguaggio macchina?
In generale no. Nel particolare dipende.
EMG

autori di BSD
Pero' non l'ha fatto. Bene o male che sia non so di nessun S.O. di
massa fatto in C++ . 
C'era non so che rivoluzionario S.O. della Apple scritto in Objectve
C, ma non so quanto vicino sia al C++ questo linguaggio, ne che fine
abbia fatto quel S.O. (credo che sia collassato sotto la complessita',
ma forse mi sbaglio). Avevo dato un'occhiata alla documentazione di
"Lucifero"(o era "Inferno"?) un S.O. embedded della AT&T, che usava un
simil C++ di loro personale invenzione, ma ero rimasto piuttosto
perplesso (per le caratteristiche del linguaggio che sembrava creato
sul concetto che puntatore e' male). Linux e NT mi sembrano molto
legatati al C, almeno dalle voci che leggo qua e la'.
Insomma (mi sembra) che ci sono casi in cui il C++ viene guardato con
sospetto. Giusto o sbagliata che sia questa opinione.
-- 
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero
Recensioni Papere su 
http://www.komix.org

 equivalenti da questo punto di vista.
E anche  oggi Alex  ci insegna  qualcosa di nuovo.  Thnks, e'  sempre un
piacere leggere i tuoi post, si impara sempre (salvo quasi in automatico
tutt i tuoi articoli, non si sa mai ^_^).
-- 
 (o-  | c:\> win2000patch001.exe
 //\  | This Microsoft(c) patch fix all bugs present. All rigth reserved.
 V_/_ | Insert Linux boot disk to continue ... loading kernel ...
http://pinguin.linuxave.net
                      r.salmaso(at)
flashnet.it

 C, ma non so quanto vicino sia al C++ questo linguaggio, ne che fine
Non molto, ma non era NextStep a essere in Objective C?  Di S.O
(in parte) della Apple fatti in C++ ho presente Pink aka Taligent,
che se non sbaglio naufrago` sostanzialmente sulla base di dissidi
Apple/IBM/HP.
BeOS (se non sbaglio vicino anch'esso al naufragio) in che
linguaggio e` scritto?
Alex

 appartengono
FYI: C9X ha adottato anche questo dal C++.


Sei impazzito? 8-)
Magari vuoi anche che insegnino a navigare in internet?!?!?!
Comunque l'importante non è il linguaggio utilizzato, ma la mentalità
aperta che ti permette di imparare quello che ti serve al momento
opportuno... Certo che Basic e Pascal li devi conoscere come
l'italiano...
Luc.


Secondo quanto ho sentito dire da Grady Booch in una conferenza OS/400
e' stato riscritto in C++.
Ciao,
Nicola

Per provare siamo andati in aula multimediale e ci siamo resi conto che
eravamo in 3 su 29 a saper qualcosa di Internet, alcuni non sapevano
nemmeno che esistesse. Per altri invece Internet era il nome della rete
privata della Microsoft.
Cambiamo discorso per favore. 
Cmq qualche piccola dritta la si potrebbe anche dare.

 e` scritto?
So che il kernel e' in C, mentre tutte le altre librerie in C++.



E Hurd (l' S.O. della GNU) ?
Alla sua homepage dicono che è interamente OOP,
anche se non è specificato il linguaggio usato.
http://www.gnu.org/software/hurd/hurd.html
Manlio Perillo

Inoltre si arriva in quinta senza saper usare nessun browser internet.
Liceo scientifico P.N.I. ?

anche se non è specificato il linguaggio usato.
Boh, sara' programmato in modo OOP, ma il codice e' tutto C puro
(guardati i sorgenti e vedi che e' puro C).
--
 (o-  | Un OS per domarli, Un OS per trovarli,
 //\  | Un OS per ghermirli e nel buio incatenarli
 V_/_ | 
http://pinguin.linuxave.net
 r.salmaso(at)
flashnet.it

 Liceo scientifico P.N.I. ?
Per Non Informatici?
Ciao,
Nicola

 --
Un'altra occasione sprecata...

se qualcuno di essi fosse in C++.
La tua osservazione e' sostanzialmente giusta. Tieni conto che pare
che qualche astuto dirigente Microsoft abbia pensato a Java come
linguaggio del S.O. del futuro, e che per quel che ne so (ma mi
sbagliero) Novell NetWare 5 ha dentro il kernel la Java Machine.
Secondo la Sun il mondo embedded dovrebbe usare Java (e considero
questa una affermazione velleitaria di una ditta che non capisce le
esigenze del mercato embedded)
Se oggi c'e' gente che vuole mettere Java ovunque, perche' allora' non
avrebbero dovuto fare lo stesso con il C++. C'e' stato un momento
storico in cui il C++ e la programmazione ad oggetti era vista come la
soluzione della fame del mondo.
Per quel che ne so io per NT la domanda fu posta. Un parte della
grafica fu sviluppata in C++ (per quel che ne so). I tempi di sviluppo
furono colossali, e Cutler (se ricordo bene, e se quello che lessi
allora riportava la realta') pare affermo' che il C++ non era adatto a
simili progetti.
Fino a poco tempo fa nell'SDK si trovavano traccia di librerie
"clandestine" per la GUI e COM ad uso esclusivo dei programmatori C.
Il che, per me, accreditava le voci che fino a poco tempo fa la
Microsoft chiedesse sopratutto programmatori bravi in C e Assembler.
Le voci che ho sentito era che la Microsoft non credeva nel C++. 
Se scopro che NT a 64 bit, le cui prime voci me le ricordo nel 1995
sulle riviste di Taiwan, e' scritto in C++, ammetto sarei piuttosto
sorpreso. Posso crederlo "ad oggetti", ma sviluppato anche con un
linguaggio ad oggetti mi sembrerebbe andare contro il conservatorismo
imperante in certi ambienti.
Cambiamo parrocchia.
Linux quando e' nato (direi) non e' stato per "spaccare in due" il
resto dei S.O. con le prestazioni. La possibilita' di prendere in
cosiderazione il C++ per motivi di gusto personale, pulizia formale, o
di studio, poteva anche essere anche stata presa in considerazione
(per quel che ne so).
Comunque per rimanere sulla "sensazione" di pesantezza del C++,
domando (perche' non lo so) se KDE e GNOME (che come progetti sono
abbastanza recenti, e di dimensioni e complessita' non banali) sono
sviluppati sostanzialmente in C, o in C++.
Sempre sullo stesso tema, SQL Server, DB 2, Oracle in che linguaggio
sono scritti? E' una domanda. Sinceramente, non lo so.
Anzi direi di piu', i Data Base ad oggetti (Jashime, Poet,
ObjectStore) sono scritti "interamente" con linguaggi ad oggetti
(magari in C++), o sotto sotto usano il vecchio C?
Secondo Stroustrup la AT&T (lavora li' no?) usa il C++ da tantissimo
tempo, e non se ne e' mai pentita. Se non fosse che la Lucent e' un
spin off della AT&T, e che per Inferno o Lucifero che sia (che e' un
S.O. ) si sono ben guardati da usare sia il C++ che il C, perche'
"pericolosi" (letto sul loro sito).
PalmOS, Symbian sono S.O. recentissimi. Sono sviluppati in C++?
Io non lo so, ma chissa' perche' ho la sensazione che siano stati
scritti in C.
Il software della Playstation 2 e' scritto in C++?
++++
Sono un dilettante del C++ a certi livelli, e personalmente mi trovo
piu' a mio agio con il C se devo fare qualcosa di piccolo e veloce. Di
fatto (personalmente) uso (troppo) spesso il C++ come un C migliorato.
Pero' nella mia (personale) esperienza ho visto molte persone che non
si fidano troppo C++ su progetti di una certa dimensione. Il fatto che
non abbia incontrato molti programmatori da un che di casuale alle mie
osservazioni.
A volte mi chiedo se il C++ abbia veramente sfondato, o se per
complessita' oggettiva del linguaggio. o chissa' per che cosa, sia
ancora oggi un linguaggio di nicchia (seppure ampia). Vedo cosi' tanto
C in giro.
Non voglio essere polemico.


"pericolosi" (letto sul loro sito).
E si sono creati un loro linguaggio, che mi sembra sia senza
puntatori...



Forse non era il significato originale, ma rende molto bene l'idea :-)
Dopo 4 anni di Pascal solo io e un'altro mio compagno di classe abbiamo saputo
fare una cazzatina come il gioco della vita :-(

osservazioni.
La mia (breve) esperienza mi suggerisce un'altra osservazione.
Discutendo tempo fa con alcuni miei colleghi ho notato che quando si
parla di C++ molti si tirano indietro spaventati dalla sua complessita`
(e dire che un informatico la complessita` dovrebbe mangiarla come il
pane)... Salvo poi ritrovarsi lavorando in C a realizzare soluzioni 
astruse che in C++ implementi in 10 minuti con eleganza e semplicita`
guadagnando enormemente in comprensibilita` del sistema e sua 
conseguente manutenibilita`.
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

 Non voglio essere polemico.
Ma hai fatto fatica, confessa :-)
Ciao,
Nicola

controllo dell'hardware ecco che il C la fa ancora da padrone.
A tale riguardo potrebbe essere interessante la seguente lettura:
"Efficient C++"
Bulka, Mayhew
Addison Wesley, 1999
[From the Back Cover]:
Far too many programmers and software designers consider efficient C++ to be an
oxymoron. They regard C++ as inherently slow and inappropriate for
performance-critical applications. Consequently, C++ has had little success
penetrating domains such as networking, operating system kernels, device
drivers, and others.
Efficient C++ explodes that myth. Written by two authors with first-hand
experience wringing the last ounce of performance from commercial C++
applications, this book demonstrates...
Saluti
AB
--
-------------------------------------------------------------
   Andrea Baruzzo
   Via Circonvallazione, 26
   Muzzana del Turgnano (UD) - Italy
   e-mail: 
andrea....@ud.nettuno.it
   home: 
http://www.dimi.uniud.it/~baruzzo
-------------------------------------------------------------

Ma hai fatto fatica, confessa :-)
Sto sostenendo altrove una guerra santa sull'influenza dei Paperi
Disneyani sulla cultura italiana.
Non ho le forze (e i mezzi tecnici) per mantenere una discussione
filosofica sul C++. Il C++ e' per me meno importante di un Papero
Disney. Il C++ e' una materia interessante, ma non cosi' interessante.
Pero' alcune domande me le sono poste, e non ho trovato risposte
soddisfacenti.


 Che non ritengo un difetto, ma un dato di fatto con cui farei i conti.
Qualcuno potrebbe anche dire "io mi trovo bene con gli spaghetti-code
del Basic e non mi ci trovo affatto con la programmazione strutturata e
l'information hiding. E non lo considero un difetto". Come commenteresti
questo? Non ti sembrerebbe che questa persona sia troppo pigra per
aggiornarsi?
EMG

aggiornarsi?
Questo invece non l'accetto.
Mi sembra che tu dai per scontato quale e' la "via giusta", che se una
persona non e' arrivata alle tue convinzioni, e' perche' e' "pigra".
Conosco piu' di un programmatore che apprezza la possibilita' del VB
di non dichiarare le variabili. Io trovo la cosa terrificante. Pero'
questo non vuol dire che loro non conoscono i "vantaggi" di una
dichiarazione preventiva. Dicono che sono piu' le scocciature che i
vantaggi. Non approvo, ma la cosa finisce li'. Per me la versione 7
del VB che dovrebbe evitare i malefici cast automatici sara' un grande
passo avanti verso programmi migliori, ma resta un'opinione che
ritengo personale.
Io non ho mai detto di non conoscere il C++ (non che lo conosco molto,
infatti parlo poco in questo NG ), ne che non mi interessa conoscerlo
(se non leggerei i post di questo NG). Dico che non mi trovo con
progetti "interamente" ad oggetti. Qualcosa che ho semplificato nel
"sara' tutto quel che vuoi, ma alla fine preferisco usare printf() a
cout".
Pero' io vado anche oltre. Mi domando se il programmatore medio C++
non affronta certe tematiche con una tendenza alla complicazione
eccessiva. Che se vuoi possiamo tradurre nella domanda: "il
programmatore medio C++ saprebbe costruire un programma in puro stile
procedurale classico?"
Non problemi a pensare che un programmatore senza esperienza possa
pensare ad un programma di comunicazione seriale interamente ad
oggetti, basato esclusivamente sulla libreria standard, sopratutto per
gli stream. Mi e' anche capitato di lavorare su un malefico driver OPC
di una nota (nel settore) casa americana di SCADA. Terrificante.
Esteticamente una bella libreria, con il difetto di essere troppo
complicata, e di mediocri prestazioni.
Anche se il tono puo' sembrare polemico, sopratutto visto il posto in
cui lo dico, la mia domanda poi' tutta qui. Il C++ e' un linguaggio
che puo' tranquillamente sostituire il C, ma il C++ aiuta veramente i
programatori ad essere "bravi" programmatori?
Cerco di spiegarmi:
Io trovo il VB un ottimo linguaggio di programmazione (per i problemi
che deve risolvere). Sui progetti di grossi dimensioni e' terribile.
E' un linguaggio che aiuta il programmatore ad essere caotico. Non per
gli spaghetti code (su quello sei fermo al basic di tanti anni fa), ma
per impostazione filosofica. Che il contenitore tipo sia la famigerata
Collection in non e' possibile avere un controllo del tipo sugli
elementi, mi sembra che la dice lunga sull'aiuto al programmatore.
Il C ha di terrificante che in se e' semplice. Infatti e' anche
semplice sbagliare. Credo che nella mia vita di programmatore C il 90%
dei miei errori sia stato dovuto a buffer overrun, o a puntatori non
inizializzati. Pero' sui progetti grossi il sistema puo' reggere.
Credo che sia molto difficile entrare in un grosso progetto scritto in
C, perche' non e' un linguaggio che non ti aiuta a comprendere
l'essenza dell'architettura. Per questo credo che un linguaggio OO sia
decisamente meglio.
Il C++ e' un linguaggio decisamente ricco e complesso. Questo ti
obbliga a studiare, il che e' un bene. Pero' credo che molto del suo
successo sia dovuto al fatto che ti permette di mischiare stili, e di
fare cose "sporche" se lo reputi necessario. Cose molto C insomma.
Uno dei difetti dell'OO, e del C++ di riflesso, e' l'equivoco
dell'analisi. Si parte dal presupposto che in sede di studio e
formulazione delle specifiche sia possibile dominare il problema, e
che quindi, a partire da una buona analisi, sia possibile pensare ad
una buona architettura dello stesso. Cosa che non mi sembbra vera nel
caso reale. Mi sembra che nei progetti reali di una certa dimensione
avere una comprensione del problema sia molto difficile, anche perche'
non puo' studiare all'infinito, alla fine se vuoi portare a casa lo
stipendio devi fare un programma reale. La mia impressione, ma e' solo
una mia impressione, e' che sia possibile costruire un programma piu'
resiliente alle modifiche in uno stile misto di C/C++, che in C++ puro
(totalmente OO intendo). Troppe volte mi sono ritrovato con una
struttura di oggetti che mi sembrava all'inizio corretta, e alla fine
sbagliata. Le modifiche in corso d'opera al progetto mi sembrano piu'
facili in programmi scritti in stile C che non in C++.


 facili in programmi scritti in stile C che non in C++.
Credo sia esattamente il contrario. La moderna analisi OO intende
l'opposto della tua affermazione. Considera le varie fasi come cicliche
riconoscendo quindi che è impossibile avere ben chiaro il problema ad un
primo step e affidando a raffinamenti successivi lo sviluppo del
software. E il supporto che permette di ottenere questo senza pagare il
prezzo di una struttura troppo rigida da modificare è proprio la OOP.
EMG

 facili in programmi scritti in stile C che non in C++.
I protagonisti dell'XP, sulla base di esperienza molto estese e
significative, differiscono dalla tua opinione.  Fowler, il guru
del refactoring, idem.  Alcuni patiti di XP vanno matti solo per
i linguaggi dinamici (Smalltalk, Python), altri controbattono,
sempre a suon di tante validissime esperienze, che anche in C++
"refactor early, refactor often", "test it to death", e "do the
simplest thing that could possibly work", giusto per citare tre
dei principi ordinatori di XP, sono cruciali anche in C++.
Alex

 Disneyani sulla cultura italiana.
Vuoi dire che Quack non e' il tuo vero cognome? Mi fai pensare a "5" dei
Peanuts.
Ciao,
Nicola

 facili in programmi scritti in stile C che non in C++.
Questo e' un problema piu' di strategie di progettazione del software
che non di C++. Pero' non hai tutti i torti, quello che esponi e' a mio
avviso ad esempio il limite piu' grosso del libro "Object Oriented
Analysis & Design with Applications" di G. Booch, testo per altro pietra
miliare della letteratura OO. Booch sostanzialmente sembra dire che una
volta analizzato il dominio basta rappresentare relazioni IS-A con
ereditarieta', aggregazione con un bel membro dato, ecc. e paf! ecco il
disegno. Peccato che le applicazioni complesse necessitino spesso di
marchingegni che con il dominio applicativo c'entrano poco.
Ti consiglio al proposito di leggerti "Multiparadigm Design for C++" di
J. Coplien, libro eccezionale per quanto troppo stringato per la portata
delle cose che dice. Sostanzialmente Coplien ritiene che l'attivita' del
programmatore consiste nel realizzare una mappa tra lo spazio del
problema, ovvero il dominio applicativo, e lo spazio delle soluzioni,
ovvero il linguaggio e gli strumenti informatici prescelti; suggerisce
quindi di analizzare nel dettaglio le caratteristiche del dominio e
quelle degli strumenti per individuare attraverso le analogie il modo
migliore di effettuare l'associazione.
Ciao,
Nicola