Newsgroup: it.comp.os.linux.development
Titolo: Linux e C++ - il parere dei developers

Programmo da molti anni, anche se come autodidatta, del C++ ho adottato il
formalismo delle classi ma ho sempre schifato le librerie (a partire dalla
<iostream.h> per finire alle STL vector,list, etc...) dopo che avevo provato
a compilare un programmino che con le librerie standard si compilava in
tempi decisamente minori, ed anche l'eseguibile mi sembrava notevolmente
cresciuto, in quanto a prestazioni non mi sono messo a fare benchmark ma
posso immaginare.
Poiché il linux basa tutto il sistema sul linguaggio C (a parte le sezioni
critiche), mi domandavo quale politica adottassero  gli sviluppatori linux,
ed anche cosa ne pensaste voi a riguardo:  Si usa in generale il c++ nello
sviluppo del kernel o dei programmi di sistema in generale o si preferisce
l'ansi C ? E' preferibile usare le STL? Inficerebbe sulle prestazioni?
grazie per l'attenzione,
--
Alessio
----------------------------------------------------------------------------
-----------------
<Non č che ho paura di morire... č che non vorrei essere lģ
 quando questo succede  (Woody Allen)>
Nick: Runamok
membro del Zizzetope fun club
HomePage: 
http://space.tin.it/io/gdcap
 (quando funziona)
----------------------------------------------------------------------------
-----------------


uhm... mi pare che il kernel sia totalmente c (con un pò di asm), e in 
generale le applicazioni che trovi preferiscono il c, molta configurazione
è affidata a script perl o python, in ogni caso il c++ è comunque molto usato
ciao

 l'ansi C ? E' preferibile usare le STL? Inficerebbe sulle prestazioni?
Come hai notato anche tu, nel kernel non c'e` C++, ma solo C (+ asm).
Per le applicazioni: si va a gusti.
Io sto scrivendo un client IRC personale in GTK+ e C, ne ho appena visto
uno scritto in Python (sempre per GTK+), uno in Tcl/Tk e (diversi) in
Java.
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

l'ansi C ?
Per il Kernel si e' preferito il C anziche' il C++ per vari motivi tra
cui:
- quando hanno sviluppato la prima volta il compilatore c++ non era il
massimo
- il sorgente c++ e' generalmente piu' complesso del sorgente C e
diventava difficile trovare gente disposta a lavorarci
- ci sono (o c'erano al momento in cui l'hanno scritto) piu'
programmatori C che C++
Mi pare sia spiegato questo sulle faq del kernel pero' (mi pare ci
fosse anche una quarta motivazione che ora non ricordo pero').
IMHO il fatto che abbiano gia' implementato in C il paradigma della
programmazione a oggetti (che e' un grande punto di forza del C++),
rende meno allettante l'idea di passare al C++.
-- 
Mox
"Trust the programmer."
"Don't prevent the programmer from doing what needs to be done."
"Keep the language small and simple."
"Provide only one way to do an operation."

 rende meno allettante l'idea di passare al C++.
naaa, la semplicita' della gestionedi input, output, contenitori , 
programmazione generica coi template, dove li metti? considera che un 
ottimo kernel come quello di beos e' sviluppato "interamente" in c++ e 
asm...
-- 
Se l'appetito vien mangiando,
Figuriamoci a digiuno...
BW2K+2

asm...
Dici bene, sviluppato interamente e dall'INIZIO in C++ e ASM... sta'
tutto qui il problema.
I pregi del C++ (e i piccoli difetti che hanno tutti i linguaggi piu'
ad alto livello del C) vanno pesati con il costo per riadattare il
tutto da C a C++ (o qualsiasi altro linguaggio piu' ad alto livello
ovviamente).
Riadattare da C a C++ comporta un costo enorme di tempo solo per avere
un prodotto finito che non avra' delle enormi migliorie (perche' gia'
a suo tempo si erano impegnati per produrre in C parte di queste
migliorie... il kernel mi pare quasi interamente programmato a oggetti
o sbaglio?)
Io non farei un lavoro simile ora e a quanto pare per ora gli
sviluppatori la pensano cosi' (come si vede dai link all'inizio del
msg).


 msg).
