[linux-l] Sauberes Programmieren (war: Sort parallelisieren)

[Oliver Bandel]

On Sun, Jan 07, 2007 at 09:40:58PM +0100, Volker Grabsch wrote:
> On Sun, Jan 07, 2007 at 11:30:00AM +0100, Oliver Bandel wrote:
> > > Die Antwort in C war dann: Kein "new", stattdessen lokale
> > 
> > Seit wann kennt C "new"?
> 
> C kennt malloc/free. Aber wenn man in C++ ständig new/delete verwendet,
> *ist* das letztendlich C-Stil. Natürlich sind new/delete viel sauberer
> als malloc/free, aber "richtiger" C++-Stil vermeidet das, so gut es
> geht.
> 
> Und das funktioniert geht immer, solange die Objekte keinen chaotischen
> Lebenszyklus haben. Und selbst dann kann man mit Listen (list<..> bzw.
> vector<..>) noch einiges retten.
> 
> > > Objekt-Variablen, RAII-Prinzip beachten, Referenzen und Objektkopien
> > > statt Pointer. Schon verschwindet ne Menge Boilerplate-Code. Das
> > > ganze ist bugfreier, und viel, viel weniger potentielle Segfaults.
> > > Bis auf eine einzige Ausnahme kein einziges "delete". Das heißt,
> > > keine Memory-Leaks, und trotzdem ohne Garbage-Collector. Das ist
> > > etwas, das C++ einzigartig macht. Völlig ungewohnt aus Python,
> > > Java, C, ...
> > 
> > Hmhhh, bin kein C++ Spezi. Klingt aber nett/interessant, was Du schreibst.
> 
> Neugierig?
> 


Ja und Nein.


> Vielleicht solltest du C++ wirklich mal ne Chance aber. Aber wiegesagt,
> erstmal den C++-Stil aneignen, das ist ein steiniger Weg. Man sieht viel
> C++-Code, der im C-Stil geschrieben wurde (... obwohl C++-Features
> verwendet werden). Auch sieht man viel C++-Code, der im Java-Stil
> geschrieben wurde.
> 
> Im Netz findet man kaum was ordentliches, aber wirklich empfehlenswert
> ist das Buch:
> 
>     "The C++ Programming Language"
>     Bjarne Stroustrup
>     http://www.research.att.com/~bs/3rd.html
> 
> Es ist vom "C++-Erfinder" geschrieben und deckt nicht nur Formalitäten
> aber, sondern auch Herangehensweisen, Methodiken, Stil.


Das Teil hatte ich mal in der Hand, als ich erwägte, eventuell
doch malC++zu lernen. Ich hatte es nicht geholt, weil C++
noch nicht ANSI-standardisiert war oder da erst kürzlich wurde, aber
das Buchg wohl noch nichtaktualisiert war, oder ich nicht wusste ob.

Ausserdem habe ich das wieder mit dem C++ sein lassen.

Da ich bereits OCaml programmieren kann, müsste ich eine Vollmeise haben,
nun noch C++ zu lernen, denn diesen Abstieg mussich mir echt nicht antun.

Was ich interessant fand, war die Sache mit dem RAII.
War mir ein neuer Begriff, ein kurzes Googeln brachte interessante
Texte zum Vorschein.
Aber nur weil das RAII interessant ist,muß esC++ nicht sein,
bzw. deswegen muss ich mir nicht meine kostbare Freizeit vermüllen
mit C++.

I prefer it sane :)




> 
> > > > Aber es gibt Leute, die einfachgrundsätzlich zu
> > > > faul sind, Fehlerbedingungen abzufragen oder
> > > > nicht gewillt sind ihre Programmiertechniken anzupassen.
> > > 
> > > Nun, das ist eine andere Baustelle. Gibt's natürlich auch, und dieses
> > > Phänomen ist unabhängig von der Programmiersprache, da stimme ich zu.
> > > :-)
> > 
> > Ja, und deswegen plädiere ich fürProgrammiersprachen, die einem
> > diese Art von Pfuscherei wenigstens schwer machen, bzw. einem
> > dabei helfen, eigene Fehler frühzeitig ausfindig zumachen.
> 
> ACK. Deshalb mag ich Python so sehr.

Und Icke OCaml. :)

 
[...]
> Ich weiß, es gibt noch dein Lieblingthema, die Laufzeit-Fehler,

hehe, gut gemerkt, ja :)

> die man überwiegend schon beim Compilieren abfangen sollte. Das
> ist natürlich auch ein Thema, aber ich wollte mit dem Quoting und
> dem API-Design mal einen neuen Aspekt beleuchten. :-)


Naja, einige der OCaml-Programmierer finden, daß OCamlzwar eine
absolut coole Spracheist, man aber an der API der Bibliotheken
(bzgl. Reihenfolge der Argumente) doch einiges hätte besser
machen können: andere Reihenfolge und auch mehr konsistent
zwischen verschiedenen Modulen.
Und ich finde zwar,daß die das in der Tat etwas besser hätten machen
können, verglichen mit den Vorteilen dieser Sprache ist das
aber nebensächlich.
Naja, und mit den Modul-Versionen, wo Labels genutzt werden,entschärft sich
das Problem ja ohnehin.


