Extrem C++

[Crush]

Erst mal möchte ich das ganze mit einer Frage starten.

Ich finde, daß hier im C++-Forum etwas wenig gepostet wird. Da ich mich gerade mit meinen Büchern etwas intensiver beschäftige und mir immer wieder ein paar Dinge auffallen, die so kaum oder gar nirgends erwähnt werden, habe ich vor, mal ein paar von den Extrem-C++-Themen, bzw. relativ wichtigen Feinheiten anzusprechen. So etwas würde ich ganz gerne mal machen um 1. den Leuten zu zeigen, was da alles noch drin ist, was man in der Schule selten, weniger oder überhaupt nicht lernt - und einfach um mal das ganze für mich selber aufzuarbeiten. Vielleicht hat ja dann der ein oder andere etwas zu dem einen oder anderen Thema zuzufügen oder auch zu korrigieren. Besteht Interesse?

Wenn ja, dann werde ich in der nächsten Zeit mit der Begründung, warum man den Präfix-Operator lieber benutzen sollte als den Postfix und der Template-Metaprogrammierung starten. Vielleicht will ja dann nochmal jemand anders ein paar Themen ansprechen, welche er als "extrem" wichtig oder wissenswert ansieht - auch wenn man´s vielleicht niemals mehr im Leben braucht.

Besteht interesse?

[gajUli]

Ich haette da gleich ein ganz konkretes Problem. Die Didaktik der c++-Programmierung hat es bislang nicht geschafft, ein uebersichtliches und sinnvolles Beispiel zu erfinden, das

- Klassen

- Vererbung

- kanonische Formen

- Chaining

- Dangling Pointer

- Deep Copy Constructor

- Operatorueberladung

demonstriert.

[Scherzkeks]

Ja, das was gaiusjUlius geschreiben hat würde mich auch sehr interrissieren. Crush, kannste da mal was zu schreiben? Wär nicht schlecht.

[Crush]

Komisch Uli ... irgendwie habe ich das Gefühl, als ob Du genau diese Frage schon einmal irgendwo gestellt hättest (vielleicht etwas anders ... aber da war doch was, oder?). Erst mal sag´ ich (auch für Scherzkeks), was ich unter diese Kürzel verstehe und was ich davon denke oder halte:

Kanonische Formen sind ja in etwa definiert aber irgendwie weiß wohl keiner so recht, was man sich darunter genau vorstellen soll oder stellt sich was eigenes vor. Das ist ja ein allumfassendes Thema über ein Design, Programmentwurf, Implementation, Dokumentation alles zusammen und am besten noch alles übervollständig. Da könnte man sich doch ewig drüber auslassen, was dazu gehört und was nicht.

Klassen ... bezeichne ich als Struct mit Funktionen - Im Umkehrschluß ist eine Struct eine Klasse ohne Methoden. Jedenfalls ist das von den Compiler-Produzenten so implementiert.

Vererbung... es gibt so viele Formen der Vererbung, daß man da ja immer einzeln drauf eingehen müßte - alle gleichzeitig in einem sinnvollen Beispiel halte ich für ein Ding der Unmöglichkeit. Aber Beispiele von diversen Kombinationen gibt´s doch zu Hauf - und alle auf einmal ... das wäre zu viel.

Chaining ist der Effekt, der durch die Referenzübergabe von Rückgabewerten auf Objektreferenzen ermöglicht wird, wodurch es möglich ist mehre Funktionen in einer "Kette" mit dem Punktoperator zu durchwandern. objekt.methode1().methode2() der Rückgabewert von Methode 2 wird das this von Methode 1. Die Rückgabewerte werden halt durchgereicht.

Ein Dangling Pointer ist ein Zeiger, der auf ein Objekt gezeigt hat und dessen Objekt sich von seiner Position fortbewegt hat, wodurch er ins Nix zeigt und eigentlich ungültig sein sollte (böse Sache bei den Zeigern) - wie sollte man das sinnvoll in ein kanonisches Beispiel einsetzen?!?!? Als absichtlich eingebauter Fehler???

