[Spiel] Findet die Fehler ...

Ahh, danke für die Aufklärung.

Heute Abend kommt bissl was mit Vererbung, Polymorphie oder Exceptions ...

Schon spät geworden

class MyClass {

    private:
            // Kopieren verhindern, um sicherzugehen das aus
            // Performancegründen MyClass nur als Referenz oder Zeiger übergeben wird
            MyClass(const MyClass& obj) { }

            string error;
    public:
            MyClass() : error("") { }

            void setErr(const string& err)
            {
                error = err;
            }

            const string& what() const
            {
                return error;
            }

};

void yuhu(MyClass a)
{
    cout << "Nochmal Glück gehabt :)" << endl;
}

bool func(const MyClass& obj)
{
    bool ohh[2] = { false, true };

    srand(time(NULL));
    random_shuffle(ohh,ohh+2);

    MyClass t(MyClass(obj));
    cout << t.what() << endl;

    return ohh[0];

}

int main()
{

    try {

        MyClass a, z; a = z;

        bool ups = func(a);
        if(ups)
        {
            a.setErr("Böser Fehler");
            throw a;
        }

        yuhu(z);

    }catch(const MyClass& err)
    {
        cout << err.what() << endl;
    }
}

Wieder mehr als ein Fehler ...

Hmmm

Scheint wohl nicht mehr viel Interesse zu sein ...

( Oder verdrückt ihr euch nur )

camper

void yuhu(MyClass a)  // erfordert Copy-Initialisierung 
bool func(const MyClass& obj) // erfordert ggf. Kopieren

    MyClass t(MyClass(obj)); // das hatten wir schon mal...
    cout << t.what() << endl; // ditto

        MyClass a, z; a = z; // kein Fehler, copy-assignment ist public

        bool ups = func(a); // ok, Argument wird direkt gebunden
            throw a; // Exception-Objekt wird kopiert
        yuhu(z); // s.o.

camper schrieb:

bool func(const MyClass& obj) // erfordert ggf. Kopieren

Wieso ?

Beim Code war eigentlich der Hauptaugenmerk von mir auf das throw.
Da die Exception ja per Referenz gefangen wird, dachte ich mir einige denken das wäre ok. Aber wie du ja bereits geschrieben hast, wird beim throw trotzdem das Objekt einmal kopiert, damit man weiterhin ein gültiges Objekt hat

Edit: Gleich kommt was neues ...
Edit2: Doch nicht gleich, muss mir mal was für camper einfallen lassen. Jeden Fehler wirst du bestimmt sehen, aber vielleicht schaffe ich es ja dich von diesem Fehler irgendwie abzulenken

camper

KasF schrieb:

camper schrieb:

bool func(const MyClass& obj) // erfordert ggf. Kopieren

Wieso ?

Falls das Argument mal ein rvalue ist - dann müssten wir allerdings auch an anderer Stelle kopiert haben, insofern hast du nicht ganz unrecht.

otze

templatefehler kann man schlecht nach schwierigkeit einordnen, hier mal was was ich als leicht bezeichnen würde

template<class T>
struct Helper
{
    template<class U>
    static U function(const T& t)
    {
         return t.bar();
    }
};

template<class U,class T>
U foobar(const T& t)
{
    return Helper<T>::function<U>(t);
}

struct Test
{
    int bar()const
    {
        return 5;
    }
};

int main()
{
    Test test;
    std::cout<<foobar<int>(test);
}

//edit was beim kopieren rausgeflutscht

camper

ist nur einer drin, oder?

enum Typ { BaseTyp,MyClassTyp };

class Style {};
class Styler : private Style {

    private:
            long stylecode;

};

template<int N>
struct Cool {

    Styler stylo;
    enum Look { hey = Cool<N-1>::hey ? (sizeof(stylo) == sizeof(long) ? 0xDEAD : 446) : 986};

};

template<>
struct Cool<-10> {

    enum Look { hey = 5 };

};

class Interface {

   public:
            virtual Typ whoAmI(Typ i) = 0;
            virtual ~Interface() = 0;
};

class Base : public Interface {

    public:
            virtual Typ whoAmI(Typ i = BaseTyp)
            {
                return i;
            }

            ~Base() { }
};

class MyClass : public Base {

    public:
            virtual Typ whoAmI(Typ i = MyClassTyp)
            {
                return i;
            }

            ~MyClass() { }

};

int main()
{
    Base base,*pbase = &base;

    cout << pbase->whoAmI() << endl;

    MyClass my;
    pbase = &my;

    cout << pbase->whoAmI() << endl;

    cout << Cool<10>::hey;
}

...

Compilieren ist verboten. _DU_ bist der Compiler
Edit: Verdammt! Habe paar Ablenkung vergessen, ist aber jetzt auch egal ...