e faresti bene: il kernel cosi' com'e' va + che bene, per doverlo 
riadattare tutto. forse il prossimo OS openSource :)


 (e g++ lo e')
Stiamo parlando di un kernel. Anche se  il g++3 ha fatto molti progressi
l'overhead  introdotto sarebbe  troppo grande. Anche  disabilitando rtti
ed  eccezioni il  codice  prodotto  dal g++  e`  piu`  lento (e  grosso)
dell'equivalente in C. Tornando  al tuo esempio, nel kernel  si evita di
allocare memoria dinamicamente se  non e` strettamente necessario. Tutti
i  container  andrebbero riscritti  per  adattarli  all'ambiente in  cui
opereranno, sarebbe un lavoraccio.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
"La mia teoria scientifica preferita e` quella secondo la quale gli 
 anelli di Saturno sarebbero interamente composti dai bagagli andati 
 persi nei viaggi aerei." -- Mark Russel

 cui opereranno, sarebbe un lavoraccio.
ti consiglio di rivederti la STL: si alloca memoria solo se necessario
std::vector<int>(5000) alloca solo la memoria che gli serve, in ogni 
implementazione che io conosca


dell'equivalente in C. 
Puo' darsi che sia il caso del g++ in particolare (anche se
lo ritengo molto strano), ma in generale il codice C++ non
e' ne' piu' lento, ne' piu' grosso dell'equivalente C.
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]

sezione algorithms, performance
Una piccola nota sui test presenti a quel link sulla STL.
- la strlen() e' piu' lenta del metodo size() perche' senz'altro il
template si tiene da qualche parte la dimensione, ovvio che ci metta
un attimo a dare il risultato... io stesso (per quando ignorante)
implemento cose simili quando creo un ADT.
- la strcat() risulta piu' lenta dell'operatore (anzi, metodo
associato all'operatore) "+=" per lo stesso motivo per cui la size()
veloce di strlen() (in tempo O(1) si trova la fine della stringa ed
esegue size(stringa2) operazioni di copia).
E' un esempio di un buon lavoro di creazione di ADT (la STL alla fine
e' solo una collezione di ADT+vari metodi) piu' che di ottimizzazine
di codice generato.
La differenza di prestazioni presente tra le funzioni del C e i metodi
della STL puo' venir facilmente emulata in C, soprattutto in un
progetto importante e delicato come il kernel di linux (e ci scommetto
la testa che se esiste un modo per risparmiare anche una sola
istruzione in una funzione l'hanno implementato :P).
Comunque quello che dice Kronos non e' totalmente infondato, si
appoggia anche all'intervista di Linus Torvald (vedi link nel mio
messaggio precedente).


 messaggio precedente).
Linus e' senz'altro un ottimo programmatore C, ma non ho mai visto una 
linea di codice c++ prodotta da lui... non so quanto possa essere valido 
il suo giudizio a riguardo, non trovi?


della STL puo' venir facilmente emulata in C
Non credere che sia cosi' facile.
Implementa il polimorfismo in C.
Tieni anche presente che gli algoritmi di una
implementazione della libreria standard del C++ (bada che
STL e lib std sono due cose diverse) non sono semplicissimi
e vanno messi in pratica nel modo giusto, se lo si vuol fare
in C.


 in C.
Verissimo, STL e libstd sono cose differenti, ma con linux (almeno fino 
al gcc 2.95.3 che uso io) di solito la lib std usa la STL di HP/SGI, 
basta vedere gli header di (ad esempio) stl_map.h, stl_set.h, 
stl_vector...


fosse anche una quarta motivazione che ora non ricordo pero').
La quarta e' che i compilatori C++ generano troppo codice asm nascosto
per poter darti tutte caratteristiche che ti mette a disposizione il
linguaggio. Per applicativi normali questo non e' importante mentre
per il kernel e' importantissimo sapere che codice asm verra'
generato!
Ciao
Mirko

 linguaggio. 
Nascosto? dev'essere proprio malefico, 
g++ miofile.cpp -S -o miofile.s
pensa, c'e' anche lo switch fverbose-asm : che  subdolo artificio!


La quarta e' che i compilatori C++ generano troppo codice asm nascosto
Non so che compilatore usi, ma, in generale, non e' cosi'.


 sezione algorithms, performance