Ein Deep Copy Constructor ruft einfach die übergeordneten Copy-Construktors der abgeleiteten Klasse direkt auf und kopiert die eigenen members direkt ins neue Objekt. Im Zusammenhang mit Clone und Smart-Pointers könnte man da vielleicht was Brauchbares machen.

Operatorüberladungen müssen eine logisch nachvollziehbare mathematische Vorgehensweise mit den Klasseninstanzen zugrunde liegen. Das bedeutet im Klartext: Input- Output- logische- und algebraische Funktionen sollten sinnvoll überladen sein, damit man sie zur verkürzten Schreibweise einsetzen kann. Nur wenige Klassenkonstruktionen erlauben das, wenn es sich nicht gerade um Mathematische Klassen oder Compilerbau handelt. Lediglich die I/O-Operatoren sind noch öfterer gut einsetzbar.

UND DAS ALLES IN EINEM SINNVOLLEN BEISPIEL!!!! ABSOLUT UNMÖGLICH!!!

Uli, ich glaube eh, daß Du hier einer von denen bist, der wohl mit am meisten auf dem Kasten hat und eigentlich wollte ich hier nur auf kleine Feinheiten von C++ hinweisen oder auf Besonderheiten und nicht ein riesen Beispiel aufziehen - da könnte man ja gleich ein Lehrbuch schreiben, vor allem, wenn man soviel Dinge dabei berücksichtigen will. Worum es sich bei diesen Dingen handelt weißt Du wahrscheinlich eh schon.

War aber trotzdem gut. Vielleicht ist mir das mit der kanonischen Form selber noch nicht klar, was damit genau gemeint sein soll, aber das ist auch ein Grund, wieso ich mal kurz jeden Begriff angerissen habe - dann kannst Du mich ja korrigieren.

Ich will also höchstens die Begriffe einzeln mal auffassen und was dazu schreiben. Aber eigentlich nur, worüber ich so beim Lesen interessantes drüberstolpere und meine, daß man das ein oder andere beim Programmieren wissen sollte oder was ich als Besonderheit betrachte, die man wenigstens mal erwähnt, damit man weiß was überhaupt unter C++ möglich ist. Dabei könnte v.a. das Chaining sicherlich ein Thema sein und man den Dangling Pointer beim Smart-Pointer anschneiden (wollte ich aber eigentlich nicht behandeln - ist doch eh klar, oder? =8-)

Das war ja auch nur ein Vorschlag, weil in letzter Zeit recht wenig los ist, muß man ja nicht ... den Einsteigern ist mit sowas bestimmt auch nicht unbedingt geholfen. Für mich wäre das höchstens so als eine Art Memo im Forum ... auch um vielleicht von anderen zu hören, ob ich das selber richtig kapiert habe.

Das ganze hat sich nur ergeben, weil ein Klassenkamerad von mir mich gerade in seiner neuen Firma ständig anruft und ich (ohne in den Source schauen zu dürfen) ihm seine Fehler erklären muß. C2501 hat zum Beispiel bei ihm bedeutet, daß er eine statische Klassenmethode definieren mußte ... auch etwas, worüber viele nicht bescheid wissen. War auch nur eine Schnappsidee von mir aus Langeweile ... wenn alle dagegen sind, lasse ich das natürlich lieber anstatt sie mit zu langweilen.

Also: Kein kanonisches Beispiel (halte mich eh für viel zu dumm für so ein riesen Ding)!

... ich warte mal ab, was andere noch so schreiben...

[gajUli]

Aeh, tja, crush wieder, muss man nur mit einigen Begriffen impfen, und schon sprudelts aus ihm heraus. Danke fuer die Blumen noch. :-))

Mit Chaining meinte ich eigentlich was anderes (Durchlaufen der Konstruktoren bei der Instantiierung, wenn eine Kette von Vererbungsbeziehungen vorliegt).

Kanonische Form ist nichts so Wildes, laesst sich einigermassen definieren und verstehen. Man soll eigentlich niemals anders programmieren als mit diesen Dinger. Fuer nicht dynamische Daten kommt man aber ohne aus.

