problem mit stack und basisklasse



  • öhm vielleicht weil das L für Linked steht?
    aber dieser post war jetzt wirklick überflüssig, ich hätte die klasse ja auch
    HaltDieFresseStack nennen können, ist ja meine entscheidung



  • uhsuhz schrieb:

    ich dachte dass ich die funktionen überladen müsste in der LStack klasse, und dann per static_cast<LContainer<T>>(...) aufrufen müsste, aber irgenwie klappt es auch wenn ich den operator nicht überladen habe für die LStack-klasse, kann ich das so lassen, oder ist es sicherer wenn ich per static_cast gehe?

    Ich würde die Operatoren global machen und in den Klassen als Friend deklarieren. Ich würde dann aber für jeden Containertypen, der in der Praxis vorkommt, eine überladene Funktion definieren. Nach Möglichkeit lässt du die Implementierung für die Basisklasse weg, damit es nicht zu ungewollten Vergleichen (implizite Umwandlung) kommt. Oder du machst das ganze in der Klasse (evtl. polymorph). Aber lass op== für die Basisklasse weg, wenn er nicht gebraucht wird.

    Und den !=-Operator kannst du einfacher implementieren:

    template<class T>bool LContainer<T>::operator!=(LContainer& other)
    {
        return !(*this == other);
    }
    

    Und right schreibt man so 😉



  • Nexus schrieb:

    Und right schreibt man so 😉

    lol hab da wohl nicht aufgepasst^^ na lieber mal schnell ändern^^

    //Edit
    hmm irgentwie verstehe ich nicht genau was ich da machen soll...:-( also aus der basisklasse rausnehmen ist ja klar, aber dann haben die ja keinen zugriff mehr auf element?? und auch nicht mehr auf ptrtofirst, ich müsste die funktion höchstens als friend deklarieren,hmm da bräuchte ich vielleicht wenn es geht genauere beschreibungen 😞



  • Wenn du eine Klasse hast, und diese soll externen Funktionen Zugriff auf private Member gewähren, musst du diese Funktionen in der Klasse als Friend deklarieren.

    // Deklaration und Definition der Funktion (genauer: des überladenen Operators)
    bool operator==(const MyClass& Left, const MyClass& Right)
    {
        // ...
    }
    
    class MyClass
    {
        // Friend-Deklaration innerhalb der Klasse; operator== kann jetzt
        // auf private Member von MyClass zugreifen
        friend bool operator==(const MyClass& Left, const MyClass& Right);
    };
    


  • uhsuhz schrieb:

    öhm vielleicht weil das L für Linked steht?
    aber dieser post war jetzt wirklick überflüssig, ich hätte die klasse ja auch
    HaltDieFresseStack nennen können, ist ja meine entscheidung

    loooooooool



  • hmm ich merke gerade, dass ich deque gar nicht von basis ableiten kann, da next ja kein prev kennt... gibt es da eventuell eine möglichkeit, dass next aus der basisklasse prev kennt?



  • uhsuhz schrieb:

    hmm ich merke gerade, dass ich deque gar nicht von basis ableiten kann, da next ja kein prev kennt... gibt es da eventuell eine möglichkeit, dass next aus der basisklasse prev kennt?

    Ehm.. Du speicherst dir auch einen Verweise auf prev?! 🙄



  • @nexus ich habe es nun so gelöst, dass ich in der Containerklasse:

    template<class T>
    class MyContainer
    {
    	template<class T>friend bool operator==(const MyContainer& leftContainer,const MyContainer& rightContainer);
    .
    .
    .
    };
    

    und dann in der stack klasse noch mal:

    template<class T> bool operator==(const MyStack<T>& left,const MyStack<T>& right)
    {
    	return (static_cast<MyContainer<T>>(left) == static_cast<MyContainer<T>>(left));
    }
    
    template<class T> bool operator!=(const MyStack<T>& left,const MyStack<T>& right)
    {
    	return !(left == right);
    }
    

    diese funktionen sind aber nicht freunde der klasse, brauchen sie auch nicht. funktionieren tut es schon mal^^



  • Ableitung macht hier wenig Sinn. Was du willst ist Komposition.
    Damit loesen sich uebrigens auch alle Namensprobleme in Luft auf.

    Stack und Deque sind zwar Container, aber bei Vererbung das Liskov Substitution Principle beachten.



  • Shade Of Mine schrieb:

    Ableitung macht hier wenig Sinn. Was du willst ist Komposition.
    Damit loesen sich uebrigens auch alle Namensprobleme in Luft auf.

    Stack und Deque sind zwar Container, aber bei Vererbung das Liskov Substitution Principle beachten.

    io ich werde mir das morgen mal anschauen, für heute habe ich genug^^


Anmelden zum Antworten