Offtopic: C++ Problem

[Martin]

> > Meist ist handgeschriebener Code fehleranfälliger und weniger effizient.
>
>  Dem widerum stimme ich nicht zu. Wahr ist, dass häufig verwendeter Code
>  mehr getestet und damit vermutlich korrekt ist.
>  Die Aussage scheint also erstmal bzgl. der Fehleranfälligkeit zustimmen.
>  Aber korrekter als korrekt geht nicht.

>  Einfache Funktionen wie diese hier laufen schneller ab, wenn sie auf das
>  Problem optimiert wurden.
Ja natürlich, da hast du Recht. Aber stellt die eine längere und 
kompliziertere Funktion (mit Zeigerarithmetik und all dem) über ein 
spezielles Thema vor. Sehr wahrscheinlich würde die Problemlösung von 
jemandem, der sich intensiv mit der Thematik auseinandergesetzt hat schneller 
laufen. Oder angenommen, man würde eine derartige Fkt. selbst schreiben, so 
wäre der Zeitaufwand um gleichermaßen effizienten Code zu erhalten doch 
wesentlich höher, oder? 

>  Ich denke, dass das selberschreiben von Funktionen die Codequalität
>  des Programmieres und damit eben die Codequalität des Programms mittel-
>  fristig sogar steigert.
Hier muss ich dir aber wirklich wiedersprechen. Selbst wenn man eine Funktion 
zum einlesen von Werte zum zwanzigsten Mal geschrieben hat glaube ich nicht, 
dass das in irgendeiner Form die Codequalität verbessert. Ich sehe das als 
reine Zeitverschwendung an, die in Projekten von größerem Ausmaß schlicht und 
einfach undenkbar ist.

> > Angenommen, jemand hat eine Zeichenkette und möchte nur einen Teilstring
> > aus ihr in Kleinbuchstaben umwandeln. Die gepostete Funktion mangelt es
> > an Flexibilität. Es ist nicht möglich ohne einigen Aufwand das Problem zu
> > lösen. Deutlich einfacher wäre es ein Funktionsobjekt zu definieren, das
> > ein Zeichen in Kleinbuchstaben umändert:
> > [C++-Beispiel]
>
>  Was mache ich mit den ganzen Funktionsaufrufen, die hier stattfinden?
>  Den Operator, um tolower() aufzurufen? Den Iterator fragen, wer ist der
>  Nächste?
>  Hoffen, dass der Compiler die aufgerufenen Funktionen inline kompiliert?
Abgesehen von den bereits genannten Gründen ist das Overhead einer Fkt. in C++ 
vergleichsweise (man betrachte z.B. Visual Basic) niedrig.

>  Ist der Mehraufwand (Speicher auf'm Stack für die Objekt-Instanzen, rufen
>  der Konstrukturen und evtl der Funktionen) nicht höher, als der Aufwand,
>  um das eigentliche Problem zu lösen (mal kurz durch das char-Array gehen
>  und jeden großen Buchstaben kleinzuklopfen)?
>  Denn der Aufruf von find() erweitert die Möglichkeiten der Funktion doch
>  jetzt nicht wirklich, oder?

Ich glaube du verstehst mich nicht. Die STL basiert größtenteils auf 
generische Algorithmen. Diese bieten mehr Flexibilität(!) als normale 
Funktionen und lassen sich nach belieben mit Funktionsobjekten verknüpfen. 
Der Aufruf von find(/* ... */); war nur ein Beispiel - vielleicht ein nicht 
ganz so gutes. :-)
Wir nehmen zum Beispiel einmal an, dass nur alle Zeichen in einem String, die 
zwischen a und i liegen, durch Kleinbuchstaben ersetzt werden sollen (warum 
auch immer) . Dein Lösungsanzatz wäre es wahrscheinlich eine neue Funktion zu 
schreiben, die genau das tut. Aber warum das Rad neu erfinden? Die 
generischen Algorithmen der STL lassen sich mit dem bereits definierten 
Fkt.-Obj. verknüpfen und bieten somit genügend Möglichkeiten dieses Problem 
zu lösen, ohne das die eigentliche Funktion zum Ersetzen der Großbuchstaben 
abgeänder werden muss.


>  Ich finde Deine Lösung als Möglichkeit nicht schlecht, aber ich stünde
>  dem als tatsächlichen Programmierstil eher skeptisch gegenüber:
>  Objektorientierte Theorie in allen Ehren, aber Programmieren ist doch
>  eher praktischer Natur.
In der modernen Softwareentwicklung kommt man mit deinem Ansatz nicht so 
schnell zum gewünschten Ziel. Es wird immer mehr auf bestehenden Code 
gesetzt, ohne das zeitaufwendige Neuimplementierungen bereits bestehender 
Funktionen nötig sind, nur weil sich der Einzatzbereich (nicht aber das 
Grundkonzept) geändert hat.

Hast du schon "Die C++ Programmiersprache" von Bjarne Stroustrup gelesen? Wenn 
nicht würde ich dir das Buch sehr ans Herzen legen.

Martin


Kleine Anmerkung noch: Ich möchte hier nicht deine persönliche Meinung 
schlecht darstellen, sondern will sachlich über die Vor- und Nachteile 
diskutieren. :-)