> 
> > > > ...es gibt eben Leute, die arbeiten gerne mit dem Debugger.
> > > > ...und es gibt andere, die brauchen keinen Debugger.
> > > > 
> > > > So einfach ist das.
> > > 
> > > Es gab ein paar Unsauberkeiten, die wir allein mit Debug-Messages
> > > nicht finden konnten. Sie resultierten aus einem teilweise falschen
> > > Verständnis von C++, ohne Debugger hätten wir das nicht gefunden.
> > 
> > Naja gut, manchmal mag man den schon brauchen; wenn man an Code anderer
> > Leute arbeitet,die Unsinn verzapft haben ;-)
> 
> Man kann solchen Unsinn auch selbst verzapfen. Ich wette, das wird
> dir auch passieren, wenn du dein erstes ernsthaftes C++-Projekt hast,
> und z.B. Referenzen in Listen packst oder so.

Ich weiss nicht, ob ich C++ nochlernen werde, bzw. ich bin mir sehr sicher,
daß ich das nicht mehr tun werde. Ich sage nicht NIE, und auch nicht
"absoult sicher", aber sehr sicher.

Ich weiss aber, daßich, wenn ich in C programmiere,
den Debugger nicht brauche. Habe nen Debugger nur gaaaaaanz ganz selten
überhaupt mal eingesetzt;seit ich da an meinem Programmier-Stil gearbeitet
habe und da --paranoia aktiviert habe, sagt das Programm schnell
selbst, wenn ein Problem auftaucht. :)



> Sicher, im nachhinein
> war mir völlig klar, warum ich das nicht machen durfte, aber dennoch
> hab ich's erstmal mit dem Debugger finden müssen, bevor es mir wie
> Schuppen von den Augen fiel.

Naja, man lernt eben dazu.


[...]
> Unsympathisch an XP, wie auch an vielen anderen Paradigmen, ist dieser
> religiöse Charakter: Wende XP ganz an oder gar nicht. Keine Varianten.
> Keine verschiedenen Lösungen für einzelne Aspekte, denen Vor- und
> Nachteile gegenüber gestellt werden. Sondern einfach nur:
> Du sollst das und das machen, und hier ein paar Gründe dafür: ...
> 
> Viel professioneller ist aber: Unter diesen Umständen mache (1), sind
> die Umstände soundso, mache lieber (2), ansonsten besser was ganz anders.

Eben.
Aber mach das mal Leuten klar. Kunden zum Beipiel.
Die wollen eine klare Aussage, und besser eine unsinnige,
aber man behauptet das auf jeden Fall, als daß man daher
kommt und sagt: "möglicherweise so, möglicherweise anders".

Erinnert mich daran, daß man mit Fuzzy Logic für bestimmte Probleme
überhaupt nur eine Lösung findet, während Crisp Logic zu zittern anfängt ;-)

Fuzzy is Crisp. :)


> 
> Für lezteres braucht man nämlich wirklich umfassende Erfahrung, und
> nicht nur eine handvoll Tricks, die bei ein paar eigenen Projekten
> zufällig gut gelaufen sind.

Gute Arbeit kann man eh nicht in Worte fassen, sondern nur machen
oder nicht machen.



> 
> Das stört mich übrigens auch an den Artikeln von Paul Graham und Joel
> Spolsky: Die sind sehr interessant zu lesen, aber sie verallgemeinern
> ihre Erfahrungen aus einzelnen Projekten viel zu schnell. (Obwohl sie
> gleichzeitig behaupten, genau das nicht zu tun ;-))


Heheh, müssen sie ja ;-)



> 
> > > > Mehr als diese allgemeine Aussage kann man hier nicht treffen,
> > > > denn sonst können wir gleich ein Buch schreiben.
> > > > (Keine schlechte Idee, eigentlich, was? :))
> > > 
> > > Ein Buch über KISS, und warum verfrühte Optimierung böse ist,
> > > mit zahlreichen Beispielen "richtig" <-> "falsch". Das wäre
> > > lustig, ja.
> > 
> > Daslustigste sind Codebeispiele.
> > Manche sehen fast aus wie uuencodet files ;-)
> 
> Von welchen Codebeispielen genau redest du?
> 


Zeugs, was ich imArbeitsleben mal habe sehen müssen.
Übelst. Aber große Klappe...


> > Sowas wie versehentlich obfuscated.
> 
> Jeder Anfänger kann unverständliches Zeug schreiben. "de-obfuscation"
> des eigenen Codes ist das, was den professionellen Programmierer
> ausmacht, oder?


Nö, garnicht erst Unsinn verzapfen ist weit besser.

Wenn man dann doch mal geht aus der Firma/dem Projekt,
kann man wenigstens guten Gewissens gehen. :)


> 
> > Aber manch einer programmiert jaobfuscated,damit sein Job sicher ist.
> 
> Davon habe ich gehört, aber noch nie jemanden kennengelernt, der das
> tatsächlich macht. Die meisten schreiben unverständlich, wenn sie es
> einfach noch nicht besser wissen.

Mag für die meisten Leute auch zutreffen.

> Das gilt für mich selbst auch, z.B.
> als ich mein erstes configure.ac - Script geschrieben habe. Oder am
> ersten größeren C++-Projekt mitprogrammierte. ;-)
> 
> > Kann sich damit aber ins Knie schiessen.
> 
> Nenn mir einen, der das nicht tut. ;-)
> 

;-)


Gruß,
   Oliver