Newsgroup: it.comp.os.linux.sys
Titolo: kernel in c....

Il kernel e' scritto in c.....perche' non in c++?

 Il kernel e' scritto in c.....perche' non in c++?
perchè il C è più prestante... alcune parti sono in linguaggio
macchina, secondo te perchè non le hanno fatte in visual basic? :PP
g4b0

 Il kernel e' scritto in c.....perche' non in c++?
Ha più che altro a che fare con una concomitanza storica fra il progetto 
GNU di RMS, il fatto che non ci fosse un valido ambiente di siluppo C++, 
il fatto che il C++ non venisse insegnato come il C e che in C sei 
ancora un pò più libero... si è parlato varie volte di convertire in C++ 
almeno una parte del kernel Linux ma le difficoltà ora sono troppe 
rispetto ai probabili benefici.
Il perchè ha a che fare col processo di sviluppo del sistema operativo e 
la struttura del linguaggio e delle librerie di funzioni su cui si appoggia.

 macchina, secondo te perchè non le hanno fatte in visual basic? :PP
Certe cose le puoi fare solo in assembler, la velocità non è rilevante.

 Il kernel e' scritto in c.....perche' non in c++?
secondo me, ma e' una opinione personale, e' che il C e' piu'
strategico del C++. Un compilatore C e' piu' facile da sviluppare
e in un sistema nuovo per primo sara' disponibile il compilatore C,
poi seguira' il C++ e poi gli altri.
Per certi tipi di programmazione il C++ non da vantaggio, anzi...
impostare un kernel in OOP probabilmente lo rende inutilmente piu'
complesso, come anche le libc perche' tradizionalmente sono una collezione
di semplici funzioni o syscall, con prototipo vecchio stile, non
oggetti ereditabili. Forse un nuovo OS con specifiche diverse e innovative
rispetto a UNIX(R)/Linux/POSIX potrebbe essere riscritto in C++
(ma io non lo auspico)
I programmatori C++ hanno accesso anche al C mentre programmatori C
(come me) non sempre gradiscono, sono capaci di valorizzare, apprezzano
C++ quindi programmatori C > programmatori C++ in quanto li contengono.
Il C e' piu' semplice ed egualmente potente. Alcuni (come me ad esempio)
non ritengono neppure vantaggioso, specie quendo si scrive da 0 usare
OOP come invece potrebbe essero quando si usa un toolkit di cui
riutilizzare oggetti come ad esempio QT.
Ma sono tutte opinioni personali, ovvero "perche' io preferisco che il
kernel sia scritto in C"
Ciao
Roberto.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Il kernel e' scritto in c.....perche' non in c++?
Almeno una volta, su lkml capitava ogni tanto il dibattito relativo. In
sintesi, perchè anche se il C++ ha una gestione delle eccezioni che il C non
ha, si porta appresso sia una minore velocità che una maggiore variabilità
di risultato di codifica, ovvero se scrivi in C puoi immaginare quale codice
assembler generi e quindi ottimizzare ad alto livello, mentre se scrivi in 
C++ non ci riesci. 
Infine, il kernel è progettato ad oggetti, pensa alle union che vedi nel
codice, ad esempio nel VFS. Basta ed avanza per avere la flessibilità
necessaria, a costo nullo e con un controllo semantico minimo, rispetto ad
idee come le tabelle di metodi virtuali dei linguaggi ad oggetti.
-- 
Per rispondermi, togli il nome del poeta

 Il C e' piu' semplice ed egualmente potente.
Il C è più semplice del C++?
Avrei detto il contrario.
Essendo una evuluzione ho sempre pensato che il C++ fosse una 
'semplificazione' del C
(NOTA BENE: non voglio fare polemica, non conosco ne C, ne C++, è solo 
una curiosità nel caso volessi impararne uno)

 idee come le tabelle di metodi virtuali dei linguaggi ad oggetti.
Manca una riga:
che hanno un costo maggiore per una indirezione in più.


 una curiosità nel caso volessi impararne uno)