Bei Vererbung existiert fuer mich eigentlich nur die public-Vererbung. Die anderen halte ich fuer einen Designirrtum. Reicht fuer die Penne auch voellig aus.

Nun gut, wie komm ich immer wieder drauf. Also Du kannst Dich mit Paukern, Dozenten, Programmierern, wem auch immer unterhalten. Alle erklaeren sie ganz brav diese netten OOP-Prinzipien, aber alle sagen sie "Ja, schoen, dieses oder jenes Beispiel, aber man koennte es auch locker ohne OOP genauso elegant hinkriegen." Was einfach fehlt, sind so Aha-Erlebnisse, wo Du ohne OOP voll vor die Wand knallst, und es mit OOP aber funktioniert.

Vielleicht ist das echt ein Paradigma, das sich erst in Riesenprojekten auszahlt. Ich weiss es nicht...

[Crush]

Das Chaining wie Du es meinst habe ich eigentlich unter dem Deep Copy Constructor beschrieben.

Es ist ja auch wahr, daß OO nichts wirklich Neues ist. Was man hier unter dem Thema Klassen laufen läßt ist nichts weiter als Datenbündelung und Abgrenzen von Funktionen auf diese Datenbündel. Das hat man halt früher nicht so schön darstellen können, war aber auch anders genauso lösbar. Protected oder Private Vererbung hat schon einen Sinn, kann aber tatsächlich anders dargestellt werden. Public entspricht der Schnittstellenvererbung und Private/Protected der Implementationsvererbung, was aber genauso auch durch ein privates Member-Objekt dargestellt werden kann. Ich sehe das weniger als Designfehler als lediglich eine logische Schlußfolgerung auf Öffentlich/Private Trennung innerhalb der Klassen nach außen auf die Vererbung übertragen - aber redundant, weil man es auch anders lösen kann, jedoch ist es dann nicht so schnell ersichtlich, was man beabsichtigt hat.

Vieles in der Syntax ist nicht absolut notwendig (genauso wie die Rekursionen) und dient nur der Übersicht. Das mit der Template-Metaprogrammierung ist ja auch nur eine zufällig entdeckte Methode um Macros zu definieren, die man über Defines oder eigene Funktionen genauso realisieren kann. Das war ja auch nur zufällig entdeckt worden als Nebeneffekt der Template-Maschine.

Was Du jetzt mit den kanonischen Formen meintest habe ich wohl falsch verstanden. Vielleicht könntest Du das mal etwas näher erläutern.

"Was einfach fehlt, sind so Aha-Erlebnisse, wo Du ohne OOP voll vor die Wand knallst, und es mit OOP aber funktioniert."

-> Das halte ich für etwas unmögliches, weil einfach alles auch ohne OOP realisierbar ist. Eigentlich ist das nichts weiter als eine Strukturierungsmethode für Soucecode - unter dem Deckmantel, daß man etwas weniger Tipparbeit hat und Fehlerquellen dadurch eingeschränkt werden sollen. Sicherlich ist das Debuggen ohne diese Strukturierung schon etwas schwieriger - andererseits komme ich im Debugger ohne den Assembler-Code und den Trace-Mode kaum aus, welche davon überhaupt keinen Gebrauch machen. Viele der OO-Themen bringen genau hier keine Vorteile. Versuch mal was von CObjects abgeleitetes oder verkette Listen aller Art im Debugger anzuschauen.

Ich halte OO für nichts anderes als eine andere Darstellungsform. Doch viele Dinge, die durch diese Sprach-Konstruktion entstanden sind sind der Übersichtlichkeit im Wege oder machen die Programmierung in bestimmten Bereichen unheimlich kryptisch. Jedes Plus hat auch ein Minus. Das ist auch der Grund, wieso eine so riesige Anzahl an Programmiersprachen existiert. Jeder glaubt, daß seine genial ist - und das ist sie auch bestimmt für ihren Einsatzbereich. Ob ich jetzt mit VB Oberflächen, mit Delphi DB-Anwendungen, mit Java plattformunabhängige Abfragemasken oder C rasend schnelle Systemnahe Software erstelle spielt doch keine Rolle. Jede hat Ihre Berechtigung und je nach Einsatzgebiet seine Vor- und Nachteile.

