Laufzeit OOP

[Werner Salomon]

Lymogry schrieb:

Virtuelle Funktionen vermeiden *check*

Äh - nein (Du hast mich missverstanden).
wenn Du eine Virtuelle Methode brauchst, so schreibe sie.
Wenn Du sie 'vermeiden' möchtest und dazu große Kopfstände in Deinem Design machen musst, so lass es bleiben und behalte die virtuellen Methoden bei.

Außerdem gilt immer - erst Laufzeiten messen und erst dann optimieren. Nach meiner Erfahrung geht die Zeit nie(!) dort verloren wo Du vorher geglaubt hast, dass es länger dauert!

Gruß
Werner

[Skym0sh0]

Kellerautomat schrieb:

Lymogry schrieb:

Virtuelle Funktionen vermeiden *check*

Bullshit.

Es ist halt Vererbung angewandt. Die Lehrbücher sagen ja auch dazu, dass Vererbung schlecht ist (weil statisch), und Komposition das einzige wahre ist. Gleichzeitig wird aber alles von allem abgeleitet.

Es ist halt alles eine Frage der richtigen Abstraktion, des guten Designs und der ordentlichen Anwendung.

Weil dann sind virtuelle Methoden nicht nur nicht schlecht, sondern fast schon der Himmel auf Erden. Bei falscher Anwendung werden die aber schnell zur Hölle auf Erden.

[Furble Wurble]

Ist OT, aber ich bin ja immer neugierig, mit was sich die Menschen hier so beschäftigen.

Worum geht's in dem Projekt eigentlich?
Und wenn's nicht zu geheim ist: nenn doch mal bitte Beispiele für diese Sonderfälle, die Dich so plagen.

[knivil]

weil eben der original Algo, den ich implementiere, ab einer bestimmten Approximation mehrere Stunden braucht

Du koenntest auch einfach mal Fakten schaffen, indem du das Problem als auch den Algorithmus nennst. Viele NP-Probleme lassen sich gut in andere transformieren, fuer die es bereits fertige und schnelle Bibliotheken gibt, bzspw. travelling sales man, integer linear programming oder 3sat.

[Lymogry]

knivil schrieb:

weil eben der original Algo, den ich implementiere, ab einer bestimmten Approximation mehrere Stunden braucht

Du koenntest auch einfach mal Fakten schaffen, indem du das Problem als auch den Algorithmus nennst. Viele NP-Probleme lassen sich gut in andere transformieren, fuer die es bereits fertige und schnelle Bibliotheken gibt, bzspw. travelling sales man, integer linear programming oder 3sat.

Tut mir leid. Die eidesstattliche Erklärung verbietet es mir, da konkret zu werden

Soviel kann ich ganz allgemein sagen:
http://de.wikipedia.org/wiki/Constraint-Satisfaction-Problem

Irgendein Problem aus dem Bereich mit irgendwelche Bedingungen, mit irgendwelche Algorithmen aus dem Bereich, damit beschäftige ich mich

[knivil]

Und deiner ist besser als uebrige CSP-Solver, e.g. CPLEX?

Und zum Thema: OOP ist grossartig fuer Softwarearchitekturen. Algorithmen in C++ sind selten OOP.

[Lymogry]

knivil schrieb:

Und deiner ist besser als uebrige CSP-Solver?

Du bist aber penetrant!

Ich habe ein Problem aus dem Raum der vielen SAT Probleme. Mit Sonderbedingungen, wo ich Suche im CSP vorher abbrechen kann. Je besser ich die Sonderfälle abgrenzen und früher abbrechen lassen kann, desto schneller wirds. Damit kann ich mein Problem behandeln, aber nicht alle!

[knivil]

Nun in Java gab es mal ein Paper, dass bei einer komplizierten Suche den Rueckgabewert ueber Exceptions transportierte, auch etwas womit man in C++ experimentieren kann.

Damit kann ich mein Problem behandeln, aber nicht alle!

Nun, es sollte trotzdem mit anderen Solvern getestet werden, auch wenn deine Sonderbedingungen nicht modeliert werden koennen. Leider habe ich die aktuelle Entwicklung nicht mehr verfolgt, deswegen kann ich dir keinen Rat geben. Minion Beispielweise nutzt auch OOP/virtuell, aber ich weiss nicht, wie stark es zum Tragen kommt. Schaut man sich MiniSAT an, so habe ich auf Anhieb keine virtuellen Funktionen ausmachen koennen.