Concordo :)
David
- --
Linux Registered User #334216
Get FireFox! >> 
http://www.spreadfirefox.com/?q=affiliates&id=48183&t=1
Staff >> 
http://www.debianizzati.org
 <<
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.9.20 (GNU/Linux)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iD8DBQFFBr4j5sXXcRsFI+cRAgpwAKCndw+e0lM9sXItByjOBYFpePr5wACgk+pb
eJgiWqbQAMd9q6Yo7255ico=
=isJV
-----END PGP SIGNATURE-----

 
In C++ hai sia i char che String, in C hai solo char, ergo C e' piu' 
semplice di C++ (si, anche da imparare).
Alessandro.

 'semplificazione' del C
Il C e` piu` diretto del C++. La "semplicita`" credo si riferisca al modo
con cui il codice C viene tradotto in linguaggio macchina ed al modo con
cui il codice C++ venga letto, dal compilatore e dal programmatore.
Scrivendo in C e` possibile creare del bel codice, leggero ed efficace.
Pero` e` piu` facile fare errori (almeno di un certo tipo) e bisogna
scrivere molto codice, a volte complesso, per fare operazioni che
sarebbero quasi immediate in C++. Il C++ crea del codice molto grosso
e che prende molte risorse, soprattutto CPU.
Poi abbiamo il discorso delle librerie...
Esistono kernel scritti in C++. Ma tutti si sono rivelati troppo pesanti
e poco popolari, almeno quelli di cui ho sentito parlare.
Quanto sopra non per fare polemica. Io mi considero abbastanza neutrale,
anche se il C++ non posso usarlo, almeno non troppo.
Ciao,
-- 
        Roberto Divia`              Love at first sight is one of the greatest
Dep:PH Bat:53 Mailbox:C02110      labour-saving devices the world has ever seen
Route de Meyrin 385               ---------------------------------------------
Case Postale                                Phone:  
+41-22-767-4994
CH-1211 Geneve 23 CERN                      Fax:    
+41-22-767-9585
Switzerland                                 E-Mail: 
Robert...@cern.ch

 Alessandro.
Assisto a un fenomeno curioso, al quale non so' pero' dare spiegazione:
Linguaggi che ammettono algebra di oggetti di piu' alto livello che
il C es stringaconcatenata = stringa1 + stringa2; sono ritenuti piu'
semplici del C, ma io personalmente non apprezzo tale vantaggio. Conosco
anche il Perl eppure non riesco a fare tutto quello che faccio con il
C, perlomeno quando voglio farlo in maniera ottimizzata. Spesso in C
non e' necessario copiare una stringa, ma la si puo' puntare piu' volte
(dipende da cio' che si fa, certo) e per questi lavoretti di limaggio
cicli  macchina e risparmio memoria PER ME il C e' unico e insostituibile
e non sento NEPPURE LA NECESSITA? di GARBAGE COLLECTED (spesso la mancanza
di GC viene esposta come un deficit del C, ma negli opuscoli pubblicitari
di lang cone Java, Python ....). Io credo che chi programma in C per
sfruttarne le potenzialita' sempre imposta la gestione della memoria
(Almeno io lo faccio, anche per le piccole cose) e viene molto spontaneo.
Il C da valore a programmatori esperti (e io NON mi ci annovero) e il
gadget per i venditori di tools di sviluppo e' "rendi piu' produttivi
i tuoi programmatori, anche se sono delle teste di legno!!"
Io che scribacchio in C da parecchio ho spontaneo ottimizzare la memoria
e quando programmo in Perl spesso ho il rammarico di creare nuovi scalari
che poi la GC riciclera' sapendo concepire codice che lo renderebbe non
necessario in C. Mi piace molto il Perl e mi diverto come un pazzo, ma
certe esigenze di aver controllo del codice rimangono insoddisfatte.
Per me quindi non e' un vantaggio apprezzabile l' algebra delle stringhe.
Anzi al contrario. Non mi permette di comprendere la gestione della mem.
Comunque non voglio farmi prendere in discussioni filosofiche e tutto
quanto ho scritto e' la mia PERSONALISSIMA ESPERIENZA PERSONALE.
Ciao.


 il fatto che il C++ non venisse insegnato come il C
...il fatto che all'epoca il C++, pur esistendo da tempo, non fosse 
ancora standardizzato...
Alessandro.

 C++ quindi programmatori C > programmatori C++ in quanto li contengono.
Che tipo di software scrivi ?
Con quante persone lavori ?

 Assisto a un fenomeno curioso, al quale non so' pero' dare spiegazione:
Se quanto scritto e' ritenuto farneticante, pazienza, rimane comunque la
mia opinione, pur nel rispetto delle altre.
Io comunque  non scriverei qsort(3) in C++ e quindi neanche le syscall
e le funzioni libc.
ciao


 Con quante persone lavori ?
da solo :)


 e che prende molte risorse, soprattutto CPU.
Quindi la "semplicità" è vista prevalentemente dal processore.
Per il processore è piu facile eseguire codice compilato in C...
In termini di velocità, però, di che cosa si sta parlando?
Questione di pochi millesimi di secondo credo...
Sempre visto dal lato del processore poi.
Non oso immaginare, quindi, che velocità possa avere un programma 
scritto in Visual Basic...
Insomma, tutto dipende da cosa bisogna fare.
Se si ha bisogno di velocità ed efficacia ai max livelli (come ad 
esempio un kernel di un sistema operativo) è preferibile il C.
Se invece la velocità non è un problema, il c++, visto dal lato 
programmatore potrebbe essere migliore in quanto certe cose sono più 
veloci da realizzare e non è necessario reinventare la ruota in C tutte 
le volte poichè in C++ è già pronta.

 complesso,
Il kernel è scritto con criteri OO.
Luca
-- 
Home: 
http://kronoz.cjb.net
"Ricorda sempre che sei unico, esattamente come tutti gli altri".

 il kernel sia scritto in C"
Io ho usato entrambi, ma in prevalenza il C. E lo preferisco perche`
e` piu` 'veloce' scrivere in C che in C++. Certo che se dovessi
affrontare un lavoro di squadra, opterei per il C++. O no ? :-)
Ciao,
-- 
--> x3m <--

 Sempre visto dal lato del processore poi.