Schon vor 12 Jahren habe ich ein paar Entwicklern von Warenwirtschaftsssystemen direkt mal über die Schulter geschaut, weil ich bei denen in den Entwicklungssessions die Protokolle geführt habe und das ganze für die Programmierer gut verdaulich aufbereiten mußte. Die ganzen Datenflußpläne und Datenobjekte sind damals auch nicht anders festgehalten worden wie in der OO. Man hatte seine Objekte, mit Attributen und diese wurden so oder in andere Objekte eingebettet, verwendet oder anderweitig abgefragt. Für jede Form von Objekten gab es Zugriffs und Verwaltungsfunktionen und unter dem Deckmantel einer Oberfläche mit entsprechend vielen Bildschirmmasken hat man im VGA-Modus mit dem ANSI-Zeichensatz hat man diese dann erstellen, editieren und abfragen können. Für mich hat sich mit OO nichts geändert. Nur wird das heute halt so dargestellt, als ob man etwas völlig Neuartiges geschaffen habe, was die Welt nachhaltig verändern wird und ein extrem mächtiges Werkzeug ist. Für mich ist OO vor allem ein Modewort für eine andersartige Syntax - sonst nix.

Ich kann mir wie gesagt nicht vorstellen, daß man mit OOP irgendwas machen kann, was ohne nicht genauso funktionell realisierbar ist - und deshalb wird es ein solches Beispiel nie geben. Deshalb sind solche Diskussionen wie gut oder schlecht die Vorzüge davon nun sind, ein wenig überflüssig. Als C sozusagen als Superassembler erfunden wurde dachte man ja auch, man hat die ultimative Waffe im Kampf gegen die Hardware erfunden. Das dachte man mit Modula1&2 auch und auch mit Fortran, Logo, Lisp und Cobol usw. usw. Wirklich innovativ fand ich das ehrgeizige Projekt von einem, der eine geniale Symbiose erfunden hat: Assembler mit C Syntax: EZASM. Das war für mich ein echter Lückenfüller. Schade, daß dies wohl kaum beachtet wurde. Das wäre vielleicht auch eine Sache, mal zu überlegen, was man gerne an der Syntax anders sehen möchte. Viele Dinge wie Index-indizierte Zugriffe sind meiner Meinung nach in Assembler wesentlich übersichtlicher gehalten als in C++. Auch viele der Bitoperationen sind nicht mehr einfach möglich. Man entfernt sich von den Vorteilen der Prozessoren und der Systeme aufgrund von Compilerbau und Portabilität - und die Optimierungsmethoden sind alles andere als gut. Einmal schreit jeder, wenn ein Computer sich durchsetzt, dann wenn ein Betriebssystem sich durchsetzt und dann als letzte Schlußfolgerung versucht man künstlich Sprachen zu erzeugen, die auf allen laufen sollen ... ich halte von diesen Bewegungen irgendwie nicht viel. Ich bin wenn es um sowas geht der, der für die Forcierung von internationalen Standards im Computerbereich steht - dann wäre die Welt doch viel einfacher.

Programmiersprachen sind nur Mittel zum Zweck und sie entwickeln sich genauso wie die echte Sprache im wirklichen Leben. Nichts bleibt einfach stehen, irgendwas gefällt dem einen mehr oder weniger und so wird halt mal irgendwann aufgrund der Forderungen wieder was verändert. Aber man kann genauso wie in der Physik nicht ständig das Rad neu erfinden. Es gibt Prinzipien die immer als Basis zugrunde liegen. Es wird wohl nie wirklich AHA-Erlebnisse geben. Eine Programmiersprache ist mit den vielen Schnittstellen und Steuerungsmethoden die geschaffen worden sind auch immer mehr und mehr eine Übereinkunft von Programmierern geworden, damit man eine Basis hat mit der man Daten hin- und herschaufelt. Deshalb sind für mich Sprachdiskussionen nur in einem Zusammenhang sinnvoll: Nach dem Einsatzgebiet - und sonst nix.

[capitanx]

