class SearchState
{
std::vector<SearchState *> m_next_states;
}

der vector gibt halt an, welche übergänge von dem knoten möglich sind
ich wollte nun folgendes machen :

class SearchState_Trace : public SearchState
{
};

womit ich beim suchen den pfad festhalten kann

und stehe nun aber vor dem problem, das ich ALLES neu schreiben müsste,
weil ich ja nun den vector aus der base-klasse nichtmehr benutzen kann,
und eigentlich wollte ich die funktionen zum aufbauen und und abbauen des
graphen ja beibehalten ...

am besten wäre sowas wie ein
std::vector<Self *> m_next_states;
gibts sowas?

virtual kommt nicht in frage, weil ich dann befürchte das die base-class
zu langsam wird, ehr nehm ich die code-duplication in kauf und schreibe
alles für den tracer neu

virtual kommt nicht in frage, weil ich dann befürchte das die base-class
zu langsam wird, ehr nehm ich die code-duplication in kauf und schreibe
alles für den tracer neu

Befuerchtungen sind selten angebracht, ausser du hast damit bereits Erfahrungen gesammelt. Bevor du befuerchtest, dass virtual deine Klasse zu langsam macht, miss es nach. Man ist oft ueberrascht, wo die Engstellen tatsaechlich liegen.

virtual kommt nicht in frage, weil ich dann befürchte das die base-class zu langsam wird, ...

Wenn dir ein Profiler tatsächlich sagt das dies der Flaschenhals ist, akzeptiere ich diese Aussage. Ansonsten solltest du dich an eine Regel halten: Versuche niemals im Vorfeld zu Optimieren, du wirst nicht selten die falschen Stellen erwischen. Es gibt eine 90:10 Regel (oder 80:20) die auf nahezu alles in der Informatik trift. In diesen Fall: In 90% der Fälle erwischt du eine Stelle die kein Flaschenhals darstellt.

cu André

...
virtual kommt nicht in frage, weil ich dann befürchte das die base-class
zu langsam wird, ehr nehm ich die code-duplication in kauf und schreibe
alles für den tracer neu

Woher kommt eigentlich diese "virtual performance panic" ?
Gerade heutzutage, wo in der Woche, die man für 2% Performancegewinn durch "code duplication" bräuchte, bereits die neue Rechnergeneration über den Ladentisch wandert, die 30% Performancegewinn liefert.

Und dann tut jeder so, als ob
a) er immer gerade an der neuen Terraforming-Modellierung arbeitet,
b) er ganz locker eine schnellere/bessere/flexiblere Technik aus dem Handgelenk schüttelt als die ganzen Heere von Compilerentwicklern und
b) gleichzeitig seine Arbeitszeit (die er mit Neuerfindung des Rades und Wartung unwartbaren Codes verschwendet) nichts wert sei.

Wozu wurde überhaupt Ableitung in C++ erfunden, wenn nicht wegen der Laufzeitpolymorphie mit virtual ?

Gruß,

Simon2.

Wozu wurde überhaupt Ableitung in C++ erfunden, ...

Damit der Diskussionsstoff nicht ausgeht

Scherz beiseite. Ich finde hier auch häufig einige Performanceängste übertrieben. Okay, wenn das Programm wirklich langsam ist, sollte man etwas verändern, aber erst dann. Ich gehe sogar noch weiter: Sofern es der Lesbarkeit und Wartbarkeit des Codes beiträgt baue ich auch mal eine weitere Indirektion ein. Ändern (falls es wirklich ein Flaschenhals sein sollte) kann ich es immer noch.

cu André

habe ich natürlich im hinterkopf, das es perfomant programmiert werden
sollte, und dann möchte ich nicht etwas vom design so entwickeln,
das man es später schwer optimieren kann

und mache mir vorher gedanken darüber ...

wenn ich eine gui-anwendung entwickle, wo man eh 99% der zeit auf mausklicks
wartet, dann sieht die sache natürlich anders aus ...

was ihr sagt ist wohl richtig, nur :
wenn ich schon weiss, das ich ca 100mal pro sekunde
so einen suchbaum durchsuchen muss, das ganze also zu 100% der
flaschenhals wird

Nicht unbedingt, da eine virtuelle Methode nur ein Indirektionsschritt ist, ist dies nicht Zwingend langsamer (In der Regel kann man das gegenüber der Laufzeit der eigentlichen Methode vernachlässigen).

Treb schrieb:

und mache mir vorher gedanken darüber ...

Was in 90% der Fälle eine falsche Stelle trifft, und das ist unabhängig ob du eine GUI Anwendung oder eine Konsolenanwendung entwickelst.

"We should forget about small efficiencies, say about 97% of the time: PrematureOptimization is the root of all evil."

cu André