In *teoria* il  C++ non introduce nessun overhead  rispetto al C. Strano
ma vero prima di postare o  fatto anche delle prove. Come ho specificato
mi  riferisco   *solo*  al   g++. Il  codice  generato   (con  -fno-rtti
-fno-exceptions -O2 -fomit-frame-pointer) e` fino  a 5 volte piu` grosso
del  corrispondente  in  C. Con  liste/vettori/stringhe  il  divario  di
prestazioni non  e` molto ampio, anche  se il C conserva  (con le stesse
opzioni) un piccolo  margine. Tirando in ballo gli  stream la situazione
cambia ed il codice C diventa 2/3 volte piu` veloce.
A  dire il  vero non  so dirti  come mai  le dimensioni  dell'eseguibile
crescano cosi` tanto:  l'assembly prodotto dal g++ proprio  non riesco a
seguirlo.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
No matter what you choose, you're still a luser.

 a seguirlo.
prova strippando e vediamo... a me vengono uguali per codici uguali
-- 
#include <stdio.h>/* (C) BW2K+2 This code is released under GPL 2+ */
int main(void){char c[]={98,108,97,107,119,111,108,102,64,116,105,
115,99,97,108,105,46,105,116,32,119,101,98,46,116,105,115,99,97,108,
105,46,105,116,47,98,108,97,107,119,111,108,102,0};printf("%s\n",c);}

 codice asm verra' generato!
Non mi risulta. Non mi risulta affatto. L'unica, e dico l'unica 
limitazione che hai all'interno del kernel rispetto ad altrove è 
se/dove/come/quando chiamare trap/interrupt/callgate. Quindi l'unica 
cosa che ti serve sapere è se una determinata funzione fa uso di una 
system call richiamandola tramite trap/interrupt/callgate, tutto il 
resto sono, come già detto, difetti, bug o limitazioni di compilatori e 
librerie esistenti
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 BW2K+2
--
====================
  Alex Vinokur
 
http://up.to/alexvn
 
http://go.to/alexv_math
    mailto:
ale...@bigfoot.com
    mailto:
ale...@go.to
  ====================


[snip]
Sorry. Here are valid links :
http://groups.google.com/groups?th=780d830ab3f5c04b
http://mygate.mailgate.org/mynews/comp/comp.software.measurement/3C84CF9B.AA99EFA8%40bigfoot.com
http://mygate.mailgate.org/mynews/comp/comp.software.measurement/3C8C7B97.E4B5CA9C%40bigfoot.com
http://mygate.mailgate.org/mynews/comp/comp.software.measurement/3C8DD296.A7304148%40bigfoot.com
http://mygate.mailgate.org/mynews/comp/comp.software.measurement/3C8C619E.D3F557D5%40bigfoot.com
http://www.delorie.com/djgpp/mail-archives/search.cgi?search=perfometer&since=&db=djgpp
http://groups.google.com/groups?th=12f55903796dc3fa
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=3512&lngWId=3


 > Also C/C++ Program Perfometer :
Thx, Alex.
I wonder wheter you actually read each programming related 
newsgroup, or you use just google ;)



Thanks.


Thanks.
I am using from time to time the following links :
http://groups.google.com/groups?q=+%22Alex+Vinokur%22&safe=off&scoring=d
http://www.graficalc.nl/google.html?adv=&frame=&hl=en&as_oq=Vinokur&as_epq=&as_eq=&as_ugroup=it.*&as_uauthors=&as_scoring=d
http://groups.google.com/groups?num=20&hl=en&newwindow=1&scoring=d&q=+efficiency+OR+performance+OR+complexity+insubject%3Avs+insubje
ct%3AC%2B%2B+OR+insubject%3ASTL&btnG=Google+Search
http://groups.google.com/groups?num=20&hl=en&newwindow=1&scoring=d&q=group%3A*C%2B%2B*+insubject%3Aperformance+OR+insubject%3Aeffici
ency+&btnG=Google+Search
http://groups.google.com/groups?num=20&hl=en&newwindow=1&scoring=d&q=C%2B%2B+insubject%3Afaster+OR+insubject%3Aslower&btnG=Google+Se
arch
Thanks again,


 prova strippando e vediamo... a me vengono uguali per codici uguali
Ovvio che compilando il codice C con g++ venga lo stesso risultato... Io
mi riferivo alle dimensione del codice C++.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Il dottore mi ha detto di smettere di fare cene intime per quattro.
A meno che non ci siamo altre tre persone.

 Io mi riferivo alle dimensione del codice C++.
posta un esempio di questi due tipi di codice e proviamo


 messaggio precedente).
Mi permetto di intervenire facendo notare come sia abbastanza insensato 
confrontare il costrutto del linguaggio con le singole implementazioni.
In questo senso do' perfettamente ragione al discorso di Kronos: se non 
altro per ogni chiamata a metodo, il C++ si porta dietro il puntatore 
*this, che e' comunque un overhead.
Supponiamo a questo punto di implementare in C e in C++ due strutture 
dati "stringa":
-- C
struct stringa {
	int len;
	char *ptr;
};
int Lunghezza (struct stringa *str)
{
	return str->len;
}
-- C++
class stringa {
 protected:
	int len;
	char *ptr;
 public:
	int lunghezza() { return len; }
};
in questo senso le due funzioni hanno, piu' o meno, le stesse 
prestazioni, a occhio. Forse, dico, forse, quella in C++ e' un po' meno 
performante, per il lavoro housekeeping necessario con il puntatore this 
e le varie VFT...
Naturalmente la cosa cambia se io utilizzassi implementazioni diverse: 
per paradosso, ribaltando il discorso di prima:
int stringa::lunghezza()
{
	for (int i=0; i < massimalunghezza && ptr[i] != 0; i++) ;
	return i;
}
ha prestazioni paragonabili alla strlen...
Just my 2 cents
-- 
HappyCactus - Registered Linux User #209744
http://utenti.tripod.it/happycactus
Made with 100% recycled electrons

 dati "stringa":
io non capisco: se A ha sia gli stessi che dei costrutti diversi da B e 
i costrutti propri di A realizzano meglio certe cose di quelli propri di 
B, perche' usare in A i costrutti di B?


ha prestazioni paragonabili alla strlen...
E' ovvio che se ricostruisco in C i meccanismi standard del
C++ (ti ricordo che la classe std::string e' predefinita in
C++) ottengo gli stessi risultati, ma nessun programmatore C
si costruisce la propria struttura "string" con tutta la
gestione che essa comporta: tutti usano le funzioni
standard.  Quindi, in questi casi e, a livello generale, il
codice C++ e' piu' veloce.


 
http://groups.google.com/advanced_group_search

 si costruisce la propria struttura "string" con tutta la
Talvolta vi sei obbligato per via della portabilita' e dell'interfaccia 
con il resto del mondo, IMHO...


 con il resto del mondo, IMHO...
ehmmm, mi faresti un esempio? 


con il resto del mondo, IMHO...
Niente affatto, IMHO...


rendono IMHO meno performante. tutto qui.
Ci risiamo: la tabella delle funzioni virtuali e' una
zavorra solo quando usi il polimorfismo.  Il puntatore
"this" te lo devi portare dietro anche in C.  


 ehmmm, mi faresti un esempio? 
Il fatto, vedi, e' che mi sembra piuttosto irrilevante tutto il discorso: 
dipende troppo dall'implementazione del compilatore, del programma (uno 
stesso algoritmo lo si puo' realizzare in infiniti modi), della cpu... 
insomma, forse si sta discutendo del sesso degli angeli.
-- 
Campagna europea per la pulizia in ics.*
Ogni post provocatorio o polemico verra' automaticamente killato 
assieme al suo poster.
http://www.google.com
 - 
http://groups.google.com/advanced_group_search

 angeli.
non credo proprio: se ritieni di essere obbligato dalll'interfaccia col 
resto del mondoe dalla portabilita' ad usare i vettori di char, mi sa 
che hai sbagliato libri di testo, come minimo


 che hai sbagliato libri di testo, come minimo
spiritosone. :)
non vedo che c'entri questo discorso. in certe particolari condizioni 
l'array char potrebbe non essere adeguato per le stringhe 
(<hint>unicode...</hint>)
In ogni caso, sara' il fatto che oramai il thread e' vecchio, sara' l'ora 
(sto cercando di capire qualche cosa di sto automake/autoconf), mi par 
che si stia andando un po' troppo al di fuori del seminato. Ribadisco, 
IMVHO non e' possibile fare un discorso generale, puo' essere che con gcc 
le differenze di prestazione siano irrilevanti, in ogni caso nulla mi 
convince che il codice c++ sia necessariamente piu' performante 
dell'equivalente diretto c...


 performante dell'equivalente diretto c...
"contro la fede, la ragione e' impotente"
la citazione ci sta bene, IMHO


 la citazione ci sta bene, IMHO
Si, senza dubbio applicabile _anche_ a te, visto che non hai voluto 
leggere bene cio' che ho scritto. Pazienza. Grazie per il piacevole 
scambio di opinioni. Chiudiamo qui l'OT, pero', ok? :)


 scambio di opinioni. Chiudiamo qui l'OT, pero', ok? :)
io ti ho fornito dei link, e IMHO non siamo OT, dato che siamo partiti 
dall'implemantare codice in C o in C++ e relativa efficienza, cmq nessun 
problema