Bei Vererbung existiert fuer mich eigentlich nur die public-Vererbung. Die anderen halte ich fuer einen Designirrtum. Reicht fuer die Penne auch voellig aus.

Gibt es sowas überhaupt? Ich dachte immer es gibt die Einfach- und Mehrfachvererbung. Die Variablen in der Superklasse sind entweder private oder protected, weil ja public wenig Sinn macht, da ja sonst jeder auf diese zugreifen könnte.

Dies hätte ja dann mit der Kapselung nichts mehr zu tun, auch OO ist es dann ja nur noch bedingt!

[gugelhupf]

Designerirrtum ?! Ich kann da aus meiner Erfahrung folgendes beisteuern:

VERZICHTET AUF MEHRFACHVERERBUNG !

Das ist m.E. nach ein Schlag ins Wasser gewesen. Wer mit Schnittstellen arbeitet der weiss was ich meine. All diese Namenskonventionen in Bezug auf Methoden etc....

[Crush]

Mehrfachvererbung ist ja auch eigentlich eine Generalisierung und steht im krassen Gegensatz zur Objektorientierung (welche eher eine Spezialisierung darstellt - ist natürlich auch die Frage aus welcher Richtung man das betrachtet), weil hier Objekte aus verschiedenen Klassen zusammengemischt werden, die man vielleicht besser als Member eines neues Objekts definieren sollte. Ein Auto hat einen Stoßdämpfer und 4 Räder und ist kein vierrädriges Stoßdämpfer-Auto. Die OO soll sich ja auch am Sprachgebrauch mitorientieren - und da heißt fast es immer: hat (Member-Objekte=Enthalten via Wert, Komposition->Objektreferenzen=Enthalten via Referenz, Aggregation=enthalten via Zeiger, ist ein ...(=Vererbung), benutzt (Parameterübergabe von Objekten) oder ist abstrakt (sobald virtuelle Methoden vorkommen - es darf davon keine Instanz existieren) und dient somit nur als Vorlage, bzw. Vereinheitlichung gemeinsamer Teil-Komponenten verschiedener Klassen.

"Das ist m.E. nach ein Schlag ins Wasser gewesen. Wer mit Schnittstellen arbeitet der weiss was ich meine. All diese Namenskonventionen in Bezug auf Methoden etc...."

Wenn´s nicht einleuchtend ist, wird man die Mehrfachvererbung bestimmt nicht einsetzen. Es gibt aber schon Fälle, wo eine Mehrfachvererbung unvermeidbar ist. Z.B. wenn man zwei komplett verschiedene Produkte hat (die nichts miteinander zu tun haben) und daraus ein 3. Neues zusammenstellt. Das hat dann schon Sinn. Genauso bei zusammengesetzten Fenster-Objekten, welche Eigenschaften in sich vereinheitlichen sollen. Bei Schnittstellenprogrammierung würde mir nicht mal im Traum einfallen hier irgendwas durch Mehrfachvererbung erreichen zu wollen. Da gibt es normal nur "ist" und "verwendet". Vielleicht solltest Du das mit den Namenskonventionen genauer erklären, anstatt es nur in den Raum zu stellen.

[gajUli]

Original geschrieben von capitanx

Gibt es sowas überhaupt? Ich dachte immer es gibt die Einfach- und Mehrfachvererbung. Die Variablen in der Superklasse sind entweder private oder protected, weil ja public wenig Sinn macht, da ja sonst jeder auf diese zugreifen könnte.

Ja, gibt es. Zu all dem kommt eben noch hinzu, dass die Basisklasse nicht nur public, sondern auch als private oder protected festgelegt werden kann, d. h. bei der Vererbung passiert das.

Wenn Bjarne Stroustroup schon meint, dass die Einfuehrung von "protected" ein Fehler war, dann sind die Varianten, die sich aus diesen Moeglichkeiten ergeben einfach eine Katastrophe, also kaum noch zu ueberschauen. Das meinte ich mit Designirrtum.

Mehrfachvererbung wuerde ich nicht so verurteilen. Java hat sie offiziell nicht, dann aber mit den Interfaces quasi durch die Hintertuer wieder eingefuehrt.