La differenza di velocita` tra due applicativi equivalenti non si misura
in millisecondi ma piuttosto nella differenza in tempo di elaborazione
e in uso delle risorse (CPU, memoria, librerie).
Per fare un esempio, ho un applicativo C che scrive su disco a 80 MB/s
usando il 40% di un dual Xeon 2.4 GHz. Un applicativo equivalente in C++
scrive a 40 MB/s per un uso CPU superiore al 90%.


 scrive a 40 MB/s per un uso CPU superiore al 90%.
Ok, ho capito. grazie per la risposta esaustiva.

 quanto ho scritto e' la mia PERSONALISSIMA ESPERIENZA PERSONALE.
Certo anche per me... ma dallo scambio di idee (se onesto) nascono cose 
positive

 Anche in C++ (puoi anche usare le "stringhe C-style")
ma allora perchè usare il c++ se programmi come in C? ^_^
ciao
BLADELA
-- 
"Resistance is Chuck Norris"

 Col compilatore GNU ottieni quasi sempre lo stesso codice.
Sicuro? guarda con questo programmino...
# wc -l text.c
308 text.c
# gcc -S -O3 text.c
# ls -l text.s
-rw-r--r-- 1 scola users 22793 Sep 13 14:15 text.s
# g++ -S -O3 text.c
# ls -l text.s
-rw-r--r-- 1 scola users 29451 Sep 13 14:15 text.s
compilando lo stesso programma con gcc o g++, il secondo genera il 30% 
di codice macchina in piu'...

 ma allora perchè usare il c++ se programmi come in C? ^_^
Il C++ è un superinsieme del C, non capisco la domanda e non credo che 
quello che tu voglia intendere giusitifichi l'abbondono delle 
significative migliorie del C++.
Se trovi un collo di bottiglia nella tua applicazione puoi anche mettere 
un pò di in-line assembler nel tuo codice C++, è una cosa che ho visto 
fare più volte in C++ e ancora di più in COBOL

 di codice macchina in piu'...
Temo che ti manchi qualche flag

 significative migliorie del C++.
intendo che se programmi a oggetti, devi farlo per intero, un misto a mio
avviso sarebbe solo un insulto alla leggibilità


 veramente).
Quindi alla fine (come ho scritto io in un vecchio post), le differenze 
di velocità/ottimizzazione tra codice C e C++, nelle macchine di oggi 
(Pentium 4 3200 con svariati GB di RAM) sono pressochè inesistenti.
O meglio, la differenza non si nota a tal punto da dover 'obbligare' 
l'utilizzo di codice C anzichè C++ nella stra maggioranza dei casi...

 Se trovi un collo di bottiglia nella tua applicazione
Il kernel di Linux è parassitario, quindi se hai un rallentamento dovuto
all'uso di un linguaggio piuttosto di un altro hai un _grosso_ problema di
prestazioni.


 avviso sarebbe solo un insulto alla leggibilità
Puoi progettare ad oggetti e programmare in C. Il kernel è fatto così.


 Puoi progettare ad oggetti e programmare in C. Il kernel è fatto così.
si, ok, quello che intendevo io è : programmi(intendo proprio di codice) a
oggetti e poi usi una parte non a oggetti? mi pare francamente stupido in
quanto inficia un po' tutto, ma è un opinione senza esperienza lavorativa
diretta, quindi vale ben poco ^_^


 oggetti e poi usi una parte non a oggetti? 
Se le parti sono funzionalmente separate, e quindi la parte non ad oggetti è
quella dove le prestazioni (ad esempio) sono critiche, si tratta di un
approccio anche sensato. Per moltissimi anni, il codice fiscale degli
italiani era calcolato da una porzione di codice in assembler, annegata in
un mondo di COBOL.



Il flag "-O3" attiva l'espansione sistematica in linea delle routines.
Prova a compilare senza ottimizzazione o - al limite - con "-O".
Ci sono parecchi casi documentati di programmi che con "-O3" (e anche
con "-O2") diventano troppo grossi e vanno piu` piano (l'espansione
non serve a niente: le procedure non vengono usate o girano una volta
sola).


 Prova a compilare senza ottimizzazione o - al limite - con "-O".