[Lymogry]

knivil schrieb:

Nun in Java gab es mal ein Paper, dass bei einer komplizierten Suche den Rueckgabewert ueber Exceptions transportierte, auch etwas womit man in C++ experimentieren kann.

oh, ok. Literatur ist immer gut. (werd ich bei Gelegenheit mal danach suchen)

Nun, es sollte trotzdem mit anderen Solvern getestet werden, auch wenn deine Sonderbedingungen nicht modeliert werden koennen.

sowas in der Art habe ich hier liegen. Das wurde schon (teilweise) modelliert und implementiert. Meine Aufgabe ist, es noch zu verbessern und eine bessere Approximation zu erhalten. (Anm.: Die Aufgabe kommt von meinem Prof, der die erste Modellierung selber gemacht hat. Ich bin schon im Thema drin, hab schon einen ersten Algorithmus mit C. Aber ich kann das noch verbessern, ich werde da auch gut von ihm betreut. Bin ganz zufrieden. )

Leider habe ich die aktuelle Entwicklung nicht mehr verfolgt, deswegen kann ich dir keinen Rat geben, nur dass OOP eine schlechte Wahl ist.

Ich glaube, du stellst dir das gerade ganz falsch vor.
Die Objekte, die die Bedingungen erfüllen müssen, sind ganz ähnlich zueinander. Diese hatte ich vorher in Structs gefasst. Habe aber mehrere Structs verwalten müssen, weil die zwar ähnlich, aber etwas unterschiedlich waren. Und die Funktionsaufrufe waren furchtbar ....
Das kann ich jetzt mit Klassen und Vererbung besser gestalten.

Ach ja ... noch eine Frage:
wie sieht es mit Funktionenüberladen aus? Wieviel Zeit frisst das? Ist das linear?

[Marthog]

Das frisst gar keine Zeit, weil beim Compilen schon die richtige Funktion bestimmt wird. Das ist so, als wären beides unabhängige Funktionen

[Lymogry]

Marthog schrieb:

Das frisst gar keine Zeit, weil beim Compilen schon die richtige Funktion bestimmt wird. Das ist so, als wären beides unabhängige Funktionen

perfekt danke!

[sfasdfasdfsyxf]

Lymogry schrieb:

wie sieht es mit Funktionenüberladen aus? Wieviel Zeit frisst das? Ist das linear?

konstant, wird ja zu compilezeit ausgewertet

[SeppJ]

Lymogry schrieb:

Ach ja ... noch eine Frage:
wie sieht es mit Funktionenüberladen aus? Wieviel Zeit frisst das? Ist das linear?

Da deine Fragen nun recht allgemein in Richtung C vs. C++ gehen: Das meiste an C++ ist "nur" Syntaxzucker gegenüber C. Keine Kosten, einfachere Schreibweise. Wenn du etwas in C mit dem gleichen Effekt machen könntest wie ein C++-Feature, eventuell mit viel Schreibarbeit, dann kannst du davon ausgehen, dass in beiden Fällen der gleiche Code erzeugt wird. Die Übersetzungstabelle ist grob:

Klassen und Memberfunktionen -> structs und Funktionen und viel Schreibarbeit
(nicht-virtuelle) Vererbung -> structs und Funktionen und noch viel mehr Schreibarbeit
Templates -> Makros (und nicht void-Pointer! void-Pointer haben Laufzeitkosten. Templates nicht.) oder viel Schreibarbeit
Überladung -> Funktionen und viel Schreibarbeit

Was interessant wird, sind "echte" C++-Features, wie Exceptions und dynamische Aspekte des Typensystems (virtuelle Funktionen, RTTI). Dies ist teilweise mit echten Kosten verbunden, aber dies sind Dinge, die man in C gar nicht oder nur schwer nachmachen kann. Eine entsprechende C-Lösung wird oft langsamer sein, weil du es nicht so gut hin bekommst wie die Compilerhersteller. Dies ist zum Beispiel bei Exceptions der Fall, wo bei vielen Implementierungen von C++ überhaupt keine(!) Kosten auftreten, so lange keine Exception fliegt, da man spezielle Eigenschaften der Architektur ausnutzen kann, auf die man in (streng standardkonformem) C keinen Zugriff hat.

[dot]

Zusammengefasst: Es gibt praktisch nichts, was du in C machen kannst, was du nicht auch in C++ machen könntest, umgekehrt aber schon. C++ ist ausdrucksstärker und ermöglicht es, mit weniger Code die gleiche oder bessere Performance zu erreichen*.

