3. Auswahl verschiedener Algorithem (funktionzeiger???))

Auswahl verschiedener Algorithem (funktionzeiger???))

  • ?

    if (x)
    function1();
    else
    funktion2();

    reicht doch eigendlich aus, braucht man doch keine Funktionszeiger nehmen.

    @David_pb "Wenn die Funktionen identische Parameter und einen identischen Rückgabewert haben geht das mit Funktionszeigern. "

    versteh ich nicht, was hat die Signatur damit zu tun? 😕

    0
  • C

    BorisDieKlinge schrieb:

    könntest du das vielleich genauer erläutern CStoll? soll ich extra klassen für jeden algortium machen?

    Kommt ganz darauf an, was du vorhast. Wenn du ein Beispiel für den Umgang mit Funktoren willst, sieh dir mal map<> oder set<> an - die übernehmen ihr Vergleichskriterium als Funktor (dadurch kannst du auswählen, ob du die Elemente per < (less<T>), > (greater<T>) oder über eine eigene Funktion vergleichen willst).

    @freak: Zum Typ eines Funktionszeigers gehört auch, was für Parameter er übernehmen soll. Und gegenüber deiner if-else Lösung kann erst viel später entschieden werden, welche Funktion(en) in Frage kommen können:

    //diese Funktion nimmt als Parameter eine beliebige double-Funktion, die sie für ihre Rechnungen verwendet
double calculate(...,double(*func)(double))
{
  double dummy = func(x);
  ...
}