@otze: Weiß leider nicht was der Fehler ist. Musste es durch den Compiler jagen und weiß trotzdem nicht wie man das behebt

Es wird glaub ich mal langsam Zeit, dass ich mir "C++ Templates: A Complete Guide" hole, ist auch das nächste Buch, falls ich es mal schaffen sollte "More Excep-C++" anzufangen ...

otze

camper schrieb:

ist nur einer drin, oder?

nur einer, denn der ist für leute dies nicht wissen schon schwer genug

Hier gibts noch ne ganze Menge solcher Aufgaben.

otze

ich lös mal auf:

return Helper<T>::function<U>(t);

das ist der Fehler. richtig ist es so:

return Helper<T>::template function<U>(t);

Das Problem ist, dass man nach dem zugriff auf einen templatetyp angeben muss, wenn danach ein weiteres template folgt, denn sonst wird das "<" pauschal als operator< interpretiert.

Das gilt übrigens nicht nur für den operator:: sondern auch für die anderen zugriffsoperatoren, also "." und "->". Einige nichtstandardconforme Compiler spucken hier übrigens keinen Fehler aus, da sie das "template" nicht unbedingt benötigen.

otze schrieb:

ich lös mal auf:
return Helper<T>::function<U>(t);
das ist der Fehler. richtig ist es so:
return Helper<T>::template function<U>(t);
Das Problem ist, dass man nach dem zugriff auf einen templatetyp angeben muss, wenn danach ein weiteres template folgt, denn sonst wird das "<" pauschal als operator< interpretiert.

Ahh gut zu wissen.

otze schrieb:

Das gilt übrigens nicht nur für den operator:: sondern auch für die anderen zugriffsoperatoren, also "." und "->". Einige nichtstandardconforme Compiler spucken hier übrigens keinen Fehler aus, da sie das "template" nicht unbedingt benötigen.

VC++ EE

Das wollte ich ja auch noch auflösen

1.)

(sizeof(stylo) == sizeof(long)

sizeof(Styler) sollte es heißen, oder man macht stylo static. Das ganze drumherum, wie die Templates und Empty Base Optimization sollte natürlich nur Ablenken.

2.)

virtual ~Interface() = 0;

Da denken vllt einige, dass dies korrekt sei, doch einen abstrakten Destruktor sollte man auch Implementieren, da die abgeleiteten Klassen ja den Destruktor der Basisklasse aufrufen müssen.

//Wessen Compiler es mitmacht so:
virtual ~Interface() = 0 { };
//Besser
virtual ~Interface() = 0;
//...
Interface::~Interface() { }

3.)

virtual Typ whoAmI(Typ i = BaseTyp)
virtual Typ whoAmI(Typ i = MyClassTyp)
//...
Base base,*pbase = &base;
cout << pbase->whoAmI() << endl;

MyClass my;
pbase = &my;

cout << pbase->whoAmI() << endl;

Ergibt zweimal 0 also BaseTyp. Das kommt daher, dass Defaultargumente statisch gebunden sind und virtuelle Funktion natürlich dynamisch.
Und da der statische Typ von pbase Base* ist wird zweimal BaseTyp zurückgegeben.

Lust auf mehr kurze Knackige ?

pumuckl

ja bitte

hustbaer

Ich finde compile-time Fehler viel uninteressanter als andere Fehler. Schliesslich ist es leicht zu wissen dass etwas nicht passt wenn einem der Compiler nen Fehler vorn Latz knallt.

Ich würde also vorschlagen Code zu posten der fehlerfrei compiliert aber sicher nicht das tut was beabsichtigt war. Einfaches Beispiel:

#include <string>

class MyException
{
public:
	MyException() {}
	MyException(std::string const& str) : m_str(str) {}
	MyException(MyException const& other)
	try :
		m_str(other.m_str)
	{}
	catch (...)
	{}

private:
    std::string m_str;
};

3 einfache Fragen:

Was wollte der Programmierer hier erreichen?
Warum geht es nicht und was passiert stattdessen?
Wie lässt es sich fixen?

Kann leider momentan keine posten, da ich mein Netzteil vergessen habe und nun sparsam mit dem Akku umgehen, bis mein Netzteil wieder da ist

Aber für die erste Frage von hustbaer reicht es dennoch

hustbaer schrieb:

Was wollte der Programmierer hier erreichen?

Er wollte verhindern, das bei einer geflogenen Exception vom Typ MyException beim Kopieren des throw-Arguments keine weitere Exception rausfliegt.

right ?

Heinzelotto

er wollte erreichen, dass eine exception in der objektinitialisierungsliste gecatcht wird (aus dem vom vorposter genannten grund).
die exception wird so oder so weitergeschmissen, da nicht garantiert werden kann, dass das Objekt in validem Zustand ist.
z.B. das ganze in den Body des Konstruktors verlagern.