# gcc -S text.c
# ls -l text.s
-rw-r--r-- 1 scola users 21109 Sep 14 12:02 text.s
# g++ -S text.c
# ls -l text.s
-rw-r--r-- 1 scola users 27338 Sep 14 12:02 text.s
sempre 30% in piu'...

 un mondo di COBOL.
ma (almeno da come l'ho capita io) sarebbe comunque una struttura a
oggetti, visto che tu usi la classe X, che ad esempio gestisce le
stringhe, e queste per migliorare le prestazioni  vengono gestite in
assembler
quello che trovo sbagliato è che tu DIRETTAMENTE gestisci le stringhe
senza gli oggetti, lo trovo CONCETTUALMENTE sbagliato
nel primo caso puoi comunque ottimizzare la gestione, e lo devi fare una
sola volta, nel secondo avresti imho un papocchio ogni volta, dovendo
ottimizzare tutte le singole istanze di char*
ovviamente è una questione più "filosofica" che altro, poi ognuno adatta
la soluzione al problema e alle risorse


 ottimizzi veramente).
Si, ma considerando che "il tuo secondo programma" (un input da console
ed una stampa di tale input) occupa in memoria quasi 2Mb in Python, e
quasi 20Mb in java, beh, permettimi di farmi rodere un po' il culo
(soprattutto se penso che la versione compilata in FreePascal occupa
quasi 500Kb e, se vogliamo essere sempre piu' pignoli, anche questa e'
una cifra che puo' essere considerata alta)...
Enrico

 una cifra che puo' essere considerata alta)...
Le differenze fra linguaggi compilati, interpretati o ibridi come Java 
sono implicite e certamente vanno considerate (a questo servono i 
programmatori): se devi caricare la VM che ti tiene 20MB di RAM per la 
tua applicazione che fa mille cose può tranquillamente avere senso, sia 
nell'economia di quel programma sia nel fatto che usi un solo linguaggio
CMQ, IMHO, 20MB 5 anni fa potevano essere un problema ma ora che sei che 
  entro la fine del 2007 (se sviluppi un'applicazione è probabile che ci 
voglia un pò per finirla, provarla etc) ci saranno DDR3 ad una frequenza 
smodata con taglio minimo da 512MB ma probabilmente le vedremo già da 
subito due moduli da 1GB

 subito due moduli da 1GB
Questo se conti solo i PC.
Dimentichi che Linux gira su un sacco di cose.
Sul mio Zaurus un programma che usa 2 Mb mi va bene, uno che ne usa 20 no,
visto che ha 64 Mb di RAM e che 40 sono occupati dal S.O. e dalla GUI.
Per questo evito Java come la peste, ma Python lo sopporto, anche se
preferisco le applicazioni compilate da 2-300 Kb.
Bye.