=> Es gibt keinen vernünftigen Grund, heutzutage noch C zu benutzen, wenn C++ ebenfalls eine Option wäre...

* Vorausgesetzt, man weiß, was man tut; aber diese Voraussetzung muss generell erfüllt sein, damit ein solcher Vergleich überhaupt jemals irgendwie Sinn ergeben könnte. Schlechten oder sinnlosen C++ Code mit optimalem C Code zu vergleichen, oder umgekehrt – wie es in solchen Diskussionen meist getan wird – ist natürlich völlig wertlos.

[Lymogry]

sehr gut sehr gut sehr gut!

C++ ist ausdrucksstärker und ermöglicht es, mit weniger Code die gleiche oder bessere Performance zu erreichen.

wahnsinn ... ich hab grad die ersten Structs in Klassen umgewandelt, denen noch ein paar nette Funktionen und statische Werte gegeben und ich liebe diesen Konstruktor!
Meine 300 Zeilen Code, die damals den Speicher freigeräumt, den Input eingelesen und einige erste Werte berechnet haben ... die haben sich zu 30 Zeilen gekürzt.

Und ich kann dank dem Konstruktor und den Default Werten mit nur einem Befehl auf alles zugreifen, was ich brauche!
ohne Laufzeitprobleme ... ! uiuiui *begeistert*

Ich liebe C++ jetzt schon!

[SeppJ]

Warte nur, bis du lernst, was ein Destruktor ist (das dürfte so ungefähr das nächste Kapitel nach dem Konstruktor sein). Damit kannst du richtig tolle Sachen machen (z.B. dies). Sag auf Wiedersehen zu sämtlichen Problemen und Fallstricken bei der Speicherverwaltung Ressourcenverwaltung!

[seldon]

Die Initialisierung eines Objektes in einer Funktion zusammenzufassen, ist auch in C möglich. Und sinnvoll. Neu an Konstruktoren ist lediglich, dass du sicherstellen kannst, dass ein Objekt nie uninitialisiert herumliegt. Das ist auch nützlich, aber für die Codekürzung sollte es eigentlich weniger relevant sein.

(Automatische) Destruktoren sind da spannender, wie SeppJ richtig anspricht.

[widerseher]

SeppJ schrieb:

Sag auf Wiedersehen zu sämtlichen Problemen und Fallstricken

Ja, auf Wiedersehen, denn die Probleme treten hundertmal schlimmer wieder auf, wenn die Ro3 verletzt wurde, Object slicing auftritt oder sonstwas passiert.

[SeppJ]

widerseher schrieb:

SeppJ schrieb:

Sag auf Wiedersehen zu sämtlichen Problemen und Fallstricken

Ja, auf Wiedersehen, denn die Probleme treten hundertmal schlimmer wieder auf, wenn die Ro3 verletzt wurde, Object slicing auftritt oder sonstwas passiert.

dot schrieb:

* Vorausgesetzt, man weiß, was man tut; aber diese Voraussetzung muss generell erfüllt sein, damit ein solcher Vergleich überhaupt jemals irgendwie Sinn ergeben könnte. Schlechten oder sinnlosen C++ Code mit optimalem C Code zu vergleichen, oder umgekehrt – wie es in solchen Diskussionen meist getan wird – ist natürlich völlig wertlos.

Wobei man in C++ an wesentlich weniger denken muss, damit es richtig und gut ist. Die Regel der großen 3/5 ist schon so ziemlich alles, wo dran man hier denken muss, meistens nicht einmal das, weil man als Ressourcenhalter einen fertigen Handler aus der Standardbibliothek nimmt. Und Slicing möchte ich mal in einem nicht-konstruierten Beispiel sehen.

Wie geht der alte Spruch? In C passiert es leicht, dass man sich selbst in den Fuß zu schießt. In C++ ist das viel schwerer, aber wenn man es schafft, dann ist auch gleich das ganze Bein weg.

Das trifft's recht gut.

[kenner der regeln]

widerseher schrieb:

SeppJ schrieb:

Sag auf Wiedersehen zu sämtlichen Problemen und Fallstricken

Ja, auf Wiedersehen, denn die Probleme treten hundertmal schlimmer wieder auf, wenn die Ro3 verletzt wurde, Object slicing auftritt oder sonstwas passiert.

dann verletze die regel der drei grossen eben nicht, so schwierig?