double s_val = calculate(...,sin);
double e_val = calculate(...,exp);
    0
  • K

    Hallo,

    je nach umfang des Projektes und Überlegungen nach Erweiterbarkeit, Aufwand, etc. kann man auch das "Strategy Pattern" verwenden.

    Siehe http://www.c-plusplus.net/forum/viewtopic-var-t-is-165475.html. Habe ich auch erst kürzlich hier im Forum gelernt.

    Viele Grüße
    Knecht

    0
  • R

    Wobei Dir eigentlich Polymorphie genau das bietet was du brauchst ....

    virtuelle funktionen sind eigentlich das Pendant fuer funktionszeiger unter c++
    Wenn es kompliziertere Abhaengigkeiten sind, kriegt man das am besten damit hin ...

    funktoren gehen auch, aber das ist ne compiler geschichte. Also wenn du den Algo zur Laufzeit auswahlen willst (usereingabe z.b.) werden dir reine funktoren ned helfen. Man kann natuerlich auch polymorphe objecte hinter funktoren verstecken, aber damit kaschiert man dann eigentlich nur die "andere" schreibweise bei den vfunktionen.

    mit vFunktionen wuerde das ca so aussehen:

    class IComputeClass
{
potected:
    IComputeClass(){}
public:
    virtual ~IComputeClass(){}
    double compute() = 0;
};
// dann noch verschiede Auspraegungen deiner algos als impl fuer IComputeClass

    und verwenden kann man dass dann so ...

    IComputeClass * pMyAlgo = x ? new Algo1(para1,para2) : new Algo2(para1,para2); // kurze version von if then 
    double result = pMyAlgo->compute();

    das ist der eigentlich saubere c++ weg (bei der bestimmung zur laufzeit)

    ciao ....

    0
  • R

    ups, da war noch wer vor mir ^^

    je nach umfang des Projektes und Überlegungen nach Erweiterbarkeit, Aufwand, etc. kann man auch das "Strategy Pattern" verwenden.

    Unter c++ ist das "strategiepattern" als solches eher weniger bekannt, wird IMHO in Schulungen ueber OOD ned expliziet erwaehnt.
    warum:
    Alle hoeheren Programmiersprachen (z.b. c++) haben dieses impliziet dabei.
    facto ist es fuer c++ eigentlich ne 1:1 uebersetzung der funktionsweisse einer virtuellen funktion.
    Alle hoeheren Pattern (erzeugermuster, verhaltensmuster ... etc) funktionieren ned ohne, bzw machen keinen sinn ..
    Bei jeder Objectfabrik wendest du natuerlich das strategiepattern an, sonst waer es ja witzlos ^^

    Ciao ...

    0
  • K

    Hallo miteinander,

    sorry dass ich da nochmal einhaken muss, aber ich bin noch nicht so lange dabei und hab desshalb auch noch nicht so den Duchblick. (Hab auch nicht Informatik studiert).

    Nach meinem bisherigen Kenntnissstand über OOP sind Klassen immer "Datensammlungen" die ein "Konzept" umsetzen.

    Z. B. eine Lampe kann brennen oder nicht (wird in einer Klasse repräsentier durch ein bool) und kann gedimmt sein oder nicht (evtl. durch ein int oder enum, dass verschiedene Lichtstärken anbietet). Die Klasse enthält die Methoden die zum Konzept gehören, wie z. B. Licht ein-/ausschalten oder Dimmen.

    Alle anderen Funktionen die zwar benötigt werden, aber nicht unmittelbar zum Konzept gehören werden nach "The C++ Programming Language" als "Helferfunktionen" ausgeglieder, lies stehe nicht in der Klasse sondern werden als friend implementiert. Dies könnte in obigem Beispiel z. B. eine Funktion "Lampe reinigen" sein.

    Das Strategy Pattern als solches repräsentiert aber kein Konzept an sich, sondern löst nur verschiedene Methoden die eigentlich zu einem Konzept gehören in separate Klassen heraus und dass war für mich das Neue.

    Dass die Umsetzung in C++ mit Hilfe der Polymorphie geschiet ist dabei unabhängig von der ander Denkweise. Oder hab ich da was verwechselt?

    Danke für alle Hinweise
    Viele Grüße
    Knecht

    0
  • R

    Deine Sicht auf Klassen ist schon sehr aehm schwarz weiss ^^
    in der praxis kann man das so eindeutig ned mehr zuordnen. manchmal verschwimmen die grenzen zwischen hilfsklassen und Datenklassen und sowas ganz schoen ... wobei man das eigentlich verhindern sollt.

    es gibt z.b. auch viele Klassen, die keine eigenen eigentlichen daten haben, sondern nur funktionalitaet umsetzen -> funktoren z.b.
    bei templates und policies wirds dann richtig wild ...

    Aber lass dich ned verwirren, prinzipiell stimmt das schon, behalt nur im hinterkopf das es gewisse Speizialfaelle gibt.

    Design patterns sind ne ziemlich abstruse Sache. Eigentlich sollten Sie Loesungsvorschriften fuer Probleme auf niederer Ebene, darstellen, um Programmierern bei aehnlichen Problemen ne aehnliche Loesung vorzuschlagen.

    Einer der Haupt-Vorteile ist z.b. wenn man sich an Namensgebung haelt, ein programmierer der deinen Code warten muss (die arme Sau) und auf eine Klasse namens XYZObserver stoesst, der gleich weiss was er vor sich hat.
    Das klingt einfacher als es eigentlich ist, weil z.b. grad zustands und Verhaltensmuster sich teilweisse ueberschneiden (also ne gruppe von klassen gemeinsam mehrere Entwurfsmuster gleichzeitig implementieren) ....
    Bei vielen Sachen iss die Sicht entscheident, um zu sagen welches Entwurfsmuster es ist.

    Das Strategy Pattern als solches repräsentiert aber kein Konzept an sich,

    Jedes Entwurfsmuster ist eigentlich ein konzept, nur eben sehr auf einen Teilaspekt eines komplizierteren Problems dezimiert.

    Das strategiepattern sagt dir z.b. das du ein wechsel des Verhaltens zur laufzeit, mittels einer Abstraktion und mehreren Detailimplementierungen loest ....
    du hast den anwender, der kennt nur die Abstraktion, und irgendwie schiebst ihm mal die eine mal die andere Implementierung unter.

    Die designpatters sind nicht nur fuer c++ anwendbar ... sondern fuer alles, womit man objectorientiert programmieren kann. Bei manchen Sprachen steckt eben dann mehr dahinter (fuer den programmierer).

    Ciao .....

    0
  • K

    @RHBaum: Danke für die Erläuterungen, das hört sich sehr einleuchtend an 👍
    Gibt es zu diesem Thema ein "gutes" Buch oder Link um tiefer einzusteigen?

    Veilen Dank
    Knecht

    0
  • R

    Ich weiss nich wie weit du wirklich in c++ selber drinnesteckst ...

    Designpattern sind huebsch und lustig, nur nutzen kann man sie ned wenn man ned weiss wie man sie umsetzen soll, und besonders knifflig ist es, wenn man zwischen mehreren Designpattern entscheiden kann / darf um die optimalste variante zu waehlen. Da das meist dann sehr sprachtechnisch ist, sollt man seine Sprache schon gut beherrschen.
    Also vererbung, richtige Anwendung (Neulinge nutzen Polymorphie, wenn sie einmal Blut geleckt haben, eigentlich viel zu oft), Vor und Nachteile ... solltest aus dem FF koennen. Vorher sieht bei den Patterns sonst nur Bahnhof.

    Weiterhin hilft extrem, um "gute" entscheidungen zu treffen, die Gegenseite zu kennen.
    Designpattern sind quasi Laufzeitmuster. Das quasi gegenstueck ist generische Programmierung (templates). Die hohe Schule ist beide dinge miteinander zu kombinieren, nich um nen mischmasch zu erzeugen sondern um designpattern effizient und so generisch wie moeglich umzusetzen.

    Nen richtig gutes Buch fuer designpatterns kann ich ned empfehlen. Die meisten sind ne abstrakte abhandlung des themas, wenn glueck hasst, sind beispiele dabei, zeigen zwar das prinzip ganz gut, sind aber selten praxisnah.
    kenn natuerlich ned alle buecher ^^
    Leih dir lieber wenn soweit bist nen buch aus, und les es dir einmal / mehrmals durch, dann bleiben schon die wichtigsten dinge haengen. Wenn du schon mal weisst, "da gab es doch was" laesst sich schnell im Inet nachschauen. Nen nachschlagewerk fuer die Patterns braucht man eher nicht. (ich schau ins buch da eher selten rein) Im Inet findet man da genug.
    Ich bin sonst eigentlich auch eher nen Fan von gedruckter Lektuere.
    Investier lieber in gute c++ buecher, da kann man ned genug von haben ...

    Ist nur Meine Meinung, (liegt vieelleicht daran das meine firma mir gutes angedeihen lassen wollte und mich auf mehrere Seminare zu dem thema auch gesteckt hat) aber vielleicht koennen die anderen hier was schoenes zum Thema empfehlen ...

    Das Buch was ich hab find ich gar ned bei Amazon ^^

    unbedingt empfehlen zum Thema kann ich :
    http://www.amazon.de/Modernes-Generische-Programmierung-Entwurfsmuster-angewendet/dp/3826613473/sr=8-14/qid=1164204553/ref=sr_1_14/302-3583416-6312825?ie=UTF8&s=books
    da solltest dich aber schon ganz gut auskennen ...

    Ciao

    0
  • K

    Danke schön!!! 👍

    Viele Grüße
    Knecht

    0
Anmelden zum Antworten