C versus C++ in Linux
Christian Helmbold
soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
nicht C++ geschrieben. Ist das einfach historisch so gewachsen, oder
gibt es einen Grund dafür, dass C statt C++ verwendet wird?
Vielleicht kann ja mal jemand einen Blick in seine Kristallkugel werfen ;-)
Christian
Bernhard Lutzer
> Hallo,
>
> soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
> nicht C++ geschrieben.
Korrekt. Nur einige Zeilen sind Assembler.
> Ist das einfach historisch so gewachsen, oder
> gibt es einen Grund dafür, dass C statt C++ verwendet wird?
Nein. In C++ brauchst du dynamische Speicherverwaltung, die es in reinem
Maschinenencode den man mit C erzeugen kann nicht gibt. Es ist also gar
nicht möglich.
>
> Vielleicht kann ja mal jemand einen Blick in seine Kristallkugel werfen
> ;-)
>
> Christian
MFG
Bernhard
--
Vermisst du die Signatur?
Immo 'FaUl' Wehrenberg
> soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
> nicht C++ geschrieben. Ist das einfach historisch so gewachsen, oder
> gibt es einen Grund dafür, dass C statt C++ verwendet wird?
Warum sollte man C++ verwenden?
FaUl
end
This article does not support incompatible and broken newsreaders.
--
we work in jobs we hate, so we can buy shit we dont need
to impress people we dont like
Immo 'FaUl' Wehrenberg
> Nein. In C++ brauchst du dynamische Speicherverwaltung, die es in reinem
> Maschinenencode den man mit C erzeugen kann nicht gibt.
Huch?
FaUl
end
This article does not support incompatible and broken newsreaders.
--
ATM ist da schon eine Schicht, die ernsthafte Chancen hat, von Al Quaida
Air heimgesucht zu werden.
[Detlef Bosau in dcounm]
Helmut Hullen
Du (christian.helmbold) meintest am 10.03.03:
> soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in
> C und nicht C++ geschrieben. Ist das einfach historisch so
> gewachsen, oder gibt es einen Grund dafür, dass C statt C++
> verwendet wird?
Und wenn schon - wofür ist das wichtig?
Viele Grüße!
Helmut
Hans-Stefan Suhle
> Und wenn schon - wofür ist das wichtig?
>
> Viele Grüße!
> Helmut
Eieieiei! Du bist aber heute wieder auf der Höhe ;-) Lass die Kinder doch
spielen.
HSS
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?
Christian Helmbold
Immo 'FaUl' Wehrenberg schrieb:
> Warum sollte man C++ verwenden?
Im ein oder anderen Fall könnte es mit Objektorientierung vielleicht
einfacher / effizienter zu entwicklen sein.
Christian
Christian Helmbold
> Und wenn schon - wofür ist das wichtig?
Interessiert mich einfach mal.
Christian
Kai Großjohann
> Nein. In C++ brauchst du dynamische Speicherverwaltung, die es in reinem
> Maschinenencode den man mit C erzeugen kann nicht gibt. Es ist also gar
> nicht möglich.
Ich dachte, der Linux-Kernel hätte kmalloc?
--
A preposition is not a good thing to end a sentence with.
Christian Helmbold
Hans-Stefan Suhle schrieb:
> Eieieiei! Du bist aber heute wieder auf der Höhe ;-) Lass die Kinder doch
> spielen.
Leidest du unter Troll-Paranoia?!
David Kastrup
> Christian Helmbold wrote:
>
> > Hallo,
> >
> > soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
> > nicht C++ geschrieben.
>
> Korrekt. Nur einige Zeilen sind Assembler.
>
> > Ist das einfach historisch so gewachsen, oder
> > gibt es einen Grund dafür, dass C statt C++ verwendet wird?
>
> Nein. In C++ brauchst du dynamische Speicherverwaltung, die es in
> reinem Maschinenencode den man mit C erzeugen kann nicht gibt. Es
> ist also gar nicht möglich.
Was für ein hanebüchener Blödsinn. Selbstverständlich kann man auch
mit C++ nichts anstellen, was nicht mit Maschinencode realisiert
werden müßte. Di dynamische Speicherverwaltung existiert auch in C.
Selbst wenn Du damit meinst, daß man nicht malloc und free direkt
verwenden wollte: wie C++ seinen Speicher alloziiert, kann man durch
Überladen des new-Operators leicht ändern.
Die Gründe für C sind vielfach:
a) komplexe Objekte in C++ sind weniger berechenbar in ihren
Laufzeitanforderungen.
b) g++ ist erheblich langsamer und fehlerträchtiger als gcc
c) der erzeugte Code ist auch schlechter
d) die Laufzeitanforderungen sind komplexer (Exceptions im Kernel?!?)
Es hat eine Zeit gegeben, als der Linuxkernel noch dahingehend
überprüft wurde, daß er auch durch den C++-Compiler läuft. Das ist
dann irgendwann mangels Interesse geknickt worden.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Olaf Kaluza
>nicht C++ geschrieben. Ist das einfach historisch so gewachsen, oder
>gibt es einen Grund dafür, dass C statt C++ verwendet wird?
Weil C besser ist. Weiss doch jeder.
Olaf
p.s: Ich habe noch Chips da. :-)
--
D.i.e.s.S. (K.)
Alexander Bartolich
> [...]
> Im ein oder anderen Fall könnte es mit Objektorientierung vielleicht
> einfacher / effizienter zu entwicklen sein.
Man kann auch in C recht gut objektorientiert programmieren.
Virtuelle Methoden lassen sich zu Fuss mit Funktionszeigern
implementieren.
Objekte müssen auch nicht durch Zeiger repräsentiert werden, man
kann statt dessen auch Integer nehmen, wie bei Gerätenummern und
Dateideskriptoren.
Ein sehr erfolgreiches Beispiel für objektorientiertes Design in
C ist Apache.
--
I peace on your war.
Hilmar Preuße
IIRC wurden in der FAQ zur LKML ein paar Sätze dazu verloren.
H.
--
Signaturen sind wie Frauen: Man findet selten eine Vernuenftige.
-- gesehen in at.linux
Yoon Soo
ja, ich würde sagen, dass es einfach 'historisch' so gewachsen ist.
Linus wollte ja ursprünglich u.a. seinen 386er Hardware besser
kennenlernen, und da bietet sich (imho) Assembler+C einfach an.
Ob es besser oder schlechter ist, einen Kernel in C++ zu
programmieren,ist eine Frage, die sich gar nicht so eindeutig
beantworten lässt.
Ich habe mal vor einiger Zeit eine ähnliche frage in aod diesbezgl
gestellt (bzw. das OP kam von jemand anders) und die Quintessenz an
die ich mich erinnere, ist, dass es keinen richtigen Grund gibt,
bevorzugt in C++ zu programmieren (wir sprechen natürlich nur über
Kernel-programmierung) ausser der persönlichen Vorliebe und in welcher
Sprache man sich besser zurechtfindet. Es gibt aber auch
(Hobby-)Kernel, die in C++ geschrieben sind..
Falls du an dem Thread und Antworten interessiert bist:
gruss
yoon
PS. afaik wird bald auch Perlcode im Linuxkernel enthalten sein.
Rainer Weikusat
> Ob es besser oder schlechter ist, einen Kernel in C++ zu
> programmieren,ist eine Frage, die sich gar nicht so eindeutig
> beantworten lässt.
Diese Frage läßt sich sogar ausgesprochen einfache beanworten: Es ist
besser, einen kernel zu programmieren, als über Programmiersprachen
daherzuschwallen.
Gerhard Häring
Ich hab mal gelesen, dass schon mal Versuche gemacht wurden, den Kernel mit
g++ kompilierbar zu machen. Das Ganze soll aber (wg. Bugs im g++, nehme ich
an) nicht funktioniert haben. Die entspr. Diskussion sollte auf der LKML zu
finden sein.
-- Gerhard
Yoon Soo
was sagt denn mein menu.lst dazu? hmm, mal schauen..
...
title MyOs
root (hd1,2)
kernel /home/yunico/mykern/system.elf.gz root=/dev/hdb3
Was meinst du denn, wie gross die Zahl derer ist, die in ihrer Freizeit
an einem kernel arbeiten? Im Grunde ist es nicht mal mehr eine Erwähnung
wert..(gähn, du auch?)
Gerhard Häring
> Hallo,
>
> soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
> nicht C++ geschrieben. Ist das einfach historisch so gewachsen,
Ja.
> oder gibt es einen Grund dafür, dass C statt C++ verwendet wird?
Ja. Und es ist eine FAQ. http://www.tux.org/lkml/#s15-3 sollte diese Frage für
den Linux-Kernel erschöpfend beantworten.
-- Gerhard
Mathias Goldau
> Christian Helmbold schrieb:
>> [...]
>> Im ein oder anderen Fall könnte es mit Objektorientierung vielleicht
>> einfacher / effizienter zu entwicklen sein.
>
> Man kann auch in C recht gut objektorientiert programmieren.
> Virtuelle Methoden lassen sich zu Fuss mit Funktionszeigern
> implementieren.
>
> Objekte müssen auch nicht durch Zeiger repräsentiert werden, man
> kann statt dessen auch Integer nehmen, wie bei Gerätenummern und
> Dateideskriptoren.
1. Wartbarkeit! Da sehe ich hier schon mal schwarz.
2. Man KANN auch alles funktional machen :-) D.h. wenn man will kann man mit
jeder Programmiersprache sogar Assemlber objektorientiert Programmieren.
Aber in C++ geht es doch schon besser, (mich auf C# für Linux freuend :-)
> Ein sehr erfolgreiches Beispiel für objektorientiertes Design in
> C ist Apache.
auch die aktuellen Versionen? Hätt ich nicht gedacht. Egal ist wohl eher ein
Programmiersprachliches Thema, und passt hier nicht so recht.
mathias
--
mail: fun...@web.de
David Kastrup
> 2. Man KANN auch alles funktional machen :-) D.h. wenn man will kann
> man mit jeder Programmiersprache sogar Assemlber objektorientiert
> Programmieren.
> Aber in C++ geht es doch schon besser,
Nein. C++ fehlt zur ernstzunehmenden Objektorientierung ein Konzept
von Messages/Rendezvous/Continuations. Es bietet keine Möglichkeiten
objektbasierter Ablaufkontrolle.
In Assembler hingegen hat man eine Vielzahl von Möglichkeiten, solch
grundlegende Konzepte der Objektorientierung zu implementieren.
Kai Großjohann
> 2. Man KANN auch alles funktional machen :-)
Warum erwähnst du jetzt plötzlich funktionale Programmierung?
Ein Kernel in Haskell. Wär ja auch nicht schlecht.
Mathias Goldau
David Kastrup wrote:
(da kann man ja fast gleich seine eigene OOSprache machen.)
Ja es ist vielleicht manchmal besser auf einige Sachen zu verzichten und
dafür mehr die vorimplementierten Komponenten einer Sprache zu benutzten,
anstatt das (ganze) Rad neu zu erfinden (einschließlich all seiner Kinder
:-)) Das C++ keine 'ernstzunehmende' OOSprache ist steht hoffentlich außer
Frage.
mathias
--
mail: fun...@web.de
Mathias Goldau
> Mathias Goldau <fun...@web.de> writes:
>
>> 2. Man KANN auch alles funktional machen :-)
>
> Warum erwähnst du jetzt plötzlich funktionale Programmierung?
Na ich hätt auch logikorientierte nehmen können. Man kann zeigen das alles
was man imperativ programmieren kann auch funktional geht. Nur mit einem
heiden Aufwand eben. Einfache sachen wie schleifen müssen durch rekursion
ersetzt werden, die manchmal enorm hässlich werden kann.
Es war mehr so ne Aussage wie: "Theoretisch (und auch praktisch) kann ich
mit $Programmiersprache alles machen was ich mit $Programmiersprache auch
kann." Und wenn ich auch einen riesen Aufwand betreibe. Manchmal gehen
Sachen aber in einer PS konfortabeler als in einer anderen, und ich bin mir
sicher das C++ in Bezug auf OOP *besser* als C ist. Und wenn OOP für einen
Kernel gut zu gebrauchen wäre, dann wäre C++ sicher die bessere Wahl.
> Ein Kernel in Haskell. Wär ja auch nicht schlecht.
Haskell kenn ich nicht (lass mich raten funktional :-)?)
In was ist eigentlich der HURD-Kernel geschrieben?
--
mail: fun...@web.de
David Kastrup
> In was ist eigentlich der HURD-Kernel geschrieben?
Emacs Lisp.
Alexander Bartolich
>> [...]
>> Objekte müssen auch nicht durch Zeiger repräsentiert werden, man
>> kann statt dessen auch Integer nehmen, wie bei Gerätenummern und
>> Dateideskriptoren.
>
> 1. Wartbarkeit! Da sehe ich hier schon mal schwarz.
Das ist nur eine Frage der Grössenordnung, also wie viele Klassen
und Objekte es gibt.
"Richtige" OO-Sprachen erziehen zur Verwendung möglichst vieler
kleiner, kurzlebiger Objekte. Das erfordert eine gute Speicherver-
waltung und verschleiert den Zusammenhang zwischen Code- und Laufzeit-
komplexität. Was in C++ sehr einfach aussieht, kann in Wirklichkeit
sehr kompliziert und ineffizient sein.
In einem Virtual-Memory-Betriebssystem ist es ausserdem sehr wichtig,
dass Kernel-Funktionen nicht unabsichtlich auf nicht gemappten
Speicher zugreifen. Eine Speicherseite hat auf i386 4 kB, und das ist
die grundlegende Einheit aller Speicheranforderungen/Freigaben.
Die Fragmentierung und der Nichtdeterminismus vieler kleiner new/delete
ist untragbar.
Ausserdem funktioniert der Polymorphismus in C an sich gut. Unter
Linux kann hinter einem Dateideskriptor entweder Pipe, Socket (Unix/
TCP/UDP), Gerätedatei, /proc-Datei oder eine reguläre Datei stecken.
Die Schnittstelle (in Userspace und Kernelspace) ist dabei immer
die selbe, d.h. write(2) muss man sich eigentlich als virtuelle
Methode eines File-Objekts vorstellen.
IMHO haben die wenigsten Verfechter von OO das Konzept an sich
verstanden, sondern betreiben nur Syntaxfetischismus.
> [...]
> Aber in C++ geht es doch schon besser, (mich auf C# für Linux freuend :-)
Interessanterweise ist C++ innerhalb des OO-Lagers ein Paria.
Alle anderen (Smalltalk, Delphi, Java, Python, Ryby) halten statische
Typisierung, fehlenden Garbage-Collector und den Template-Dschungel
für untragbar.
C++-Missionare haben sehr viel mit den "Linux-8.1"-Anwendern gemein.
Kai Großjohann
> Nein. C++ fehlt zur ernstzunehmenden Objektorientierung ein Konzept
> von Messages/Rendezvous/Continuations. Es bietet keine Möglichkeiten
> objektbasierter Ablaufkontrolle.
Wasisndas?
Kai Großjohann
> Kai Großjohann wrote:
>
>> Mathias Goldau <fun...@web.de> writes:
>>
>>> 2. Man KANN auch alles funktional machen :-)
>>
>> Warum erwähnst du jetzt plötzlich funktionale Programmierung?
>
> Na ich hätt auch logikorientierte nehmen können. Man kann zeigen das alles
> was man imperativ programmieren kann auch funktional geht. Nur mit einem
> heiden Aufwand eben. Einfache sachen wie schleifen müssen durch rekursion
> ersetzt werden, die manchmal enorm hässlich werden kann.
Mir ist unklar, was an Rekursion hässlich sein soll.
Und ich dachte immer, Schleifen gibt's auch in funktionalen
Sprachen. Hm.
> Es war mehr so ne Aussage wie: "Theoretisch (und auch praktisch) kann ich
> mit $Programmiersprache alles machen was ich mit $Programmiersprache auch
> kann." Und wenn ich auch einen riesen Aufwand betreibe.
Ja, in der Welt der Turingmaschinen mag das sein. Aber beim Kernel
geht's ja auch (u.a.) darum, zum richtigen Zeitpunkt den richtigen
Wert in das richtige Register zu pröppeln.
Und wenn die Sprache keinen Weg kennt, Dinge in Register zu pröppeln,
haste verloren.
Diese Denkweise ist stark zustandsbehaftet: was in dem Register
steht, ist der momentane Zustand des Rechners.
Zustandsabhängigkeit ist aber nun gerade das, was funktionale
Programmierung vermeiden will...
Wer weiß einen Ausweg?
> Manchmal gehen Sachen aber in einer PS konfortabeler als in einer
> anderen, und ich bin mir sicher das C++ in Bezug auf OOP *besser*
> als C ist. Und wenn OOP für einen Kernel gut zu gebrauchen wäre,
> dann wäre C++ sicher die bessere Wahl.
Flame on!
>> Ein Kernel in Haskell. Wär ja auch nicht schlecht.
> Haskell kenn ich nicht (lass mich raten funktional :-)?)
Genau. Ich kenne Haskell aber auch nicht. Vielleicht hätte ich ML
sagen sollen...
> In was ist eigentlich der HURD-Kernel geschrieben?
C.
David Kastrup
> David Kastrup <d...@gnu.org> writes:
>
> > Nein. C++ fehlt zur ernstzunehmenden Objektorientierung ein Konzept
> > von Messages/Rendezvous/Continuations. Es bietet keine Möglichkeiten
> > objektbasierter Ablaufkontrolle.
>
> Wasisndas?
Sowas wie ein logischer Thread für ein Objekt, aber unter Kontrolle
von Compiler und Optimizer.
"Message Passing" hat was damit zu tun.
Wenn ich auf ein Signal/Message/Was auch immer in C++ reagiere, lande
ich immer am Anfang einer Prozedur/Methode.
Wenn man etwa ein Protokoll implementiert, besteht das aus Senden und
Empfangen von Zeichen in einer sinnvollen Abfolge. Ich könnte einem
Kommunikationsobjekt in C++ etwa Methoden/Funktionen mitgeben, um ein
einzelnes Zeichen zu senden/zu empfangen. Kann ich jetzt zwei solche
Objekte miteinander kommunizieren lassen, um zu überprüfen, ob das
funktioniert? Das gibt C++ nicht her. Da muß ich dann schon auf
Betriebssystemebene oder Threads runtergehen, obwohl hier eigentlich
nur komplett synchrone Ablaufwechsel gefragt sind.
André Pönitz
> "Richtige" OO-Sprachen erziehen zur Verwendung möglichst vieler
> kleiner, kurzlebiger Objekte. Das erfordert eine gute Speicherver-
> waltung und verschleiert den Zusammenhang zwischen Code- und Laufzeit-
> komplexität. Was in C++ sehr einfach aussieht, kann in Wirklichkeit
> sehr kompliziert und ineffizient sein.
Nun waere "richtige OO" tatsaechlich nicht die typische Anwendung fuer C++
in Kernelnaehe (zumal C++ weder "richtiges OO" ist, noch "richtiges OO" als
solches besonders wuenschenswert ist)
Kapselung von haeufig gebrauchten Idiomen (Wieviele Listen werden
handverzeigert? Wieviel Typsicherheit bekommt man, wenn alles ein typedef
auf int ist?) waere dagegen durchaus eine Option.
Und nein, das Ergebnis muss nicht langsamer sein oder Speicherplatz
kosten.
> C++-Missionare haben sehr viel mit den "Linux-8.1"-Anwendern gemein.
Danke.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Rainer Weikusat
> Rainer Weikusat wrote:
> > Diese Frage läßt sich sogar ausgesprochen einfache beanworten: Es ist
> > besser, einen kernel zu programmieren, als über Programmiersprachen
> > daherzuschwallen.
>
> Freizeit an einem kernel arbeiten? Im Grunde ist es nicht mal mehr
> eine Erwähnung wert..(gähn, du auch?)
Warum sollte ich auf diesen bescheuerten Gedanken kommen?
Yoon Soo
<weik...@students.uni-mainz.de> wrote:
vielleicht weil du so daherredest, als ob es etwas tolleres sei, einen
kernel zu programmieren, als darüber zu reden,oder daherzuschwallen?
Manche Leute laufen in ihrer Freizeit hinter einem Ball her, und ich
würde es nicht unbedingt als bescheuert bezeichnen. Du rettest also in
deiner Freizeit nur bedrohte Tiere oder tust sonst was nur
nicht-bescheuertes? Oder wieso kannst DU darüber urteilen, wie
sinnvoll die Freizeitgestaltung anderer menschen ist? Aber Toleranz
und soziale Kompetenz scheinen eh nicht zu deinen Stärken zu gehören.
Aber lieber du bezeichnest das, was ich in meiner Freizeit mache als
bescheuert als wenn du auf die Idee kämest, wir könnten was gemeinsam
in meiner knappen Zeit unternehmen.
yoon
Mathias Goldau
Kai Großjohann wrote:
>> Na ich hätt auch logikorientierte nehmen können. Man kann zeigen das
>> alles was man imperativ programmieren kann auch funktional geht. Nur mit
>> einem heiden Aufwand eben. Einfache sachen wie schleifen müssen durch
>> rekursion ersetzt werden, die manchmal enorm hässlich werden kann.
>
> Mir ist unklar, was an Rekursion hässlich sein soll.
1. Schleifen sind meißt besser, das sie den Stack nicht voll müllen. Also im
Bezug auf Performance.
2. Hat man eine Schleife indem viele Variablen dann incrementiert o.ä.
werden, muß man die alle mit in die Signatur aufnehmen, da es ja keine
Variablen wie im imperativen Sinne gibt (nur eine Wertzuweisung je
''Variable'').
> Und ich dachte immer, Schleifen gibt's auch in funktionalen
> Sprachen. Hm.
Naja nicht so ganz. :-) höchstens eine Funktion die wie eine schleife
funktioniert, dazu benötigt man dann aber wieder einen 'goto' Befehl.
>> Es war mehr so ne Aussage wie: "Theoretisch (und auch praktisch) kann ich
>> mit $Programmiersprache alles machen was ich mit $Programmiersprache auch
>> kann." Und wenn ich auch einen riesen Aufwand betreibe.
>
> Ja, in der Welt der Turingmaschinen mag das sein. Aber beim Kernel
> geht's ja auch (u.a.) darum, zum richtigen Zeitpunkt den richtigen
> Wert in das richtige Register zu pröppeln.
>
> Und wenn die Sprache keinen Weg kennt, Dinge in Register zu pröppeln,
> haste verloren.
Selbst funktionale Sprachen bieten sogenannte native-funktionen an, mit
denen dann solch Hardware naher Umgang realisiert wird. (Erlang) Ok, bei
Prolog könnte ich mir vorstellen das das nicht gegeben ist, da es praktisch
nicht/nie eingesetzt wird/wurde.
> Diese Denkweise ist stark zustandsbehaftet: was in dem Register
> steht, ist der momentane Zustand des Rechners.
>
> Zustandsabhängigkeit ist aber nun gerade das, was funktionale
> Programmierung vermeiden will...
>
> Wer weiß einen Ausweg?
Es gibt keinen, Zustandsänderungen müssen in NEUEN Variablen festfehalten
werden. Das ist auch das hauptsächliche Problem das Varaiblen in
fkt.-Sprachen nur einmal verwendet werden dürfen, bzw. es keine Zuweisung
gibt.
>> Manchmal gehen Sachen aber in einer PS konfortabeler als in einer
>> anderen, und ich bin mir sicher das C++ in Bezug auf OOP *besser*
>> als C ist. Und wenn OOP für einen Kernel gut zu gebrauchen wäre,
>> dann wäre C++ sicher die bessere Wahl.
>
> Flame on!
Hmmm.
>>> Ein Kernel in Haskell. Wär ja auch nicht schlecht.
>> Haskell kenn ich nicht (lass mich raten funktional :-)?)
>
> Genau. Ich kenne Haskell aber auch nicht. Vielleicht hätte ich ML
> sagen sollen...
>
>> In was ist eigentlich der HURD-Kernel geschrieben?
>
> C.
Ahhh....
mathias
--
mail: fun...@web.de
Mathias Goldau
Alexander Bartolich wrote:
> Mathias Goldau schrieb:
> "Richtige" OO-Sprachen erziehen zur Verwendung möglichst vieler
> kleiner, kurzlebiger Objekte. Das erfordert eine gute Speicherver-
> waltung und verschleiert den Zusammenhang zwischen Code- und Laufzeit-
> komplexität. Was in C++ sehr einfach aussieht, kann in Wirklichkeit
> sehr kompliziert und ineffizient sein.
Die Möglichkeit besteht immer, oder? Und anders herum: Es gibt sicher auch
Sachen die einfacher als in C++ nicht zu realisieren sind (C++ also als
verkürzte Schreibweise bzw. intuitivere fkt.), und in C geschrieben nur
minimalen Performanceverlust verursachen, aber erhöhte unleserlichere
Tipparbeit.
> In einem Virtual-Memory-Betriebssystem ist es ausserdem sehr wichtig,
> dass Kernel-Funktionen nicht unabsichtlich auf nicht gemappten
> Speicher zugreifen. Eine Speicherseite hat auf i386 4 kB, und das ist
> die grundlegende Einheit aller Speicheranforderungen/Freigaben.
> Die Fragmentierung und der Nichtdeterminismus vieler kleiner new/delete
> ist untragbar.
Ja wenn natürlich die Spracherweiterungen von C++ nichts taugen, sollte man
sie mit vorsicht genießen. So gesehen ist C doch wohl die bessere Wahl.
[...]
> IMHO haben die wenigsten Verfechter von OO das Konzept an sich
> verstanden, sondern betreiben nur Syntaxfetischismus.
>
>> [...]
>> Aber in C++ geht es doch schon besser, (mich auf C# für Linux freuend :-)
>
> Interessanterweise ist C++ innerhalb des OO-Lagers ein Paria.
> Alle anderen (Smalltalk, Delphi, Java, Python, Ryby) halten statische
> Typisierung, fehlenden Garbage-Collector und den Template-Dschungel
> für untragbar.
Java ist doch ok.: (bis auf Schnelligkeit):
Garbage-Coll., ab 1.5.x sollen dann die Generics==Templates kommen
> C++-Missionare haben sehr viel mit den "Linux-8.1"-Anwendern gemein.
Ich bin mir sicher man kann C++ auch ordentlich verwenden :-).
mathias
--
mail: fun...@web.de
Alexander Bartolich
> [...] Kapselung von haeufig gebrauchten Idiomen (Wieviele Listen
> werden handverzeigert?
"inline" ist #define natürlich in der Wartbarkeit weit überlegen.
Allerdings bietet gcc das auch für reines C an.
AFAIK lässt sich Vererbung in C nur mit sehr viel Casts oder mit
ultra-hässlichen #define hinschreiben. Gebraucht wird das AFAIK
aber nur in GUI-Bibliotheken, etwa gtk oder Motif.
> [...] Wieviel Typsicherheit bekommt man, wenn alles ein typedef
> auf int ist?
Also typsichere Handles definiert man in C so:
typedef struct { int dummy; } * Handle;
Windows benutzt das recht ausgiebig. Die original Unix-Philosophie
lautet allerdings in Richtung "Everything is a file", d.h. nur ein
einziger Typ von Handle. Idealerweise sollten also alle System-
Objekte mit select(2) zusammenarbeiten.
Die bestehenden Ausnahmen wie wait(2), System-V IPC, POSIX-Threads
sind extrem ärgerlich.
Alexander Bartolich
> [...] Es gibt sicher auch Sachen die einfacher als in C++ nicht
> zu realisieren sind [...] und in C geschrieben nur minimalen
> Performanceverlust verursachen, aber erhöhte unleserlichere
> Tipparbeit.
Gut, auch in C ist Performance-Schwachsinn möglich, etwa Kaskaden
von strcat/strcpy/sprintf. Da steckt überall ein redundantes strlen
drin (ganz abgesehen davon, dass ein Nichtüberprüfung der Puffer-
grenzen mit einem Bugtraq-Posting enden kann).
Aber zumindest wird man C zu einer "+="-Semantik gezwungen, während
die natürliche Schreibweise in C++ temporäre Kopien braucht, etwa
MyClass abc = def + geh;
statt
MyClass abc = def; abc += geh;
>> C++-Missionare haben sehr viel mit den "Linux-8.1"-Anwendern gemein.
>
> Ich bin mir sicher man kann C++ auch ordentlich verwenden :-).
Ja, sicher.
Genauso wie man SuSE ordentlich verwenden kann (keine Ironie!).
Das Problem ist nur, dass beide Dinge große Massen an Neulingen
anziehen, die hier das erste mal mit etwas "richtigem" Arbeiten.
Und in der Begeisterung darüber übersehen sie dann, dass das alles
nur Variationen globaler Konzepte sind.
SuSE ist nur eine von vielen Linux-Distribution.
C++ ist nur eine von vielen OOPL.
Bernhard Lutzer
> Christian Helmbold wrote:
>
>> Hallo,
>>
>> soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
>> nicht C++ geschrieben.
>
> Korrekt. Nur einige Zeilen sind Assembler.
>
>> Ist das einfach historisch so gewachsen, oder
>> gibt es einen Grund dafür, dass C statt C++ verwendet wird?
>
> Nein. In C++ brauchst du dynamische Speicherverwaltung, die es in reinem
> Maschinenencode den man mit C erzeugen kann nicht gibt. Es ist also gar
> nicht möglich.
>
>>
>> Vielleicht kann ja mal jemand einen Blick in seine Kristallkugel werfen
>> ;-)
>>
>> Christian
>
> MFG
> Bernhard
>
Ich hatte mich leicht geirrt. Ich hab das was David mit free und malloc mit
dem C++ verwechselt. War einfach schon zu müde *gähn*
MFG
Bernhard
--
Vermisst du die Signatur?
Thomas Hühn
>> Mir ist unklar, was an Rekursion hässlich sein soll.
> 1. Schleifen sind meißt besser, das sie den Stack nicht voll müllen. Also im
> Bezug auf Performance.
Wenn eine derartige Iteration rekursiv programmiert wird, kann der
Compiler das gegebenenfalls auflösen.
> denen dann solch Hardware naher Umgang realisiert wird. (Erlang) Ok, bei
> Prolog könnte ich mir vorstellen das das nicht gegeben ist, da es praktisch
> nicht/nie eingesetzt wird/wurde.
Prolog wurde nie eingesetzt? Die Computerlinguisten werden dich dafür
verprügeln...
Thomas
René Möhring
Alexander Bartolich <alexander...@gmx.at> wrote:
> Mathias Goldau schrieb:
> > [...] Es gibt sicher auch Sachen die einfacher als in C++ nicht
> > zu realisieren sind [...] und in C geschrieben nur minimalen
> > Performanceverlust verursachen, aber erhöhte unleserlichere
> > Tipparbeit.
>
> Gut, auch in C ist Performance-Schwachsinn möglich, etwa Kaskaden
> von strcat/strcpy/sprintf. Da steckt überall ein redundantes strlen
> drin (ganz abgesehen davon, dass ein Nichtüberprüfung der Puffer-
> grenzen mit einem Bugtraq-Posting enden kann).
>
> Aber zumindest wird man C zu einer "+="-Semantik gezwungen, während
> die natürliche Schreibweise in C++ temporäre Kopien braucht, etwa
>
> MyClass abc = def + geh;
>
> statt
>
> MyClass abc = def; abc += geh;
Man kann in C++ den += Operator auch gemau so nutzen.
Holger Schauer
> 1. Schleifen sind meißt besser, das sie den Stack nicht voll
> müllen. Also im Bezug auf Performance.
Deine Kenntnisse über Rekursion sind verbesserungswürdig. Nicht
zuletzt diskutierst Du Implementationsdetails von Compilern, ohne dass
man auch nur annähernd den Eindruck gewinnt, dass Du wüsstest, worüber
Du redest.
Beliebtes Stichwort in dem Zusammenhang: Endrekursion.
> 2. Hat man eine Schleife indem viele Variablen dann incrementiert o.ä.
> werden, muß man die alle mit in die Signatur aufnehmen, da es ja keine
> Variablen wie im imperativen Sinne gibt (nur eine Wertzuweisung je
> ''Variable'').
Hmm? Stichworte hier sind Kontextargumente und Akkumulatoren.
>> Und wenn die Sprache keinen Weg kennt, Dinge in Register zu pröppeln,
>> haste verloren.
> Selbst funktionale Sprachen bieten sogenannte native-funktionen an, mit
> denen dann solch Hardware naher Umgang realisiert wird. (Erlang) Ok, bei
> Prolog könnte ich mir vorstellen das das nicht gegeben ist, da es praktisch
> nicht/nie eingesetzt wird/wurde.
Was hat Prolog mit funktionalen Sprachen zu tun? Und warum sollte
Prolog nicht eingesetzt werden? Ich kenne zudem mind. zwei
Prologimplementationen, die es erlauben, auch recht Hardware-nah zu
programmieren (ich weiss aber nicht mehr, ob das nur über den Umweg
von Einbindung von Assemblercode ging, oder auch auf anderem Wege).
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
Frauen ? Maenner ? Autos ? Geld ? Linux-Informationen ?
Letzteres findest Du in de.comp.os.unix.linux.infos
0 Flames, 0% Off-Topic: de.comp.os.unix.linux.moderated
Rainer Weikusat
> <weik...@students.uni-mainz.de> wrote:
> >Yoon Soo <y00...@gmx.net> writes:
> >> Was meinst du denn, wie gross die Zahl derer ist, die in ihrer
> >> Freizeit an einem kernel arbeiten? Im Grunde ist es nicht mal mehr
> >> eine Erwähnung wert..(gähn, du auch?)
> >
> >Warum sollte ich auf diesen bescheuerten Gedanken kommen?
>
> vielleicht weil du so daherredest, als ob es etwas tolleres sei, einen
> kernel zu programmieren, als darüber zu reden, oder daherzuschwallen?
Die Nullen sind Programm, wie zu erwarten. Du darfst das Projekt
aufgeben, da wird nichts draus werden.
Noch mal für Schnellmerker mit einer überhöhten Einschätzung der
eigenen (Un-)fähigkeiten: Language wars sind Abfall.
> Manche Leute laufen in ihrer Freizeit hinter einem Ball her, und ich
> würde es nicht unbedingt als bescheuert bezeichnen. Du rettest also in
> deiner Freizeit nur bedrohte Tiere oder tust sonst was nur
> nicht-bescheuertes? Oder wieso kannst DU darüber urteilen, wie
> sinnvoll die Freizeitgestaltung anderer menschen ist? Aber Toleranz
> und soziale Kompetenz scheinen eh nicht zu deinen Stärken zu
> gehören.
Lieber Pisser, ich habe so gut wie keine Freizeit und während der
werde ich nicht auch noch vor einem Computer sitzen. Den Begriff
»Toleranz« möchtest Du im übrigen nachschlagen. Er bedeutet das
Gegenteil von dem, was Du in obigem Absatz auszudrücken versuchst.
> Aber lieber du bezeichnest das, was ich in meiner Freizeit mache als
> bescheuert als wenn du auf die Idee kämest, wir könnten was gemeinsam
> in meiner knappen Zeit unternehmen.
Danke, ich habe gerade erst ein langes & sinnloses Gespräche mit Lucy
Donnerhacke hinter mir und mein Bedarf ein bis zur Verblödung
arroganten Egozentrikern ist momentan Null. Falls Du mal
gewohnheitsmäßig jeden Tag +10h arbeitest (größtenteils unbezalht)
darfst Du noch mal wiederkommen und mir von Deiner Großartigkeit
erzählen.
Rainer Weikusat
> Kapselung von haeufig gebrauchten Idiomen
Ist eine blöde Idee.
Rainer Weikusat
> Ich kenne zudem mind. zwei Prologimplementationen, die es erlauben,
> auch recht Hardware-nah zu programmieren (ich weiss aber nicht mehr,
> ob das nur über den Umweg von Einbindung von Assemblercode ging,
> oder auch auf anderem Wege).
Der »Umweg über die Einbindung von Assemblercode« ist auch ein sinnloser
Einfall: Davon wollten 'wir' doch eigentlich irgendwann mal wegkommen. Aber
solange es noch 'Häcker' gibt, wird eben alles, was in $modesprache
nicht auszudrücken ist, in Maschinencode implementiert (vorzugsweise
via poke, schließlich ist der C64 das Urbild eines Computers) und
dabei kommt man sich dann wirklich noch wie ein toller Hecht vor,
Stichwort »meine persönliche Kernelschnittstelle«.
Mathias Goldau
Thomas Hühn wrote:
> Also sprach Mathias Goldau <fun...@web.de>:
>
>>> Mir ist unklar, was an Rekursion hässlich sein soll.
>> 1. Schleifen sind meißt besser, das sie den Stack nicht voll müllen. Also
>> im Bezug auf Performance.
>
> Wenn eine derartige Iteration rekursiv programmiert wird, kann der
> Compiler das gegebenenfalls auflösen.
Trotzdem *MUß* man das Problem erstmal rekursiv lösen!
>> denen dann solch Hardware naher Umgang realisiert wird. (Erlang) Ok, bei
>> Prolog könnte ich mir vorstellen das das nicht gegeben ist, da es
>> praktisch nicht/nie eingesetzt wird/wurde.
>
> Prolog wurde nie eingesetzt? Die Computerlinguisten werden dich dafür
> verprügeln...
die einzige mir bekannte echte Anwendung war Lehre und Forschung. Gab es
einen Praktischen Einsatzt von Prolog? (Ich meine einen zu zählenden, nicht
irgendein kleines Progrämmchen was mir meine Telefonrechnug auseinander
klamüsert.)
Gruß
mat*sich gerne eines besseren belehren lassend*hias
--
mail: fun...@web.de
Yoon Soo
>
> Die Nullen sind Programm, wie zu erwarten. Du darfst das Projekt
> aufgeben, da wird nichts draus werden.
>
Lieber Rainer, das ist das gute an einem Hobby. Das Resultat muss nix
werden, was zählt ist der Weg und der Spass den man dabei hat.
Vielleicht ist das bei dir etwas auf der Strecke geblieben, weil du es
'professionell' betreibst?
> Noch mal für Schnellmerker mit einer überhöhten Einschätzung der
> eigenen (Un-)fähigkeiten: Language wars sind Abfall.
>
wenn du mein Posting aufmerksamer gelesen hättest, wäre dir aufgefallen,
dass ich eben das gesagt habe. (Im hinblick auf CversusC++..) nach
eigenen Vorlieben und kenntnissen..ich bin der letzte,mit dem du einen
Laguage War führen könntest..hin und wieder nutze ich 'sogar' VBA.
> arroganten Egozentrikern ist momentan Null. Falls Du mal
> gewohnheitsmäßig jeden Tag +10h arbeitest (größtenteils unbezalht)
> darfst Du noch mal wiederkommen und mir von Deiner Großartigkeit
> erzählen.
kann ich was für deine Zeiteinteilung und deine Vorliebe für unbezahlte
Arbeit? Ich will dir auch nichts von meiner Grossartigkeit erzählen,
wozu denn auch..du erkennst sie ja eh nicht an ;)
yoon
David Kastrup
> Mathias Goldau <fun...@web.de> writes:
> > Kai Großjohann wrote:
> >> Mir ist unklar, was an Rekursion hässlich sein soll.
> > 1. Schleifen sind meißt besser, das sie den Stack nicht voll
> > müllen. Also im Bezug auf Performance.
>
> Deine Kenntnisse über Rekursion sind verbesserungswürdig. Nicht
> zuletzt diskutierst Du Implementationsdetails von Compilern, ohne dass
> man auch nur annähernd den Eindruck gewinnt, dass Du wüsstest, worüber
> Du redest.
Naja, aber wenn wir über einen Kernel reden, dann ist sowas wie
Stacktiefe halt nicht ein Implementationsdetail, das man dem Compiler
überlassen wollte.
Und das ist das Hauptproblem, das ich bei einem Kernel in C++ sehe.
C++ ist bei einer ganzen Menge Geschichten darauf angewiesen, daß der
Compiler auch gut optimiert, sonst wird es gräßlich ineffizient (es
gibt eine ganze Menge Sprachkonstrukte der Preisklasse "Tail
Recursion", die für tolerierbare Geschwindigkeit von Objektklassen
optimiert werden sollten). Sinn einer Hochsprache ist es ja, von
Assembler wegzukommen.
Bei einem Kernel in C++ müßte ich aber _viel_ häufiger das übersetzte
Ergebnis daraufhin überprüfen, ob das akzeptablen Assemblercode
erzeugt, als bei einem Kernel in C. Und wenn der Optimierer mal das
Handtuch wirft, sind die Folgen auch gleich viel verheerender.
David Kastrup
Nicht per se. Aber ein gewisses Problem besteht natürlich schon in
"Interface Garbage". Illustrieren kann man das mit einem
"wiederverwendbaren Satzteil". Wenn der es als Hauptsatz oder
Nebensatz tun soll, braucht man eine Abstraktion für
Wortumstellungen. Wenn man den im Akkusativ und Genitiv verwenden
will, müssen bestimmte Flexionsstellen entsprechend variabel werden.
Und dann kommt jemand und sagt, daß er gerne das hinkriegen will,
so daß man das auch in verschiedene Gedichte einbinden kann, ohne daß
die Metrik leidet...
Das ist halt eine Frage der Komplexität. Wegwerfidiome paßt man am
besten in den Kontext ein, statt zwangweise irgendein Modul zu nutzen
(lineare Listen abklappern etwa).
Nun kann ich bei sowas wie linearen Listen natürlich auch STL
benutzen, und habe dann mit wenigen Handgriffen die Möglichkeit, eine
Implementation, die einen Faktor 3 langsamer ist, mit einer zu
ersetzen, die einen Faktor 2.5 langsamer ist...
Bei komplexerer Funktionalität kann die Kapselung dann aber schon
praktischer sein. Aber das wird man auch in C schon i.a. dann in der
einen oder anderen Form durchführen, wenn man es als nötig erachtet.
Mathias Goldau
> Yoon Soo <y00...@gmx.net> writes:
>> <weik...@students.uni-mainz.de> wrote:
>> >Yoon Soo <y00...@gmx.net> writes:
>> >> Was meinst du denn, wie gross die Zahl derer ist, die in ihrer
>> >> Freizeit an einem kernel arbeiten? Im Grunde ist es nicht mal mehr
>> >> eine Erwähnung wert..(gähn, du auch?)
>> >
>> >Warum sollte ich auf diesen bescheuerten Gedanken kommen?
>>
>> vielleicht weil du so daherredest, als ob es etwas tolleres sei, einen
>> kernel zu programmieren, als darüber zu reden, oder daherzuschwallen?
>
> Die Nullen sind Programm, wie zu erwarten. Du darfst das Projekt
> aufgeben, da wird nichts draus werden
von Anfang an und bemerke das Du nur so daher-laberst.
> Noch mal für Schnellmerker mit einer überhöhten Einschätzung der
> eigenen (Un-)fähigkeiten: Language wars sind Abfall.
Natürlich und Weiterentwicklung ist auch Unsinn. So ein ausgemachter
Schwachsinn.
>> Manche Leute laufen in ihrer Freizeit hinter einem Ball her, und ich
>> würde es nicht unbedingt als bescheuert bezeichnen. Du rettest also in
>> deiner Freizeit nur bedrohte Tiere oder tust sonst was nur
>> nicht-bescheuertes? Oder wieso kannst DU darüber urteilen, wie
>> sinnvoll die Freizeitgestaltung anderer menschen ist? Aber Toleranz
>> und soziale Kompetenz scheinen eh nicht zu deinen Stärken zu
>> gehören.
>
> Lieber Pisser, ich habe so gut wie keine Freizeit und während der
> werde ich nicht auch noch vor einem Computer sitzen. Den Begriff
> »Toleranz« möchtest Du im übrigen nachschlagen. Er bedeutet das
> Gegenteil von dem, was Du in obigem Absatz auszudrücken versuchst.
Du willst Tolleranz deiner Urteile? Nein irgendwann ist eine Grenze
erreicht! Jetzt.
>> Aber lieber du bezeichnest das, was ich in meiner Freizeit mache als
>> bescheuert als wenn du auf die Idee kämest, wir könnten was gemeinsam
>> in meiner knappen Zeit unternehmen.
>
> Danke, ich habe gerade erst ein langes & sinnloses Gespräche mit Lucy
> Donnerhacke hinter mir und mein Bedarf ein bis zur Verblödung
> arroganten Egozentrikern ist momentan Null. Falls Du mal
Jetzt wird mir einiges klar warum deine Posts so sind wie sie sind. Du hast
zu oft solche Gespräche?
> gewohnheitsmäßig jeden Tag +10h arbeitest (größtenteils unbezalht)
> darfst Du noch mal wiederkommen und mir von Deiner Großartigkeit
> erzählen.
Eine Dose Mitleid für dich! (ein große)
--
mail: fun...@web.de
Mathias Goldau
Holger Schauer wrote:
> Mathias Goldau <fun...@web.de> writes:
>> Kai Großjohann wrote:
>>> Mir ist unklar, was an Rekursion hässlich sein soll.
>> 1. Schleifen sind meißt besser, das sie den Stack nicht voll
>> müllen. Also im Bezug auf Performance.
>
> Deine Kenntnisse über Rekursion sind verbesserungswürdig. Nicht
> zuletzt diskutierst Du Implementationsdetails von Compilern, ohne dass
> man auch nur annähernd den Eindruck gewinnt, dass Du wüsstest, worüber
> Du redest.
Hmm, Compilerbauer bin ich wirklich nicht.
> Beliebtes Stichwort in dem Zusammenhang: Endrekursion.
Es ging doch darum Schleifen funktional auszudrücken. Diese mußt du erst
rekurisv programmieren. So. Es gibt ja verschiedene Rekusionen unteranderem
verneste siehe Ackermann. Können heutige Compiler solch krasse Rekursionen
auflösen? (Theoretisch kann man ja jede Rekursion in Schleifen überführen)
Wenn das auch praktisch geht dann stimmt mein Argument 1 nicht mehr :-).
>> 2. Hat man eine Schleife indem viele Variablen dann incrementiert o.ä.
>> werden, muß man die alle mit in die Signatur aufnehmen, da es ja keine
>> Variablen wie im imperativen Sinne gibt (nur eine Wertzuweisung je
>> ''Variable'').
>
> Hmm? Stichworte hier sind Kontextargumente und Akkumulatoren.
Ja im Compilerbau(-optimierung), nicht in der Implementation der Rekursion
in $fkt-Sprache, da Akkumulatoren als Sprachelemente nicht in das Konzept
von funktionalen Sprachen passen.
>>> Und wenn die Sprache keinen Weg kennt, Dinge in Register zu pröppeln,
>>> haste verloren.
>> Selbst funktionale Sprachen bieten sogenannte native-funktionen an, mit
>> denen dann solch Hardware naher Umgang realisiert wird. (Erlang) Ok, bei
>> Prolog könnte ich mir vorstellen das das nicht gegeben ist, da es
>> praktisch nicht/nie eingesetzt wird/wurde.
>
> Was hat Prolog mit funktionalen Sprachen zu tun? Und warum sollte
Prolog ist auch eine! UND außerdem eine Logikorientierte.
> Prolog nicht eingesetzt werden? Ich kenne zudem mind. zwei
> Prologimplementationen, die es erlauben, auch recht Hardware-nah zu
> programmieren (ich weiss aber nicht mehr, ob das nur über den Umweg
> von Einbindung von Assemblercode ging, oder auch auf anderem Wege).
Ahhh... das würde mich aber mal brennend interessieren. Keine URL mehr?
Gruß
mathias
--
mail: fun...@web.de
André Pönitz
Du debugst lieber das Einhaengen in eine doppelt verkettete Liste
zwanzigmal am Tag neu?
[Ok, das hat man irgendwann mal "fliessend", dann gibt's aber die
vier-Zeiler, die man nur alle vier Wochen braucht.]
Thomas Hühn
>> Wenn eine derartige Iteration rekursiv programmiert wird, kann der
>> Compiler das gegebenenfalls auflösen.
>
> Trotzdem *MUß* man das Problem erstmal rekursiv lösen!
Ja und?
>> Prolog wurde nie eingesetzt? Die Computerlinguisten werden dich dafür
>> verprügeln...
>
> die einzige mir bekannte echte Anwendung war Lehre und Forschung. Gab es
> einen Praktischen Einsatzt von Prolog? (Ich meine einen zu zählenden, nicht
> irgendein kleines Progrämmchen was mir meine Telefonrechnug auseinander
> klamüsert.)
Ich bin kein Prolog-Freak und kann da wenig zu sagen. Aber Lehre und
Forschung finde ich als praktische Anwendung auch ganz nett.
Nicht alles, was die Universitäten so treiben, ist sinnlos.
Thomas
André Pönitz
> Aber zumindest wird man C zu einer "+="-Semantik gezwungen, während
> die natürliche Schreibweise in C++ temporäre Kopien braucht, etwa
>
> MyClass abc = def + geh;
Wenn Du diese Ineffizienz verhindern willst, dann deklarierst Du halt den
entsprechend Operator+ und implementierst ihn nicht und keiner wird ihn
benutzen.
Und wenn Du ein helles Koepfchen bist, bastelst Du Dir passende
Expressiontemplates und kannst
MyClass abc = def + geh
schreiben, und der Compiler droeselt Dir das brav zu
MyClass abc = def; abc += geh;
wenn nicht gar zu
MyClass abc = def;
abc.data1 += geh.data1;
abc.data2 += geh.data2;
abc.data3 += geh.data3;
auf. Und _diese_ Art von Effizienz ("Ich schreibe, was ich meine, und
bekomme optimalen Code") in blankem C zu erreichen, ist gerade in diesem
Bereich unmoeglich.
In C wirst Du fast immer
double a[n], b[n], c[n], d[n];
set_array(a, b);
add_array(a, c);
add_array(a, d);
schreiben muessen, um nicht jedes mal das Rad neu erfinden zu muessen.
Dann hast zwangslaeufig drei Schleifen, deren Performance nicht durch den
Koerper sondern durch den Reucksprung bestimmt ist. Davon mal abgesehen ist
die Syntax nicht offensichtlich (was wird eigentlich wo dazugezaehlt?).
In C++ nimmst Du
std::valarray<double> a(n), b(n), c(n), d(n);
a = b + c + d;
und wenn der Bibliotheksimplementor keinen Sch* gebaut hat, wird das eine
einzige Schleife mit Koerper a[i] = b[i] + c[i] + d[i].
> SuSE ist nur eine von vielen Linux-Distribution.
Ack.
> C++ ist nur eine von vielen OOPL.
C++ ist keine OOPL. Es laesst sich allerdings zu einem gewissen Grad als
solche (miss|ge)brauchen. Insbesondere von Leuten, die es normalerweise
nicht verwenden.
David Kastrup
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > André Pönitz <poe...@gmx.net> writes:
> >> Kapselung von haeufig gebrauchten Idiomen
> >
> > Ist eine blöde Idee.
>
> Du debugst lieber das Einhaengen in eine doppelt verkettete Liste
> zwanzigmal am Tag neu?
>
> [Ok, das hat man irgendwann mal "fliessend", dann gibt's aber die
> vier-Zeiler, die man nur alle vier Wochen braucht.]
Anekdote am Rande: in 95% aller Fälle werden doppelt verkettete
Listen nicht gebraucht, um diese rückwärts zu durchlaufen, sondern um
Elemente löschen zu können. Und dann ist die übliche Implementation
zu umständlich und langsam und muß den Kopf der Liste unnötigerweise
als Ausnahme behandeln.
Beispiel für eine bessere Behandlung:
struct node {
struct node *next, **anchor;
...
}
Aufbau:
struct node *head, **tail = &head;
while (...) {
ptr = malloc(...);
*(ptr->anchor = tail) = ptr;
*(tail = &ptr->next) = 0; /* Kann aus der Schleife raus, falls
Daten zwischendurch nicht konsistent
sein müssen. */
}
Löschen, auch des ersten Elementes:
if (ptr->next) {
ptr->next->anchor = ptr->anchor;
}
*ptr->anchor = ptr->next;
free(ptr);
Usw. Einfügen vor und nach dem ersten Element brauchen ebenfalls
keine Fallunterscheidung. Die Idiome sind so kurz, daß ich da
wirklich keine allgemeine Funktion brauche.
Wenn ich jetzt meine doppelt gelinkten Listen gekapselt habe, muß ich
auf diese effiziente Konstruktion verzichten, weil man in 5% der Fälle
die doppelt gelinkten Listen eben _doch_ braucht, um sie mal
rückwärts zu durchlaufen.
Mathias Goldau
> Also sprach Mathias Goldau <fun...@web.de>:
>
>>> Wenn eine derartige Iteration rekursiv programmiert wird, kann der
>>> Compiler das gegebenenfalls auflösen.
>>
>> Trotzdem *MUß* man das Problem erstmal rekursiv lösen!
>
> Ja und?
Also um noch mal zusammen zufassen: war ich anfangs der Meinung das OO zu
programmieren in C genauso schwer, wenn nicht sogar noch einfacher, wie
funktional überhaupt zu programmieren ist. Die funktionalen Sprachen
sollten ein Beispiel dafür sein das es doch ein ziehmliches Gefriehmel ist
fkt. zu programmieren. Und diesen Vergleich zu C zog ich da ich mir
vorstellen kann das in C OO zu programmieren ebenfalls ein ziehmliches
Gefriehmel sein dürfte. Als sprich der Entwicklungsaufwand größer würde.
Und das Beispiel sollten die Schleifen sein. Deren Umsetzung nicht immer
einfach sind (finde ich). Und deshalb:
Komme ich um den Entwicklungsaufwand der Rekursivität in fkt-Sprachen nicht
drum herum.
Klar ist das mein Effizienzargument entfällt sobald der Compiler rekursion
wieder auflöst.
> Ich bin kein Prolog-Freak und kann da wenig zu sagen. Aber Lehre und
> Forschung finde ich als praktische Anwendung auch ganz nett.
Wenn Prolog nur in Forschung und Lehre benutzt wird ist es dann nicht eine
Art Selbstzweck? Ok es ist eine Hübsche "Spielerei", und wer weiss was mal
draus wird :-).
<philosophisch>
Ok je länger ich drüber nachdenken, desto mehr kann ich mir vorstellen, das
auch Forschung und Lehre eine praktische ANWENDUNG der von ihr selbst
erstellten Theorie ist.
</philosophisch>
> Nicht alles, was die Universitäten so treiben, ist sinnlos.
ACK
--
mail: fun...@web.de
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > André Pönitz <poe...@gmx.net> writes:
> >> Kapselung von haeufig gebrauchten Idiomen
> >
> > Ist eine blöde Idee.
>
> Du debugst lieber das Einhaengen in eine doppelt verkettete Liste
> zwanzigmal am Tag neu?
Nicht unbedingt ;-). Aber wenn ich zB eine queue auf einer allgemeinen
Liste aufsetze, bringt mir das wenig außer zusätzlichem Fett. Ich habe
hier zB das Problem, daß ich den Durchschnitt einer Menge von Zahlen
berechnen möchte, zu der ständig neue Mitgleider hinzukommen (und die
jeweils ältesten ersetzen). Dafür könnte man einen beliebig
implementierten FIFO benutzen, aber die 'nicht-abstrahierte' Lösung
sieht bloß so aus:
void add_to_avg(unsigned npackets)
{
if (ndx == AVG_ELEMENTS) ndx = 0;
else ++ndx;
if (n == AVG_ELEMENTS) sum -= GOP_sizes[ndx];
else ++n;
npackets = npackets * 3 / 4
GOP_sizes[ndx] = npackets;
sum += npackets
avg_GOP_packets = sum / n;
info("avergage GOP size: %u packets", avg_GOP_packets);
}
Es gibt auch verschiedene Möglichkeiten, verkettete Listen zu
implementieren (zB mit einer array-Repräsentation). Bevor man
'abstrakte Datentypen' kreativ verwendet, sollte man mE erst mal
darüber nachdenken, welche Operationen man eigentlich konkret
durchführen möchte und ob das nicht auch einfacher geht (mit
'einfacher' ::= 'erfordert weniger Hintergrundwissen zum Verständnis'
in diesem Fall).
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > André Pönitz <poe...@gmx.net> writes:
> >> Kapselung von haeufig gebrauchten Idiomen
> >
> > Ist eine blöde Idee.
>
> Du debugst lieber das Einhaengen in eine doppelt verkettete Liste
> zwanzigmal am Tag neu?
Nicht unbedingt ;-). Aber wenn ich zB eine queue auf einer allgemeinen
André Pönitz
> Beispiel für eine bessere Behandlung:
>
> struct node {
> struct node *next, **anchor;
> ...
> }
>
> Aufbau:
> Löschen, auch des ersten Elementes:
Nett. Kannte ich noch nicht.
> Wenn ich jetzt meine doppelt gelinkten Listen gekapselt habe, muß ich
> auf diese effiziente Konstruktion verzichten, weil man in 5% der Fälle
> die doppelt gelinkten Listen eben _doch_ braucht, um sie mal
> rückwärts zu durchlaufen.
Oh, nichts hindert Dich, zwei verschiedene Dinge zu kapseln.
Das Huebsche am Kapseln ist ja, dass Du jederzeit erstmal mit einer
"featurereichen Liste" anfangen kannst, dann feststellst, dass Du ausser
anhaengen und loeschen nix brauchst und dann nur den Typ des Listenobjekts
von fetter_typ auf schlanker_typ aendern musst und ohne weitere Aenderungen
am Code alles noch geht.
Hast Du das "handverdrahtet", dann sind das zwar "immer nur zwei Zeilen",
aber "fix mal was ausprobieren" wird deutlich komplizierter.
David Kastrup
> David Kastrup <d...@gnu.org> wrote:
> > Beispiel für eine bessere Behandlung:
> >
> > struct node {
> > struct node *next, **anchor;
> > ...
> > }
> >
> > Aufbau:
> > [...]
> > Löschen, auch des ersten Elementes:
> > [...]
>
> Nett. Kannte ich noch nicht.
Kennt auch so gut wie keiner. Das ist ein relativ natürliches Idiom,
wenn man von Assembler herkommt, und geht gar nicht, wenn man von
Pascal herkommt. Beim Stichwort "Datenstruktur" schaltet aber der
typische Informatiker sein Gehirn auf Hochsprache um.
Ich kenne praktisch keinen Code und keine Literatur, die nicht
zwanghaft bei der Notwendigkeit von Rückwärtsreferenzen statt der
eigentlich interessanten Referenz auf den Link eine Referenz auf das
komplett vorangegangene Datenelement mitschleift und deswegen zum
einen ständig unnötig Offsets auf das interessante Element
berücksichtigen muß, zum anderen den Kopfpointer immer gesondert
behandeln muß, weil der eben nicht zu einem Element gehört.
Das wird besonders schmerzhaft, wenn ich etwa bei Hashstrukturen nicht
einen, sondern hunderte potentieller Köpfe habe, und meine Elemente
über verschiedene Verkettungen erreichbar sind. Ein Element dann aus
einer anderen als der Kette zu entfernen, über die ich sie erreicht
habe, wird richtig schmerzhaft.
Da diese Schmerzen aber bei den Spielproblemen in den
Informatikvorlesungen noch nicht extrem auffällig werden, wird auch
nichts anderes gelehrt, und was nicht gelehrt wird, wird nicht
benutzt. Und eine Vorlesung über Datenstrukturen wird sich eh vornehm
von Dingen wie Assembler und C fernhalten und diskret verschweigen,
daß eine elegante Lösung in einer Sprache, die nicht das Äquivalent
prozeduraler var-Parameter in Datenstrukturen brennen kann, nicht
möglich ist.
> Das Huebsche am Kapseln ist ja, dass Du jederzeit erstmal mit einer
> "featurereichen Liste" anfangen kannst, dann feststellst, dass Du
> ausser anhaengen und loeschen nix brauchst und dann nur den Typ des
> Listenobjekts von fetter_typ auf schlanker_typ aendern musst und
> ohne weitere Aenderungen am Code alles noch geht.
schlanker_typ ist aber dann immer noch deutlich ineffizienter als die
Handkodierung, da ich (will ich ernsthafte Austauschbarkeit auf diesem
Niveau) dann kräftig vererben und virtuelle Methoden einsetzen muß.
Da dann der Compiler nicht weiß, was letztlich verwendet werden wird,
kann er auch nicht für den Spezialfall optimieren.
Holger Schauer
Mathias Goldau <fun...@web.de> writes:
> Holger Schauer wrote:
>> Mathias Goldau <fun...@web.de> writes:
>>> 1. Schleifen sind meißt besser, das sie den Stack nicht voll
>>> müllen. Also im Bezug auf Performance.
[...]
>> Beliebtes Stichwort in dem Zusammenhang: Endrekursion.
> Es ging doch darum Schleifen funktional auszudrücken. Diese mußt du erst
> rekurisv programmieren. So. Es gibt ja verschiedene Rekusionen unteranderem
> verneste siehe Ackermann.
Ja, solche Fälle gibt es. Your point being?
(Man beachte den oben gequoteten Kontext).
> Können heutige Compiler solch krasse Rekursionen auflösen?
> (Theoretisch kann man ja jede Rekursion in Schleifen überführen)
> Wenn das auch praktisch geht dann stimmt mein Argument 1 nicht mehr
Dein Argument aus 1 stimmt so oder so nicht. Es gibt reichlich
bescheidene iterative Lösungen für viele Probleme, die mit Rekursion
eleganter zu lösen wären. Es ist einfach Quatsch, Rekursion standepede
zu verteufeln, so wie Du es hier getan hast.
>>> 2. Hat man eine Schleife indem viele Variablen dann incrementiert o.ä.
>>> werden, muß man die alle mit in die Signatur aufnehmen, da es ja keine
>>> Variablen wie im imperativen Sinne gibt (nur eine Wertzuweisung je
>>> ''Variable'').
>> Hmm? Stichworte hier sind Kontextargumente und Akkumulatoren.
> Ja im Compilerbau(-optimierung), nicht in der Implementation der Rekursion
> in $fkt-Sprache, da Akkumulatoren als Sprachelemente nicht in das Konzept
> von funktionalen Sprachen passen.
Ich weiss nicht, was Du unter Akkumulatoren verstehst, aber ich
verstehe darunter wahrscheinlich etwas anderes als Du. Akkumulatoren
sind der typische funktionale Sammeleimer für das von Dir ange-
sprochene Problem.
(defun add (x y)
(labels (add-acc (x y result)
(when (= y 0)
result)
(add-acc (x (- y 1) (+ result 1)))))
(add-acc x y 0))
>> Was hat Prolog mit funktionalen Sprachen zu tun? Und warum sollte
> Prolog ist auch eine! UND außerdem eine Logikorientierte.
Du verdrehst die Tatsachen. Prolog ist in aller erster Linie eine
deklarative Sprache. Wenn man fies sein möchte, kann man in Prolog
problemlos nicht-funktional programmieren. Stichwort: assert und
retract als globale Variablen missbrauchen. Man kann in jeder Sprache
Fortran programmieren.
>> Prolog nicht eingesetzt werden? Ich kenne zudem mind. zwei
>> Prologimplementationen, die es erlauben, auch recht Hardware-nah zu
>> programmieren (ich weiss aber nicht mehr, ob das nur über den Umweg
>> von Einbindung von Assemblercode ging, oder auch auf anderem Wege).
> Ahhh... das würde mich aber mal brennend interessieren. Keine URL mehr?
Ich bin recht sicher, dass das mit Amzi-Prolog ging/geht (falls die
noch existieren). Ich meine, Sicstus oder Eclipse Prolog konnte das
auch. Selbst SWI hat mittlerweile eine C-Schnittstelle, die auf den
ersten Blick recht mächtig aussieht.
Holger Schauer
> Thomas Hühn wrote:
>> Wenn eine derartige Iteration rekursiv programmiert wird, kann der
>> Compiler das gegebenenfalls auflösen.
> Trotzdem *MUß* man das Problem erstmal rekursiv lösen!
Ich habe zwar schon öfter Probleme gehabt, eine rekursive Lösung in
eine iterative zu verwandeln, aber nur selten, eine iterative Lösung
in eine rekursive zu verwandeln. Mag es aber auch geben. Aber dennoch
dürfte der Fall, in dem eine Lösung rekursiv /deutlich/ intuitiver
ist, häufiger sein.
>> Prolog wurde nie eingesetzt? Die Computerlinguisten werden dich dafür
>> verprügeln...
>
> die einzige mir bekannte echte Anwendung war Lehre und Forschung. Gab es
> einen Praktischen Einsatzt von Prolog?
IIRC wurde Prolog bspw. zur Konfiguration von irgendwelcher Peripherie
eingesetzt, entweder Soundkarten oder Netzwerkkarten. Ich meine, dass
wäre entweder in den Tiefen von OS/2 oder einem Windows 9X oder NT-X
gewesen. Daneben dürfte es doch eine Menge an Firmen-Einsätzen
geben, die man als Normal-Sterblicher eher nicht zu Gesicht bekommt.
Irgendwovon müssen die kommerziellen Prolog-Vendors ja auch leben. Auf
der Visual Prolog Homepage finden sich einige Infos.
André Pönitz
> schlanker_typ ist aber dann immer noch deutlich ineffizienter als die
> Handkodierung, da ich (will ich ernsthafte Austauschbarkeit auf diesem
> Niveau) dann kräftig vererben und virtuelle Methoden einsetzen muß.
Nein. 'template' ist das Stichwort.
> Da dann der Compiler nicht weiß, was letztlich verwendet werden wird,
> kann er auch nicht für den Spezialfall optimieren.
Doch. Der Code landet komplett inline. Im Assembler steht ziemlich genau
das, was mit Deiner handgemachten Loesung da auch steht.
Juergen Ilse
Bernhard Lutzer <gigama...@web.de> wrote:
> Christian Helmbold wrote:
>> soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
>> nicht C++ geschrieben.
> Korrekt. Nur einige Zeilen sind Assembler.
>> Ist das einfach historisch so gewachsen, oder
>> gibt es einen Grund dafür, dass C statt C++ verwendet wird?
Es gibt eine Menge Programmierer, die C++ nicht allzusehr moegen.
C++ ist irgendwie "weiter von der Maschine weg" als C. Ausserdem
hat das sicherlich auch historische Gruende, denn zu Zeiten der
ersten Linux-Kernel war der Gnu-C++ Compiler noch lange nicht auf
dem heutigen Stand, was die Unterstuetzung der Sprache anbetraf,
sogar noch schlimmer: Es gab noch nicht einmal den (IIRC 1999
verabschiedeten) ANSI- bzw. ISO-Standard fuer die Sprache C++.
Zwar wurde im selben Jahr auch eine Ueberarbeitung des Standards
fuer die Sprache C verabschiedet (C99), aber es gab zumindest
auch vorher schon einen ISO-Standard fuer die Sprache, bei C++
war das nicht der Fall. Einige Kernel (IIRC aus der 2.0.x Serie)
wurden uebrigens per Default mit dem C++-Compiler uebersetzt, was
die Entwicklung des C++ Compilers voran getrieben hatte (weil
dadurch einige Probleme erst richtig zu Tage traten, die vorher
eher unbemerkt geblieben sind).
> Nein. In C++ brauchst du dynamische Speicherverwaltung, die es in reinem
> Maschinenencode den man mit C erzeugen kann nicht gibt. Es ist also gar
> nicht möglich.
Das Argument ist einfach nur Kaese. Nach dieser Argumentation koennte
es kein weitgehend in C++ geschriebenes Betriebssystem geben, allerdings
gibt es da doch einige (Choices z.B. aber es gibt noch mehr).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Juergen Ilse
Mathias Goldau <fun...@web.de> wrote:
> die einzige mir bekannte echte Anwendung war Lehre und Forschung. Gab es
> einen Praktischen Einsatzt von Prolog? (Ich meine einen zu zählenden, nicht
> irgendein kleines Progrämmchen was mir meine Telefonrechnug auseinander
> klamüsert.)
AFAIK gab es am Institut fuer Fertigungstechnik der Uni Hannover mal
ein Projekt zur Planung von Fertigungsanlagen, dass (zumindest teilweise)
in Progol programmiert war. Das Projekt, an dem ich damals mitgeschrieben
habe, lief allerdings auf einer Micro-VAX unter Vax-Lisp (und es wurde
darueber hinaus "KnowledgeCraft" oder wie das hiess als "Expertensystemshell"
benutzt).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
André Pönitz
> Es gibt auch verschiedene Möglichkeiten, verkettete Listen zu
> implementieren (zB mit einer array-Repräsentation). Bevor man
> 'abstrakte Datentypen' kreativ verwendet, sollte man mE erst mal
> darüber nachdenken, welche Operationen man eigentlich konkret
> durchführen möchte und ob das nicht auch einfacher geht (mit
> 'einfacher' ::= 'erfordert weniger Hintergrundwissen zum Verständnis'
> in diesem Fall).
Genau das ist das Problem: 100%-\epsilon der Faelle ist es voellig wurscht,
welche konkrete Implementation hinter der Fassade steckt. Es gibt nach dem
"gesunden Menschenverstand" immer eine halbwegs vernueftige erste Naeherung
(z.B. Container mit oder ohne Einfuegen in der Mitte == liste oder array)
Wenn Dir dann der Profiler sagt, da ist ein Flaschenhals, _dann_ kannst Du
Dir'n Kopf ueber die zweite Naeherung machen. Und diese "Nacharbeit" wird
besonders einfach, wenn man ein Arsenal von Dingen mit dem gleichen
Interface hat, die fuer verschiedene Aspekte optimiert sind, aber
trotzdem relativ problemlos ausgetauscht werden koennen.
Eugen Ernst
> Ausserdem hat das sicherlich auch historische Gruende,
> denn zu Zeiten der ersten Linux-Kernel war der Gnu-C++
> Compiler noch lange nicht auf dem heutigen Stand
Und genau deswegen bleiben alle bis in alle Ewigkeit bei C und schreiben
Umlaute mit ae. Lasst dem Fortschritt keine Chance, was gestern ging ist
auch morgen noch gut. Wahrscheinlich reitest du jeden morgen noch mit
einem Pferd duch die Stadt und hälst die Maus für Teufelszeug. Euch
schmeißt man hoffentlich bald mitsamt euren Stuhl auf dem ihr klebt aus
der IT damit es endlich wieder vorangeht. Nur Steinzeitprogrammierer und
Kaputtadministrierer findet man bei Linux.
mfg
Eugen
David Kastrup
> David Kastrup <d...@gnu.org> wrote:
> > schlanker_typ ist aber dann immer noch deutlich ineffizienter als
> > die Handkodierung, da ich (will ich ernsthafte Austauschbarkeit
> > auf diesem Niveau) dann kräftig vererben und virtuelle Methoden
> > einsetzen muß.
>
> Nein. 'template' ist das Stichwort.
Für größere Funktionalität kannst Du nicht den Wasserkopf von
hunderten Instanzen rumschleppen. Irgendwann muß man halt einen
Schnitt machen und auf virtuelle Basisklassen ausweichen. Und dieser
Schnitt ist nicht gerade übermäßig unauffällig zu bewerkstelligen.
Musterbeispiele sind ja etwa Sortierroutinen. Die kann man nicht nur
auf dem Zieltype templatisieren, weil ja verschiedene Sortierkriterien
anfallen können. Also muß man auch noch auf einer
Vergleichsfunktion/Operator templatisieren. Auf einen
Integervergleichsoperator kann ich aber nicht gerade einen
Funktionspointer als Templateargument rekrutieren.
Generelle Sortierkriterien brauchen auch eventuell zusätzliche
Parameter/Datenstrukturen, die man dann bei rekursiven Aufrufen auch
weitergeben müßte. Die in statischen Variablen zu verstauen, ist
keine Lösung, weil nicht reentrable, threadsicher etc.
Wenn Du willst, kann ich Dir mal eine Sortierroutine für lineare
Listen schicken, die ich in C plus Präprozessor geschrieben habe.
Eigentlich ein Musterexemplar für Funktionalität, die man gerne
templatisieren wollte. Ich gebe zu, daß ich mich nicht lange daran
versucht habe, aber eine Typisierung und Schreibweise in C++, die mich
gleichzeitig in Lesbarkeit, Flexibilität und Effizienz bei typischen
Anwendungen überzeugt hätte, habe ich nicht gesehen.
Und mit STL sinnvoll zu verheiraten war das irgendwie auch nicht.
Kann sein, daß meine damaligen Versuche auch am gerade von g++
unterstützen Sprachstandard, speziell den sauber nutzbaren
Templateparametern, krankten.
Generell bricht sich nach meinem Geschmack C++ für einige der Dinge,
die es zu erreichen versucht, viel zu sehr einen ab. Das
Typenkonversionsdickicht beispielsweise ist eine Krankheit, die ganz
offensichtlich von dem Wunsch diktiert wurde "ich will einen komplexen
Datentyp vom Benutzer definieren lassen können, der sich mit
automatischen Konversionen so ziemlich benimmt wie der eingebaute in
Fortran, ohne daß bisherige C-Programme anders interpretiert werden".
Daß die Regeln dann aber vollkommenes Chaos anrichten, wenn man etwa
einen komplexen Restklassenarithmetiktyp damit bastelt, bei dem eine
automatische Konversion über den Umweg "double" tödlich wäre, ist
dabei unter den Tisch gefallen.
Ein weiteres Unding ist die _Syntax_ von Templates, die recht
unreflektiert von Adas generics geklaut wurde, wo die Spitzklammern
als Typenconstraints sich in ein sinnvolles Konzept einfügen. In
einer C-basierten Syntax ist das aber ziemlicher Unfug, schon allein
weil >> ein Shiftoperator ist. Weiterhin verursacht es erhebliche
Merkwürdigkeiten im Zusammenspiel zwischen Präprozessor und templates.
Oftmals wird eine Klasse nur als syntaktischer Bezugspunkt
eingerichtet, was auch Sinn macht. Dennoch kann ich beispielsweise
überladene arithmetische Operatoren nicht als static deklarieren, so
daß sie nicht ohne sinnlose Instantation und herumreichen eines
unnötigen this-pointers auf ein ungenutztes Objekt einsetzbar sind.
Die Regel ist vollkommen willkürlich: eine technische Notwendigkeit
besteht nicht. Ein typisches Beispiel einer instanzfrei sinnvollen
arithmetischen Klasse wäre bei der Implementation komplexer Arithmetik
eine eigene Klasse für "i", das bei Multiplikationen speziell
implementiert werden könnte, um komplexe Zahlen effizient als a+i*b
schreiben zu können.
C++-Parser sind praktisch nicht fehlerfrei hinzukriegen, jeder hat
seine eigene Liste von Fehlerquellen und ein korrekter Parser kann
praktisch nur von Hand geschrieben werden.
Man muß sich deswegen in der Praxis auf einen Subset beschränken, bei
dem die Wahrscheinlichkeit, daß verschiedene Compiler und menschliche
Leser zu derselben Interpretation kommen, halbwegs gegeben ist.
Kurz: für meinen Geschmack ist C++ zu sehr Objektorientierung mit der
Brechstange. Die aufwendigen faulen Kompromisse, die es eingeht, sind
ohne Weitsicht auf die Sprache aufgepfropft worden und lösen
tendenziell immer nur gerade irgendein spezielles Problem, mit einer
neuen speziellen Syntax und neuen speziellen Nebenwirkungen, die mit
inkonsistenten Zusatzregeln auf Abwärtskompatibilität getrimmt zu
werden versuchen.
Für einen Kernel oder andere Projekte mit massiv verteilten Autoren
und Kompetenzen ist nach meiner Ansicht die Sprache mit erheblicher
Vorsicht zu genießen. Sie ist erheblich unberechenbarer als C in den
Auswirkungen auf den konkreten Code, und vor allen Dingen macht sie es
einem auch sehr leicht, Features in einer Art und Weise zu benutzen,
von der man aus Rücksicht auf geistige Gesundheit,
Compilerabhängigkeit und Wartbarkeit besser abgesehen hätte.
Maik Zumstrull
> Juergen Ilse schrieb:
>
>>Ausserdem hat das sicherlich auch historische Gruende,
>>denn zu Zeiten der ersten Linux-Kernel war der Gnu-C++
>>Compiler noch lange nicht auf dem heutigen Stand
>
> Und genau deswegen bleiben alle bis in alle Ewigkeit bei C und schreiben
> Umlaute mit ae. Lasst dem Fortschritt keine Chance, was gestern ging ist
> auch morgen noch gut.
Der Argumentationslinie stimme ich absolut zu. Nur: Sie greift an dieser
Stelle nicht, weil die Aussage, C++ wäre ein "Fortschritt" gegenüber C
nicht stimmt. Neuer != besser. C++ ist in erster Linie _anders_ als C.
C ist als Sprache, um einen Kernel zu schreiben, wesentlich besser
geeignet als C++. Der produzierte Code ist effizienter, das
Speicherverwaltungsmodell arbeitet mit weniger Overhead, und das
klassische Argument, C++ sei objektorientiert und deshalb überlegen, ist
auch nicht richtig. Einerseits ist objektorientierte Programmierung kein
Allheilmittel (es gibt viele Problemstellungen, wo es geradezu pervers
wäre aus technischer Sicht, objektorientiert zu arbeiten), andererseits
kann man auch in C objektorientiert arbeiten. Tatsache ist: Große Teile
des Kernels, gerade die höher abstrahierten Systeme, arbeiten
objektorientiert, nur halt in C statt in C++.
Selbstverständlich sind mir die Vorteile von C++ bekannt, und sie sind
der Grund, warum ich Projekte mit GUI lieber in C++ schreibe als in C.
Aber man muss auch die Nachteile von C++ sehen, die ich oben genannt
habe, und diese sind bei zentral performancerelevanten Einheiten wie dem
Betriebssystemkernel einfach nicht beiseite zu schieben.
Fazit: Fortschritt ist wichtig, "Fortschritt" um jeden Preis (== alles
wegwerfen, sobald etwas Neueres auf den Markt kommt, egal ob das Neuere
besser ist als das Ältere) ist unsinnig. Die letztere Einstellung hat
zum Beispiel dazu geführt, dass heutzutage so viele Projekte in Java
geschrieben werden, für die dieser Performancekiller absolut
unangemessen ist - einfach nur, weil Java die neueste Sprache unter den
Großen ist.
> Wahrscheinlich reitest du jeden morgen noch mit
> einem Pferd duch die Stadt und hälst die Maus für Teufelszeug. Euch
> schmeißt man hoffentlich bald mitsamt euren Stuhl auf dem ihr klebt aus
> der IT damit es endlich wieder vorangeht. Nur Steinzeitprogrammierer und
> Kaputtadministrierer findet man bei Linux.
Ich denke, bei einem großen Anteil der Mitglieder dieses Forums hat
dieser Absatz zu einem kurzen, aber knackigen *plonk* geführt. Und ich
kann es ihnen nicht übelnehmen - so ein Schreibstil ist wirklich
unangemessen. Man kann ja über alles reden, aber bitte mit einer Portion
Respekt und Anstand.
Grüße,
Maik Zumstrull
Joern Ahrens
Maik Zumstrull <Maik.Zu...@gmx.de> schrieb am Mit, 12 Mär 2003 um 16:48 GMT:
> Ich denke, bei einem großen Anteil der Mitglieder dieses Forums hat
> dieser Absatz zu einem kurzen, aber knackigen *plonk* geführt. Und ich
> kann es ihnen nicht übelnehmen - so ein Schreibstil ist wirklich
> unangemessen.
Hast recht mit dem Plonken ;-) Der Kerl geht mir schon länger auf den
Sack.
Zu Deinem Geschriebenen zu den Unterschieden von C und C++ kann ich nur
sagen: ACK. Es wäre auch ein ganz ordentlicher Aufwand den Kernel jetzt
auf einmal in C++ zu schreiben..
Gruß,
Jörn
--
/// Jörn Ahrens <jahr...@gmx.de> - PGP: 1024D/216C1D08
(o o) http://stud.fh-wedel.de/~ii4820/
-oOO--(_)--OOo- ICQ: 97822080
Mathias Goldau
> Wir entfernen uns völlig vom eigentlichem Thema dieses Threads ...
[OT]? Na gut: Einen Neuen aufmachen, Gruppe wechseln?
> Mathias Goldau <fun...@web.de> writes:
>> Holger Schauer wrote:
>>> Mathias Goldau <fun...@web.de> writes:
>>>> 1. Schleifen sind meißt besser, das sie den Stack nicht voll
>>>> müllen. Also im Bezug auf Performance.
> [...]
>>> Beliebtes Stichwort in dem Zusammenhang: Endrekursion.
>> Es ging doch darum Schleifen funktional auszudrücken. Diese mußt du erst
>> rekurisv programmieren. So. Es gibt ja verschiedene Rekusionen
>> unteranderem verneste siehe Ackermann.
>
> Ja, solche Fälle gibt es. Your point being?
> (Man beachte den oben gequoteten Kontext).
diesen Zweig noch mal zusammengefasst: Angefangen hatts mit:
C vs C++, und das man mit C auch OO programmieren könne, worauf ich meinte:
"na toll, das ist ja genauso kompliziert wie funktional zu programmieren."
Worauf die Frage kam warum funktional? DARAUF sagte ich dann: <<1.
Schleifen usw...>> und deswegen nacher noch mal: <<Es ging doch darum
Schleifen funktional auszudrücken...>> Weil das Argument, das Schleifen im
funktionalen schwierig sein können, nicht klar war. Dies wollte ich dann an
einem Beispiel verdeutlichen.
Was ist genau unklar?
>> Können heutige Compiler solch krasse Rekursionen auflösen?
>> (Theoretisch kann man ja jede Rekursion in Schleifen überführen)
>> Wenn das auch praktisch geht dann stimmt mein Argument 1 nicht mehr
>
> Dein Argument aus 1 stimmt so oder so nicht. Es gibt reichlich
> bescheidene iterative Lösungen für viele Probleme, die mit Rekursion
> eleganter zu lösen wären. Es ist einfach Quatsch, Rekursion standepede
> zu verteufeln, so wie Du es hier getan hast.
Hab ich doch nicht! Ich sagte ***meißt*** sind Scheifen besser. *Natürlich*
gibt es auch bescheidene iterative Lösungen, die gibt es immer und überall.
Ich denke aber nicht das es Probleme gibt die rekursiv *besser* zu lösen
wären als iterativ => Eleganter ja, Performance nein.
>>>> 2. Hat man eine Schleife indem viele Variablen dann incrementiert o.ä.
>>>> werden, muß man die alle mit in die Signatur aufnehmen, da es ja keine
>>>> Variablen wie im imperativen Sinne gibt (nur eine Wertzuweisung je
>>>> ''Variable'').
>>> Hmm? Stichworte hier sind Kontextargumente und Akkumulatoren.
>> Ja im Compilerbau(-optimierung), nicht in der Implementation der
>> Rekursion in $fkt-Sprache, da Akkumulatoren als Sprachelemente nicht in
>> das Konzept von funktionalen Sprachen passen.
>
> Ich weiss nicht, was Du unter Akkumulatoren verstehst, aber ich
> verstehe darunter wahrscheinlich etwas anderes als Du. Akkumulatoren
> sind der typische funktionale Sammeleimer für das von Dir ange-
> sprochene Problem.
>
> (defun add (x y)
> (labels (add-acc (x y result)
> (when (= y 0)
> result)
> (add-acc (x (- y 1) (+ result 1)))))
> (add-acc x y 0))
Ich verstehe unter einem Akkumulator einen Speicherplatz indem zu Beginn
einer binären Operation ein Operand steht und zum Schluss das Ergebniss.
Nicht die Emulation eines solchen. Der Operand also überschrieben wird.
Funktionalesprachen können dass nicht richtig da Variablen nur einmal
gebunden werden können!
Mein eigentliches Beispiel mit dem incrementieren usw. kam daher: Ich hatte
mal ne Funktion zu programmieren, bei der ich einige Zwischenergebnisse mit
in die Signatur aufnehmen mußte um sie nicht zu verlieren. Ich finds nicht
mehr und mir fällt jetzt auch kein anderes ein. Vielleicht hab ich damals
zu schlecht programmiert, und du hast recht das sowas nicht sein muß.
>>> Was hat Prolog mit funktionalen Sprachen zu tun? Und warum sollte
>> Prolog ist auch eine! UND außerdem eine Logikorientierte.
>
> Du verdrehst die Tatsachen. Prolog ist in aller erster Linie eine
> deklarative Sprache. Wenn man fies sein möchte, kann man in Prolog
> problemlos nicht-funktional programmieren. Stichwort: assert und
> retract als globale Variablen missbrauchen. Man kann in jeder Sprache
> Fortran programmieren.
Ok, mich hat wahrscheinlich Prolog nur zu sehr an Erlang erinnert. Sorry.
Und jetzt bitte nicht: Was hatt Erlang mit OO zu tun dann krieg ich nen
Komplex ;-)
>>> Prolog nicht eingesetzt werden? Ich kenne zudem mind. zwei
>>> Prologimplementationen, die es erlauben, auch recht Hardware-nah zu
>>> programmieren (ich weiss aber nicht mehr, ob das nur über den Umweg
>>> von Einbindung von Assemblercode ging, oder auch auf anderem Wege).
>> Ahhh... das würde mich aber mal brennend interessieren. Keine URL mehr?
>
> Ich bin recht sicher, dass das mit Amzi-Prolog ging/geht (falls die
> noch existieren). Ich meine, Sicstus oder Eclipse Prolog konnte das
> auch. Selbst SWI hat mittlerweile eine C-Schnittstelle, die auf den
> ersten Blick recht mächtig aussieht.
Danke, obwohl mich der Umweg mehr interessiert hätte (evtl. Sprachintern).
mat*hoffentlich klärend wirkend*hias
--
mail: fun...@web.de
Maik Zumstrull
> Es wäre auch ein ganz ordentlicher Aufwand den Kernel jetzt
> auf einmal in C++ zu schreiben..
Es gab zwei Versuche in der Richtung:
1) Eine Gruppe von Leuten hat sich mal vorgenommen, den Kernel nach C++
zu portieren.
2) Jemand hat mal vorgeschlagen, wenigstens so viel C++-Abstraktion im
Kernel bereitzustellen, dass man wenigstens Third-Party-Kernelmodule in
C++ schreiben kann, wenn man will.
1 haben diese Leute angefangen, aber recht schnell wieder aufgegeben,
weil sie merkten: Tierisch aufwändig, und benutzen würde es hinterher
sowieso keiner.
2 hat Linus verweigert, weil sehr aufwändig, aber aus seiner Sicht keine
erkennbaren Vorteile.
Grüße,
Maik Zumstrull
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > Es gibt auch verschiedene Möglichkeiten, verkettete Listen zu
> > implementieren (zB mit einer array-Repräsentation). Bevor man
> > 'abstrakte Datentypen' kreativ verwendet, sollte man mE erst mal
> > darüber nachdenken, welche Operationen man eigentlich konkret
> > durchführen möchte und ob das nicht auch einfacher geht (mit
> > 'einfacher' ::= 'erfordert weniger Hintergrundwissen zum Verständnis'
> > in diesem Fall).
>
> Genau das ist das Problem: 100%-\epsilon der Faelle ist es voellig
> wurscht, welche konkrete Implementation hinter der Fassade steckt.
Falls ich mal einen 'professionellen' Programmierer treffen sollte,
der mir nicht spätestens im zweiten Atemzug erklärt, daß es ihm
scheißegal ist, wie seine Programme aussehen, weil er nach Stunden
bezalht wird, würde mich das enorm erleichtern.
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > Es gibt auch verschiedene Möglichkeiten, verkettete Listen zu
> > implementieren (zB mit einer array-Repräsentation). Bevor man
> > 'abstrakte Datentypen' kreativ verwendet, sollte man mE erst mal
> > darüber nachdenken, welche Operationen man eigentlich konkret
> > durchführen möchte und ob das nicht auch einfacher geht (mit
> > 'einfacher' ::= 'erfordert weniger Hintergrundwissen zum Verständnis'
> > in diesem Fall).
>
> Genau das ist das Problem: 100%-\epsilon der Faelle ist es voellig
> wurscht, welche konkrete Implementation hinter der Fassade steckt.
> Es gibt nach dem "gesunden Menschenverstand" immer eine halbwegs
> vernueftige erste Naeherung (z.B. Container mit oder ohne Einfuegen
> in der Mitte == liste oder array)
Die Annahme, daß Computer so etwas ähnliches sein müßten, wie Frauen,
ist falsch.
Rainer Weikusat
> Rainer Weikusat wrote:
> > Die Nullen sind Programm, wie zu erwarten. Du darfst das Projekt
> > aufgeben, da wird nichts draus werden
> Meine Glaskugel hat gesagt: Deine hat Unrecht. Lese den Thread doch nochmal
> von Anfang an und bemerke das Du nur so daher-laberst.
Du mußt nicht alles verstehen, was ich sage.
> > Noch mal für Schnellmerker mit einer überhöhten Einschätzung der
> > eigenen (Un-)fähigkeiten: Language wars sind Abfall.
>
> Natürlich und Weiterentwicklung ist auch Unsinn.
Es findet hier keine Weiterentwicklung statt.
> >> Manche Leute laufen in ihrer Freizeit hinter einem Ball her, und ich
> >> würde es nicht unbedingt als bescheuert bezeichnen. Du rettest also in
> >> deiner Freizeit nur bedrohte Tiere oder tust sonst was nur
> >> nicht-bescheuertes? Oder wieso kannst DU darüber urteilen, wie
> >> sinnvoll die Freizeitgestaltung anderer menschen ist? Aber Toleranz
> >> und soziale Kompetenz scheinen eh nicht zu deinen Stärken zu
> >> gehören.
> >
> > Lieber Pisser, ich habe so gut wie keine Freizeit und während der
> > werde ich nicht auch noch vor einem Computer sitzen. Den Begriff
> > »Toleranz« möchtest Du im übrigen nachschlagen. Er bedeutet das
> > Gegenteil von dem, was Du in obigem Absatz auszudrücken versuchst.
> Du willst Tolleranz deiner Urteile? Nein irgendwann ist eine Grenze
> erreicht! Jetzt.
'Tolerzanz' bedeutet, anderen ihre Meinungen zu gestatten, *nicht*
selber keine zu haben.
> > gewohnheitsmäßig jeden Tag +10h arbeitest (größtenteils unbezalht)
> > darfst Du noch mal wiederkommen und mir von Deiner Großartigkeit
> > erzählen.
> Eine Dose Mitleid für dich! (ein große)
Dein Mitleid ist soviel wert, wie Du.
Rainer Weikusat
Dein Mitleid ist soviel wert wie Du.
Immo 'FaUl' Wehrenberg
> Mathias Goldau <fun...@web.de> writes:
>> In was ist eigentlich der HURD-Kernel geschrieben?
> Emacs Lisp.
ROTFL, darf ich das sig'en?
FaUl
end
This article does not support incompatible and broken newsreaders.
--
Am Ende kommst du mir noch mit der Theorie, daß die Erde gar nicht der
Mittelpunkt des Universums ist! Lächerlich. Ketzern wie dir wünsche
ich manchmal, daß sie vom Rand der Erdscheibe herunterfallen!
[Felix von Leitner in dasr]
Immo 'FaUl' Wehrenberg
> Immo 'FaUl' Wehrenberg schrieb:
>> Warum sollte man C++ verwenden?
> Im ein oder anderen Fall könnte es mit Objektorientierung vielleicht
> einfacher / effizienter zu entwicklen sein.
Dann sollte man vieleicht besser kein C++ benutzen?
FaUl
end
This article does not support incompatible and broken newsreaders.
--
okay, have a sig then
Immo 'FaUl' Wehrenberg
> Eugen Ernst wrote:
> Ich denke, bei einem großen Anteil der Mitglieder dieses Forums hat
> dieser Absatz zu einem kurzen, aber knackigen *plonk* geführt.
Gab es ernsthaft noch jemanden ausser dir hier, der Herr Ernst noch nicht
geplonkt hat?
Rainer Weikusat
> Nun kann ich bei sowas wie linearen Listen natürlich auch STL
> benutzen, und habe dann mit wenigen Handgriffen die Möglichkeit, eine
> Implementation, die einen Faktor 3 langsamer ist, mit einer zu
> ersetzen, die einen Faktor 2.5 langsamer ist...
Der resultierende Code bleibt dann aber um einen Faktor neun
komplizierter. Als ich das letzte mal C++ geschrieben habe, bin ich
»wieder mal« prompt mit einem g++-Fehler kollidiert (ich muß
allerdings zugeben, daß ich unter C++ nicht primär die STL verstehe und
deswegen einen Hang dazu habe, Sprachfeatures auch wirklich benutzen
zu wollen :->). Nach zwei Tagen »frantic debugging« bin ich den in
der Assembler-Ausgabe suchen gegangen und habe ihn relativ schnell
gefunden. Ich kenne den (Quell-)Code der SGI-STL ein bißchen und damit
möchte ich das wirklich nicht machen müssen.
> Bei komplexerer Funktionalität kann die Kapselung dann aber schon
> praktischer sein.
Ich bin mir sicher, daß jeder hier mit den »üblichen«
(C++)-OO-Einführungsliteratur vertraut ist (dh mit all diesen
schwachsinnigen Beispielen mit Zootieren, Telephonen, Kreisen und
Punkten). So unbrauchbar die scheinen mögen, illustrieren sie
doch einen wichtigen Punkt: Man sollte das modellieren, was man
abbilden möchte und nicht die Art, wie man das zu tun gedenkt. Die
Programme werden dann einfacher, kleiner, portabler und normalerweise
auch schneller.
Am Rande: Ich wäre dankbar, wenn man mich mit weiteren Ausbrüchen von
'aber ich spare doch Arbeitszeit, wenn ich bereits geschriebenen Code
zurechtbiege' etc pp zu verschonen. Kommerzware ist, um Felix zu
zitieren, »legendär schlecht« und das ist einer der Gründe dafür.
Rainer Weikusat
> Bernhard Lutzer <gigama...@web.de> wrote:
> > Christian Helmbold wrote:
> >> soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
> >> nicht C++ geschrieben.
> > Korrekt. Nur einige Zeilen sind Assembler.
> >> Ist das einfach historisch so gewachsen, oder
> >> gibt es einen Grund dafür, dass C statt C++ verwendet wird?
>
> Es gibt eine Menge Programmierer, die C++ nicht allzusehr moegen.
> C++ ist irgendwie "weiter von der Maschine weg" als C.
Das ist Unsinn. Es gibt eine Menge Leute, die kein C++ verstehen (und
es leider trotzdem zu verwenden versuchen :-(, vgl Qt) und der Teil
davon, der es nicht trotzdem benutzt, hat eine beliebig große Menge
von Phantastereien parat, warum das eine objektiv sinnvolle
Entscheidung war, aber die lassen sich meiner Meinung nach alle auf
»Ich kanns nicht (und sehe keinen Grund, es zu lernen)« zurückführen.
Das ist eigentlich immer der eigentlich Grund, sobald jemand anfängt,
mit »objektiven Begründungen« ultimativ zu fordern, das in Zukunft
alle gefälligst nur noch die Sprache benutzen sollten, die er/sie/es
zufällig erlernt hat.
Rainer Weikusat
> Juergen Ilse schrieb:
> > Ausserdem hat das sicherlich auch historische Gruende,
> > denn zu Zeiten der ersten Linux-Kernel war der Gnu-C++
> > Compiler noch lange nicht auf dem heutigen Stand
>
> Und genau deswegen bleiben alle bis in alle Ewigkeit bei C und
> schreiben Umlaute mit ae.
Es gibt Leute, die Tastaturen mit amerikanischer Tastenbelegung haben,
weil das einfacher ist, als ständig umzudenken, wo jetzt welche Tasten
liegen. Es wird allerdings niemand annehmen, daß Du für deren Arbeit
qualifiziert wärest.
> einem Pferd duch die Stadt und hälst die Maus für Teufelszeug.
[...]
> schmeißt man hoffentlich bald mitsamt euren Stuhl auf dem ihr klebt aus
> der IT damit es endlich wieder vorangeht.
Die Maus ist eine Erfindung von 1977.
Immo 'FaUl' Wehrenberg
> "Eugen Ernst" <Er...@gmx.com> writes:
>> Juergen Ilse schrieb:
>> > Ausserdem hat das sicherlich auch historische Gruende,
>> > denn zu Zeiten der ersten Linux-Kernel war der Gnu-C++
>> > Compiler noch lange nicht auf dem heutigen Stand
>>
>> Und genau deswegen bleiben alle bis in alle Ewigkeit bei C und
>> schreiben Umlaute mit ae.
>
> Es gibt Leute, die Tastaturen mit amerikanischer Tastenbelegung haben,
> weil das einfacher ist, als ständig umzudenken, wo jetzt welche Tasten
> liegen. Es wird allerdings niemand annehmen, daß Du für deren Arbeit
> qualifiziert wärest.
Ausserdem gibt es nirgendwo ein De-Dvorak-Layout (jedenfalls ist es nirgendwo
standardmaessig drauf, und ich kenne es auch nicht). Trotzdem waehre es
nett wenn man jetzt aufhoeren wuerde Eugen zu fuettern.
Vielen Dank fuer eure Mithilfe.
FaUl
end
This article does not support incompatible and broken newsreaders.
--
"Manche Benutzer haben immer Viren und manche Benutzer haben nie
Viren." (Detlef Bosau)
Rainer Weikusat
> Der Argumentationslinie stimme ich absolut zu. Nur: Sie greift an dieser
> Stelle nicht, weil die Aussage, C++ wäre ein "Fortschritt" gegenüber C
> nicht stimmt. Neuer != besser. C++ ist in erster Linie _anders_ als C.
> C ist als Sprache, um einen Kernel zu schreiben, wesentlich besser
> geeignet als C++. Der produzierte Code ist effizienter,
Unsinn.
> das Speicherverwaltungsmodell arbeitet mit weniger Overhead,
Leider ist obiger Begriff nicht mehr steigerbar. Man darf vermuten,
daß dieser Unsinn »irgendwie« aus der Existenz von temporaries
herausmutiert ist, Entsprechungen in der Realität hat er keine.
> Aber man muss auch die Nachteile von C++ sehen, die ich oben genannt
> habe,
Die sind fiktiv. Es gibt für C wenigstens genauso monströse
Bibliotheken wie für C++, einschließlich grotesk wirkender Stilblüten
wie
gpointer
typedef void* gpointer;
An untyped pointer. gpointer looks better and is easier to use
than void*.
(<URL:http://developer.gnome.org/doc/API/2.0/glib/glib-Basic-Types.html#gpointer>)
und damit bekommt man auch alle »Vorteile« von C++ bzgl Duplosteinen.
> zum Beispiel dazu geführt, dass heutzutage so viele Projekte in Java
> geschrieben werden,
Nein, dazu führt, wie David richtig bemerkt hat, die Tatsache, das so
gut wie niemand, der auf diesem Gebiet »ausbildet« (einen grausigeren
Euphemismus kann man sich kaum vorstellen) mehr als oberflächlich mit
maschinennaher Programmierung vertraut wäre und außerdem idR einen
tiefen Widerwillen dagegen hat -- »zuviel Arbeit«.
> für die dieser Performancekiller absolut unangemessen ist
Das Problem bei Java ist weniger die Ablaufgeschwindigkeit der
Programme, sondern vor allem der memory footprint. Daher (vermutlich)
auch die extrem langen Ladezeiten.
> - einfach nur, weil Java die neueste Sprache unter den
> Großen ist.
Es ist die mit dem umfangreichsten Repertoire an Formteilen, deren
Komplexität nicht wesentlich über C hinausgeht.
Rainer Weikusat
> Bernhard Lutzer <gigama...@web.de> wrote:
> > Christian Helmbold wrote:
> >> soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
> >> nicht C++ geschrieben.
> > Korrekt. Nur einige Zeilen sind Assembler.
> >> Ist das einfach historisch so gewachsen, oder
> >> gibt es einen Grund dafür, dass C statt C++ verwendet wird?
>
> Es gibt eine Menge Programmierer, die C++ nicht allzusehr moegen.
> C++ ist irgendwie "weiter von der Maschine weg" als C.
Das ist Unsinn. Es gibt eine Menge Leute, die kein C++ verstehen (und
es leider trotzdem zu verwenden versuchen :-(, vgl Qt) und der Teil
davon, der es nicht trotzdem benutzt, hat eine beliebig große Menge
von Phantastereien parat, warum das eine objektiv sinnvolle
Entscheidung war, aber die lassen sich meiner Meinung nach alle auf
»Ich kanns nicht (und sehe keinen Grund, es zu lernen)« zurückführen.
Das ist eigentlich immer der Grund, sobald jemand anfängt, mit
André Pönitz
> C ist als Sprache, um einen Kernel zu schreiben, wesentlich besser
> geeignet als C++. Der produzierte Code ist effizienter, das
> Speicherverwaltungsmodell arbeitet mit weniger Overhead
Das ist, wie schon mehrfach gesagt, Unsinn, da fast jedes C-Programm ein
gueltiges C++-Program ist.
Die Frage ist, ob C++ tatsaechlich _zusaetzliche_ Vorteile bringt. Und
da gibt es durchaus moegliche Kandidaten (Templates, kontrollierte Freigabe
von Ressourcen durch Destruktoren, evtl. Exceptions)
Das Problem ist, dass C++ immer als "C mit toller Vererbung" verkauft wird
und haeufig so programmiert wird - insbesondere von Leuten, die mit kaputten
Compilern aufgewachsen sind, oder C++ vor zehn Jahren "gelernt" und seit
dem nicht angeschaut haben, oder die in die Java-Tasse gefallen sind, oder
(das sind in der Regel die, die am lautesten schreien), es nie verwendet
haben.
Und genau das ("C mit toller Vererbung") ist Kacke. Wenn jemand einen
Schraubenzieher zum Einschlagen einer Schraube benutzt anstatt sie
einzudrehen, ist das aber kein Problem des Schraubenziehers, sondern des
Benutzers.
> und das klassische Argument, C++ sei objektorientiert und deshalb
> überlegen, ist auch nicht richtig. Einerseits ist objektorientierte
> Programmierung kein Allheilmittel (es gibt viele Problemstellungen, wo es
> geradezu pervers wäre aus technischer Sicht, objektorientiert zu
> arbeiten),
Es gibt immer zwei Aspekte bei der Objektorientierung: Kapselung und
Hierarchien. Ersteres halte ich fast uneingeschraenkt fuer wuenschenswert,
letzteres sicher nicht...
André Pönitz
> Für größere Funktionalität kannst Du nicht den Wasserkopf von
> hunderten Instanzen rumschleppen.
Kommt drauf an. Die Werkzeugkiste ist gross.
Du kannst z.B. die Templates fuer "alle Zeiger" spezialisieren und intern
nur einen void * nehmen, nach draussen aber Typsicherheit garantieren.
Das gleiche geht allgemeiner fuer PODs mit gleichem sizeof(). Besser kommst
Du auch in C nicht weg, im Gegenteil, Du verlierst in aller Regel noch
Typsicherheit durch das Getrickse.
> Irgendwann muß man halt einen Schnitt machen und auf virtuelle
> Basisklassen ausweichen. Und dieser Schnitt ist nicht gerade übermäßig
> unauffällig zu bewerkstelligen.
"Muss" ist selten. Sehr selten.
Es wird leider viel zu haeufig gemacht. Ich hab hier ein 70kloc
"Spassprojekt", das kein einziges 'virtual' enthaelt.
> Musterbeispiele sind ja etwa Sortierroutinen. Die kann man nicht nur
> auf dem Zieltype templatisieren, weil ja verschiedene Sortierkriterien
> anfallen können. Also muß man auch noch auf einer
> Vergleichsfunktion/Operator templatisieren.
Genau das macht std::sort().
> Auf einen Integervergleichsoperator kann ich aber nicht gerade einen
> Funktionspointer als Templateargument rekrutieren.
s/Auf/Aus/ ?
struct comparer { bool operator()(int a, int b) { return whatever(a,b); } };
[Irgendwas in der Richtung boost::function<bool(int, int)> = whatever;
geht glaub' ich auch, aber ich bin ja auch schon aelter...]
Btw: im Ergebnis ist std::sort() ungefaehr doppelt so schnell wie qsort(),
weil qsort die Aufrufe der Vergleichsroutinen nicht inlinen kann und diese
bescheuerten -1/0/1 Unterscheidung haben will...
> Generelle Sortierkriterien brauchen auch eventuell zusätzliche
> Parameter/Datenstrukturen, die man dann bei rekursiven Aufrufen auch
> weitergeben müßte. Die in statischen Variablen zu verstauen, ist
> keine Lösung, weil nicht reentrable, threadsicher etc.
>
> Wenn Du willst, kann ich Dir mal eine Sortierroutine für lineare
> Listen schicken, die ich in C plus Präprozessor geschrieben habe.
Mach mal.
> Daß die Regeln dann aber vollkommenes Chaos anrichten, wenn man etwa
> einen komplexen Restklassenarithmetiktyp damit bastelt, bei dem eine
> automatische Konversion über den Umweg "double" tödlich wäre, ist
> dabei unter den Tisch gefallen.
Naja, operator double() implementiert man auch nur im Notfall. Dass es an
dieser Stelle kein 'explicit' wie fuer Konstruktoren gibt, halte ich echt
fuer eine Schwaeche der Sprache. Andererseits hindert Dich ja niemand das
als 'double as_double()' o.ae. zu implementiern. Das wird sicher nie "aus
Versehen" genommen.
> Ein weiteres Unding ist die _Syntax_ von Templates, die recht
> unreflektiert von Adas generics geklaut wurde, wo die Spitzklammern
> als Typenconstraints sich in ein sinnvolles Konzept einfügen. In
> einer C-basierten Syntax ist das aber ziemlicher Unfug, schon allein
> weil >> ein Shiftoperator ist. Weiterhin verursacht es erhebliche
> Merkwürdigkeiten im Zusammenspiel zwischen Präprozessor und templates.
Naja. C-Syntax ist auch gewoehnungsbeduerftig. Und so viele moegliche freie
Klammerpaare gibt's auch nicht...
> Oftmals wird eine Klasse nur als syntaktischer Bezugspunkt
> eingerichtet, was auch Sinn macht. Dennoch kann ich beispielsweise
> überladene arithmetische Operatoren nicht als static deklarieren, so
> daß sie nicht ohne sinnlose Instantation und herumreichen eines
> unnötigen this-pointers auf ein ungenutztes Objekt einsetzbar sind.
?
Versteh ich ohne Beispiel nicht.
> C++-Parser sind praktisch nicht fehlerfrei hinzukriegen, jeder hat
> seine eigene Liste von Fehlerquellen und ein korrekter Parser kann
> praktisch nur von Hand geschrieben werden.
Kann man nix dagegen sagen.
> Für einen Kernel oder andere Projekte mit massiv verteilten Autoren
> und Kompetenzen ist nach meiner Ansicht die Sprache mit erheblicher
> Vorsicht zu genießen. Sie ist erheblich unberechenbarer als C in den
> Auswirkungen auf den konkreten Code, und vor allen Dingen macht sie es
> einem auch sehr leicht, Features in einer Art und Weise zu benutzen,
> von der man aus Rücksicht auf geistige Gesundheit,
> Compilerabhängigkeit und Wartbarkeit besser abgesehen hätte.
Das Risiko, dass kranke Programmierer kranken C++ Code erzeugen, scheint
tatsaechlich groesser zu sein als fuer C.
Das ist aber ein soziales Problem. Bislang wird ja versucht, C++ aufgrund
technischer Probleme ("langsamere Code" etc) zu disqualifizieren.
André Pönitz
> Java ist doch ok.: (bis auf Schnelligkeit):
> Garbage-Coll., ab 1.5.x sollen dann die Generics==Templates kommen
Java ist genau das Subset von C++, dass in Kernel-Naehe absolut untauglich
ist.
Eugen Ernst
> C ist als Sprache, um einen Kernel zu schreiben,
> wesentlich besser geeignet als C++.
Viele Entwickler scheinen zu glauben, wenn man in C++ programmiert, dann
muß man auch wirklich alle vorhandenen Features der Sprache irgendwie in
das Projekt verbauen, nur damit man die Vorteile der Sprache ausgenutzt
hat. Da werden Templateklassen entworfen, die nur ein einziges mal
gebraucht werden, da werden Classfactory's implementiert, obwohl von der
fachlichen Anforderung eine Umstellung an dieser Stelle niemals
vorkommen kann, da werden ganze Klassenbäume mit virtuellen Basisklassen
und Ableitungen aufgebaut (insgesamt 59 Klassen!) um einen String zu
erzeugen, was durch eine einfache Schleife in 2 Seiten Code ohne eine
einzige Klasse auch gelöst werden konnte.
Wenn man sich von dieser Idiotie leiten lässt, dann ist C++ tatsächlich
ungeeignet. Aber nicht weil C++ schlecht ist, sondern weil die
Entwickler einfach zu dämlich sind. Es gibt eine nette Menge an
Erweiterungen in C++ mit welchem man den Code einfacher strukturieren
kann, mit welchem vieles klarer wird und letztenendes genauso performant
ist.
Und wenn es an einer bestimmten Stelle nicht performant genug ist, kann
man es immer noch über C und Assembler lösen. Aber man kann gleichzeitig
an vielen anderen Stellen mit bedacht die Vorteile von C++ einsetzen,
was man in reinem C hat.
Man muß eben wissen was man macht. Und bei vielen liegt der Verdacht
nahe, daß sie eher von Unwissenheit, Unerfahrenheit und Starrsinn
geleitet werden, weil sie eben nicht wissen, wie man mit den
"Neuerungen" umzugehen hat. Statt dessen wird dann alles verteufelt und
gemauert, nur um zu verhindern, daß man nochmal "umlernen" muß. Aber wer
in der heutigen IT zu faul (oder zu blöd) ist um nochmal umzulernen, der
soll sich lieber gleich verpissen und nicht die anderen bei der Arbeit
aufhalten.
Zum Glück kann man sagen, daß es zumindest bei C++ egal ist, diese
konnte ja nicht wirklich von den Fortschrittsverweigerern verhindert
werden. Tatsächlich ist es ja so, daß C++ schon wieder auf dem
absteigenden Ast ist und eigentlich nur noch in irgendwelchen
Sonderbereichen benötigt wird. Für 95% alle Applikationen macht Java
oder .Net mehr Sinn.
Aber da sind wir dann beim gleichen Thema wie mit C und C++, da wird
dann wieder alles mögliche behauptet, nur um zu verhindern, daß man sich
was Neues ansehen muß, bzw. wieder einmal "umlernen" muß. Gerade die
Unixstinkstiefel, die sich bis heute nicht an eine Maus gewöhnen konnten
sind doch da schon wieder am rumgreinen.
Java und .Net wird nicht verwendet, weil es modern ist, sondern weil die
meisten Entwickler zu blöd für C/C++ sind. So sieht es doch aus. Und die
Oberblöden beharren im Jahr 2003 immer noch auf C. Geht nach Hause,
poliert euren 386, aber tut mir den Gefallen, müllt das Usenet, das
Internet oder eure armen Bekannten nicht weiter mit eurem kleingeistigen
Quatsch zu.
> Ich denke, bei einem großen Anteil der Mitglieder dieses Forums
> hat dieser Absatz zu einem kurzen, aber knackigen *plonk* geführt.
Das geht mir irgendwo vorbei, ob mich hier ein paar Hobbylinuxadmins
plonken oder nicht. Freiwillige Selbstzensur ist nun wirklich nicht mein
Problem.
mfg
Eugen
David Kastrup
> Juergen Ilse <il...@news.pop-hannover.de> writes:
> > Bernhard Lutzer <gigama...@web.de> wrote:
> > > Christian Helmbold wrote:
> > >> soweit ich weiß, ist der Linux-Kernel (und noch einiges andere) in C und
> > >> nicht C++ geschrieben.
> > > Korrekt. Nur einige Zeilen sind Assembler.
> > >> Ist das einfach historisch so gewachsen, oder
> > >> gibt es einen Grund dafür, dass C statt C++ verwendet wird?
> >
> > Es gibt eine Menge Programmierer, die C++ nicht allzusehr moegen.
> > C++ ist irgendwie "weiter von der Maschine weg" als C.
>
> Das ist Unsinn.
Sagen wir einmal: der Abstand von der Maschine ist mitunter bei C++
schwer einzuschätzen. Bei C hat man noch eine gut vorstellbare
Beziehung zwischen Quellcode und Maschinencode. Setzt man etwa "-O0"
als Optimierungsoption von gcc ein, rechnet man mit einer gewissen
einschätzbaren Verlangsamung. Bei C++ muß man damit rechnen, daß
"-O0" das Programm komplett unbrauchbar verlangsamt, weil die Zahl von
temporaries und Funktionsaufrufen ins unermeßliche steigen. Das
Laufzeitverhalten _und_ der Speicherbedarf ist erheblich stärker vom
Compiler abhängig.
> Es gibt eine Menge Leute, die kein C++ verstehen (und es leider
> trotzdem zu verwenden versuchen :-(, vgl Qt) und der Teil davon, der
> es nicht trotzdem benutzt, hat eine beliebig große Menge von
> Phantastereien parat, warum das eine objektiv sinnvolle Entscheidung
> war, aber die lassen sich meiner Meinung nach alle auf »Ich kanns
> nicht (und sehe keinen Grund, es zu lernen)« zurückführen.
Ich habe mich schon mit Stroustroup rumgestritten, als C++ noch nicht
eine ANSI-Norm war. Und wenn Du auf Fragen der Sorte "warum sind
overloaded operators nur als non-static member functions zulässig?
Diese Einschränkung erfüllt keinen Zweck, ist für diese und jene
Problemstellung sehr lästig, steht im Gegensatz zu anderen
Memberfunktionen und muß deswegen im Compiler extra implementiert
werden, um dem Benutzer das Leben schwer zu machen" dann vom
_Designer_ der Sprache die Antwort "Keine Ahnung. Wir haben nicht
gesehen, wozu man das brauchen könnte, also haben wir es einfach mal
verboten und es wäre lästig, das noch zu ändern.", dann fördert das
nicht gerade das Vertrauen in das Design der Sprache.
Zu verschiedenen Eigenheiten der C++-Syntax habe ich mich ja schon
geäußert.
Es steht Dir frei zu vermuten, daß ich C++ nicht verstehe, aber
zumindest habe ich es hinbekommen, damit eine Studienarbeit zu
machen, bei der ich denselben Code für schnelle Faltungen mit
komplexer Arithmetik wie mit zahlentheoretischen Transformationen
über einer entsprechend implementierten arithmetischen Klasse nehmen
konnte
<URL:http://www.neuroinformatik.ruhr-uni-bochum.de/ini/PEOPLE/dak/studie.ps.gz>.
a> Das ist eigentlich immer der Grund, sobald jemand anfängt, mit
> »objektiven Begründungen« ultimativ zu fordern, das in Zukunft alle
> gefälligst nur noch die Sprache benutzen sollten, die er/sie/es
> zufällig erlernt hat.
Das sage ich ja gar nicht. Ich sage lediglich, daß ich C++ als
Sprache für so chaotisch, inkonsistent und komplex halte, daß ich auf
ihre Verwendung dort verzichten würde, wo man das kann.
Auch als Sprache für Lehrzwecke (Informatikstudium etc) halte ich sie
für ungeeignet, da sie viel zu wenig "aus einem Guß" ist. Für jede
neue Kleinigkeit braucht man wieder ein neues Idiom, das vollkommen
anders aussieht als das letzte.
Ich mag ein Trottel sein, der zu dämlich ist, C++ richtig zu verstehen
und damit umzugehen. Aber eine Programmiersprache ist letztlich ein
Werkzeug. Und ein gutes Werkzeug zeichnet sich eben dadurch aus, daß
auch ein Trottel damit umgehen kann, ohne daß es anspruchsvolleren
Anwendungen im Wege steht, und ohne daß man es separat auf
"anspruchsvolle" Trickkisten umschalten müßte. Ein Werkzeug ist
nicht Selbstzweck.
Thomas Orgelmacher
> Aber da sind wir dann beim gleichen Thema wie mit C und C++, da wird
> dann wieder alles mögliche behauptet, nur um zu verhindern, daß man sich
> was Neues ansehen muß, bzw. wieder einmal "umlernen" muß. Gerade die
> Unixstinkstiefel, die sich bis heute nicht an eine Maus gewöhnen konnten
> sind doch da schon wieder am rumgreinen.
X11 existiert AFAIK seit 1986 und Xerox und Apple waren vor
M$ maustauglich. Aber was erzähle ich da einem Visionär
wie Dir.
Eigentlich bin ich überrascht, daß Du so altertümliche
Sprachen wie C++ noch kennst. Bist Du nicht schon total
ver.NETtet und verCsharped?
Orgel
--
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.
Eugen Ernst
> X11 existiert AFAIK seit 1986 und Xerox und Apple
> waren vor M$ maustauglich. Aber was erzähle ich da
> einem Visionär wie Dir.
Was hat das immer mit MS zu tun? Seit ihr alle total bescheuert, zu
jedem verficketen Scheißthema irgendwas von MS labern zu müssen? Habt
ihr nichts anderes mehr im Hirn? Ich werde auf so eine Scheiße nicht
mehr antworten.
David Kastrup
> Java und .Net wird nicht verwendet, weil es modern ist, sondern weil
> die meisten Entwickler zu blöd für C/C++ sind. So sieht es doch aus.
Eben. Und das ist das Problem von C++. Ein Sprachdesign ist nach
meiner Ansicht her als gescheitert zu beurteilen, wenn es
unnötigerweise zu komplex und inkonsistent für den Großteil der
potentiellen Rezipienten ist.
Werke wie Joyce's "Ulysses" und Eliot's "The Waste Land" haben in der
Literatur einen festen Platz, auch wenn die erforderlichen rezeptiven
Fähigkeiten modernistischer Werke einen elitären Leserkreis erfordern,
um das Werk in wesentlichen Teilen seiner Schöpfungshöhe zu erfassen.
Aber Programmiersprachen sind nicht Kunst zum Selbstzweck, sondern
Werkzeug. Ich kann für die Rezeption eines Gedichtes oder
literarischen Werkes Beherrschung von Altgriechisch, Latein, Deutsch,
English, Französisch, Spanisch, Italienisch und der jeweiligen
Kernmythen und anderer kultureller Werte erwarten, aber nicht für die
Rezeption der Gebrauchsanleitung eines Fernsehers.
Eugen Ernst
> Und das ist das Problem von C++. Ein Sprachdesign ist
> nach meiner Ansicht her als gescheitert zu beurteilen, wenn
> es unnötigerweise zu komplex und inkonsistent für den
> Großteil der potentiellen Rezipienten ist.
Korrekt. Gilt das auch für C oder ist das aufgrund des minderen Umfangs
als gelungen zu beurteilen? Ich würde sagen nein, C steht C++ in nichts
nach. Lohnt es sich noch, die Frage zu klären, welches von beiden noch
schlechter ist oder sollte man sich gleich neuen Dingen zuwenden, wobei
sich mit Sicherheit herausstellen wird, daß die neuen Konzepte auch noch
nicht das Wahre sind?
mfg
Eugen
Juergen Ilse
Mathias Goldau <fun...@web.de> wrote:
> Kai Großjohann wrote:
>> Mir ist unklar, was an Rekursion hässlich sein soll.
> 1. Schleifen sind meißt besser, das sie den Stack nicht voll müllen. Also im
> Bezug auf Performance.
Das "vollmuellen des Stacks" kann sich durchaus in Grenzen halten,
schliesslich reden wir hier ja nicht von rekursiver Berechnung der
Ackermann-Funktion, oder?
Wie wuerdest du z.B. ein "Quicksort" mit Schleifen statt Rekursion
implementieren?
> 2. Hat man eine Schleife indem viele Variablen dann incrementiert o.ä.
> werden, muß man die alle mit in die Signatur aufnehmen, da es ja keine
> Variablen wie im imperativen Sinne gibt (nur eine Wertzuweisung je
> ''Variable'').
HAEH? Hast du schon mal in Lisp programmiert? Solltest du vielleicht
mal nachholen, dann kommst du von deiner recht hardwarenahen Betrachtung
vielleicht mal zu wesentlicheren Blickwinkeln ...
>> Und ich dachte immer, Schleifen gibt's auch in funktionalen
>> Sprachen. Hm.
> Naja nicht so ganz. :-) höchstens eine Funktion die wie eine schleife
> funktioniert, dazu benötigt man dann aber wieder einen 'goto' Befehl.
Ach, die "map*" Funktionen in Lisp sind keine Schleifen?
>> Ja, in der Welt der Turingmaschinen mag das sein. Aber beim Kernel
>> geht's ja auch (u.a.) darum, zum richtigen Zeitpunkt den richtigen
>> Wert in das richtige Register zu pröppeln.
Wer haelt einen davon ab, die Schnittstelle zum System von der "Register-
proepelei" frei zu halten? Wer haelt einen davon ab, bei Bedarf eine
eigene virtuelle Maschine zu schreiben, und alle Programme sowie nahezu
das gesamte System als Programme in dieser virtuellen Maschine ablaufen
zu lassen (ja, auch dafuer gibt es durchaus Beispiele, wo das getan wurde,
und teils sogar sehr effektiv).
>> Und wenn die Sprache keinen Weg kennt, Dinge in Register zu pröppeln,
>> haste verloren.
Warum denkst du ausschliesslich so hardwarenah? Es gibt Systeme, bei denen
man das (zumindest fuer weite Teile des Systems) nicht noetig hat.
>> Diese Denkweise ist stark zustandsbehaftet: was in dem Register
>> steht, ist der momentane Zustand des Rechners.
>> Zustandsabhängigkeit ist aber nun gerade das, was funktionale
>> Programmierung vermeiden will...
>> Wer weiß einen Ausweg?
> Es gibt keinen, Zustandsänderungen müssen in NEUEN Variablen festfehalten
> werden. Das ist auch das hauptsächliche Problem das Varaiblen in
> fkt.-Sprachen nur einmal verwendet werden dürfen, bzw. es keine Zuweisung
> gibt.
Wann wurde denn "setq" aus dem common-Lisp-Standard entfernt?
>>> Manchmal gehen Sachen aber in einer PS konfortabeler als in einer
>>> anderen, und ich bin mir sicher das C++ in Bezug auf OOP *besser*
>>> als C ist. Und wenn OOP für einen Kernel gut zu gebrauchen wäre,
>>> dann wäre C++ sicher die bessere Wahl.
Die Entwickler von Linux sind in diesem Punkt anderer Meinung.
>>>> Ein Kernel in Haskell. Wär ja auch nicht schlecht.
>>> Haskell kenn ich nicht (lass mich raten funktional :-)?)
>> Genau. Ich kenne Haskell aber auch nicht. Vielleicht hätte ich ML
>> sagen sollen...
Ich haette eher ueber einen Kernel in OCAML nachgedacht. Wenn ich nur
mehr Zeit haette, um mich da intensiver einzuarbeiten (nicht in die
Kernel-Programmierung sondern in diese hochinteressante Sprache) ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> writes:
> > Juergen Ilse <il...@news.pop-hannover.de> writes:
> > > Es gibt eine Menge Programmierer, die C++ nicht allzusehr moegen.
> > > C++ ist irgendwie "weiter von der Maschine weg" als C.
> >
> > Das ist Unsinn.
>
> Sagen wir einmal: der Abstand von der Maschine ist mitunter bei C++
> schwer einzuschätzen. Bei C hat man noch eine gut vorstellbare
> Beziehung zwischen Quellcode und Maschinencode. Setzt man etwa "-O0"
> als Optimierungsoption von gcc ein, rechnet man mit einer gewissen
> einschätzbaren Verlangsamung. Bei C++ muß man damit rechnen, daß
> "-O0" das Programm komplett unbrauchbar verlangsamt,
> weil die Zahl von temporaries und Funktionsaufrufen ins unermeßliche
> steigen. Das Laufzeitverhalten _und_ der Speicherbedarf ist
> erheblich stärker vom Compiler abhängig.
In welchem Umfang der Compiler temporaries generiert, hängt in erster
Linie vom Programm ab. Ebenso, in welchem Umfang es inlining
verwendet. Das man C++ ohne beides schreiben kann, sollte klar
sein. Das beides ohne einen optimierenden Compiler Müll ist,
auch. Nichtsdestotrotz kann man ziemlich problemlos einen guten
Überblick darüber behalten.
> > Es gibt eine Menge Leute, die kein C++ verstehen (und es leider
> > trotzdem zu verwenden versuchen :-(, vgl Qt) und der Teil davon, der
> > es nicht trotzdem benutzt, hat eine beliebig große Menge von
> > Phantastereien parat, warum das eine objektiv sinnvolle Entscheidung
> > war, aber die lassen sich meiner Meinung nach alle auf »Ich kanns
> > nicht (und sehe keinen Grund, es zu lernen)« zurückführen.
>
> Ich habe mich schon mit Stroustroup rumgestritten, als C++ noch nicht
> eine ANSI-Norm war.
Ich nur mit der Sprache.
> Und wenn Du auf Fragen der Sorte "warum sind
> overloaded operators nur als non-static member functions zulässig?
> Diese Einschränkung erfüllt keinen Zweck, ist für diese und jene
> Problemstellung sehr lästig, steht im Gegensatz zu anderen
> Memberfunktionen und muß deswegen im Compiler extra implementiert
> werden, um dem Benutzer das Leben schwer zu machen"
Das ist falsch, es gilt lediglich für folgende Operatoren:
- operator =()
- operator ()()
- operator ()[]
- operator ->()
Das sind alles Operationen, für die ein erstes Argument, das keine
Instanz einer Klasse ist, ohnehin wenig bis keinen Sinn ergibt.
> a> Das ist eigentlich immer der Grund, sobald jemand anfängt, mit
> > »objektiven Begründungen« ultimativ zu fordern, das in Zukunft alle
> > gefälligst nur noch die Sprache benutzen sollten, die er/sie/es
> > zufällig erlernt hat.
>
> Das sage ich ja gar nicht. Ich sage lediglich, daß ich C++ als
> Sprache für so chaotisch, inkonsistent und komplex halte, daß ich auf
> ihre Verwendung dort verzichten würde, wo man das kann.
s/++/C/ und als Widerpart nehmen wir (haha) Ada und sofort wird da
ein Standard-Advocacy-Flamewar draus. Du vertrittst gerade die
Ada-Position :->.
> Auch als Sprache für Lehrzwecke (Informatikstudium etc) halte ich sie
> für ungeeignet, da sie viel zu wenig "aus einem Guß" ist. Für jede
> neue Kleinigkeit braucht man wieder ein neues Idiom, das vollkommen
> anders aussieht als das letzte.
Auch das ist eine subjektive *Geschmacksäußerung*, aber bezüglich
»Lernsprache« alleine stimme ich Dir da vollkommen zu: IMHO sollte man
Leute solange mit Assembler traktieren, bis sie ein Gefühl dafür
entwickelt haben, wie ein richtiger Prozessor arbeitet, bevor man sie
mit komplexen abstrakten Maschinen herumspielen läßt. Aber das
komplette Thema kommt (wenigstens in Dtl und nach meinem Wissensstand)
in der Informatik überhaupt nicht vor.
> Ich mag ein Trottel sein, der zu dämlich ist, C++ richtig zu verstehen
> und damit umzugehen. Aber eine Programmiersprache ist letztlich ein
> Werkzeug. Und ein gutes Werkzeug zeichnet sich eben dadurch aus, daß
> auch ein Trottel damit umgehen kann, ohne daß es anspruchsvolleren
> Anwendungen im Wege steht, und ohne daß man es separat auf
> "anspruchsvolle" Trickkisten umschalten müßte. Ein Werkzeug ist
> nicht Selbstzweck.
C++ kann ein sehr nützliches Werkzeug sein:
output.len() += header_len;
mit
access_ui16 len() const
{
return access_ui16(data + eap::eap_len);
}
und
class access_ui16: public accessor<ui16>
{
public:
[...]
operator unsigned() const
{
return ntohs(*(ui16 const *)where);
}
ui16 operator +=(unsigned v)
{
*(ui16 * const)where += htons(v);
return ntohs(*(ui16 * const)where);
}
};
David Kastrup
> Mathias Goldau <fun...@web.de> wrote:
> > Kai Großjohann wrote:
> >> Mir ist unklar, was an Rekursion hässlich sein soll.
> > 1. Schleifen sind meißt besser, das sie den Stack nicht voll
> > müllen. Also im Bezug auf Performance.
>
> Das "vollmuellen des Stacks" kann sich durchaus in Grenzen halten,
> schliesslich reden wir hier ja nicht von rekursiver Berechnung der
> Ackermann-Funktion, oder?
>
> Wie wuerdest du z.B. ein "Quicksort" mit Schleifen statt Rekursion
> implementieren?
Wird meist aus Effizienzgründen so gemacht. Es wird quasi per Hand
ein Stack für die Daten eingeführt, dann werden die Daten für die
mächtigere Untermenge in diesen Stack geschoben, zunächst die weniger
zahlreiche Untermenge sortiert, und dann per tail recursion auch die
mächtigere erlegt. Die tail recursion muß auf der mächtigeren Hälfte
arbeiten, um die Stacktiefe auf O(lg n) begrenzen zu können.
Selbstverständlich ist dieser effiziente Code dann im Vergleich zur
mit zwei rekursiven Aufrufen geschriebenen aber wesentlich
scheußlicher zu lesen.
Kai Großjohann
> Es gibt immer zwei Aspekte bei der Objektorientierung: Kapselung und
> Hierarchien. Ersteres halte ich fast uneingeschraenkt fuer wuenschenswert,
> letzteres sicher nicht...
Hm, Kapselung...
#define private public
#include <schnuerpel>
--
A preposition is not a good thing to end a sentence with.
Kai Großjohann
> Kai Großjohann wrote:
>>> Na ich hätt auch logikorientierte nehmen können. Man kann zeigen das
>>> alles was man imperativ programmieren kann auch funktional geht. Nur mit
>>> einem heiden Aufwand eben. Einfache sachen wie schleifen müssen durch
>>> rekursion ersetzt werden, die manchmal enorm hässlich werden kann.
>>
>> Mir ist unklar, was an Rekursion hässlich sein soll.
> 1. Schleifen sind meißt besser, das sie den Stack nicht voll müllen. Also im
> Bezug auf Performance.
Ich habe mal was von Restrekursion in meiner Programmierungsvorlesung
gelernt...
> 2. Hat man eine Schleife indem viele Variablen dann incrementiert o.ä.
> werden, muß man die alle mit in die Signatur aufnehmen, da es ja keine
> Variablen wie im imperativen Sinne gibt (nur eine Wertzuweisung je
> ''Variable'').
Hört sich so an, als sei das Problem der fehlende Zuweisungsoperator.
>> [FP für Betriebssysteme] Diese Denkweise ist stark
>> zustandsbehaftet: was in dem Register steht, ist der momentane
>> Zustand des Rechners.
>>
>> Zustandsabhängigkeit ist aber nun gerade das, was funktionale
>> Programmierung vermeiden will...
>>
>> Wer weiß einen Ausweg?
> Es gibt keinen, Zustandsänderungen müssen in NEUEN Variablen festfehalten
> werden. Das ist auch das hauptsächliche Problem das Varaiblen in
> fkt.-Sprachen nur einmal verwendet werden dürfen, bzw. es keine Zuweisung
> gibt.
Und hat das schon mal jemand gemacht?
Vielleicht muss ich mich mal in der Literatur über FP tummeln...
Kai Großjohann
> Mathias Goldau <fun...@web.de> wrote:
>
>>> Ja, in der Welt der Turingmaschinen mag das sein. Aber beim Kernel
>>> geht's ja auch (u.a.) darum, zum richtigen Zeitpunkt den richtigen
>>> Wert in das richtige Register zu pröppeln.
>
> Wer haelt einen davon ab, die Schnittstelle zum System von der "Register-
> proepelei" frei zu halten? Wer haelt einen davon ab, bei Bedarf eine
> eigene virtuelle Maschine zu schreiben, und alle Programme sowie nahezu
> das gesamte System als Programme in dieser virtuellen Maschine ablaufen
> zu lassen (ja, auch dafuer gibt es durchaus Beispiele, wo das getan wurde,
> und teils sogar sehr effektiv).
Oh, gut. Man implementiert eine zusätzliche Abstraktionsebene, damit
man die ekeligen Sachen nicht in der fkt Sprache machen muss :-)
Vielleicht bin ich zu stark von der normalen PC-Hardware verseucht.
>>> Und wenn die Sprache keinen Weg kennt, Dinge in Register zu pröppeln,
>>> haste verloren.
>
> Warum denkst du ausschliesslich so hardwarenah? Es gibt Systeme, bei denen
> man das (zumindest fuer weite Teile des Systems) nicht noetig hat.
Ich denke nicht ausschließlich hardwarenah, sondern ich habe gesagt,
dass FP für hardwarenahe Dinge schwierig wird.
>>> Diese Denkweise ist stark zustandsbehaftet: was in dem Register
>>> steht, ist der momentane Zustand des Rechners.
>>> Zustandsabhängigkeit ist aber nun gerade das, was funktionale
>>> Programmierung vermeiden will...
>>> Wer weiß einen Ausweg?
>> Es gibt keinen, Zustandsänderungen müssen in NEUEN Variablen festfehalten
>> werden. Das ist auch das hauptsächliche Problem das Varaiblen in
>> fkt.-Sprachen nur einmal verwendet werden dürfen, bzw. es keine Zuweisung
>> gibt.
>
> Wann wurde denn "setq" aus dem common-Lisp-Standard entfernt?
CL != funktionale Programmierung. Lisp hat einen funktionalen Kern,
der um imperative Konstrukte (setq eben) erweitert wurde.
In der funktionalen Programmierung ist (das Äquivalent von) setq
verboten.
>>>>> Ein Kernel in Haskell. Wär ja auch nicht schlecht.
>>>> Haskell kenn ich nicht (lass mich raten funktional :-)?)
>>> Genau. Ich kenne Haskell aber auch nicht. Vielleicht hätte ich ML
>>> sagen sollen...
>
> Ich haette eher ueber einen Kernel in OCAML nachgedacht. Wenn ich nur
> mehr Zeit haette, um mich da intensiver einzuarbeiten (nicht in die
> Kernel-Programmierung sondern in diese hochinteressante Sprache) ...
<AOL/>
Schon ML allein ist ja spannend genug.
André Pönitz
> André Pönitz <poe...@gmx.net> writes:
>
>> Es gibt immer zwei Aspekte bei der Objektorientierung: Kapselung und
>> Hierarchien. Ersteres halte ich fast uneingeschraenkt fuer wuenschenswert,
>> letzteres sicher nicht...
>
> Hm, Kapselung...
>
> #define private public
> #include <schnuerpel>
Hm, und?
Kapselung hat nicht notwendigerweise was mit der physischen
Unfaehigkeit zu tun, auf irgendetwas zuzugreifen.
Kai Großjohann
> Kapselung hat nicht notwendigerweise was mit der physischen
> Unfaehigkeit zu tun, auf irgendetwas zuzugreifen.
Ja. Ich finde ``es ist besser, wenn du in diesen Innereien hier
nicht weiter rumwühlst'' angenehmer als ``du darfst hier nicht!''.