[solved] transformation von variadic template types

[Skym0sh0]

Es gibt da verschiedene Arten von Vererbung und nicht jede ist in jedem Kontext falsch oder schlecht.

class Interface
{
public
    virtual void foo() = 0;
    virtual void bar() = 0;
};

class FooBar : public Interface
{
public
    virtual void foo(){}
    virtual void bar(){}

};

So eine Interface-implementierung (wie in Java) ist ok. Zumal diese Art der Verbung ja auch durch Template-Policys dargestellt wird.

template<class IF>
class Widget
{
public:
    void callFoo()
    {
        IF x;
        x.foo();
    }

    void callBar()
    {
        IF x;
        x.Bar();
    }
};

(Ist zwar en doofes Beispiel, aber letztlich sieht man, dass der Typ, der in die Klasse geschoben wird, das Interface wie oben haben muss, sonst kompilierts nicht.)

Was viele allerdings unter Vererbung verstehen ist:

class Ding
{
public:
    virtual void spezifischeMethode() {/*code*/} // virtual im nachhinein noch dran gepappt, damits "läuft"
};

class AnderesDing : public Ding
{
public:
    virtual void spezifischeMethode()
    {
        // Stuff ...
        Ding::spezifischeMethode();
        // Zeugs ...
    }
};

Und durch sowas blickst du ganz schnell nicht mehr durch. Und die Abhängigkeit zwischen Ding und AnderesDing ist so statisch und fest, da musst du selbst beim Refectorn richtig Zeit drauf verwenden.

[volkard]

Skym0sh0 schrieb:

Es gibt da verschiedene Arten von Vererbung und nicht jede ist in jedem Kontext falsch oder schlecht.

class Interface
{
public
    virtual void foo() = 0;
    virtual void bar() = 0;
};

class FooBar : public Interface
{
public
    virtual void foo(){}
    virtual void bar(){}

};

So eine Interface-implementierung (wie in Java) ist ok. Zumal diese Art der Verbung ja auch durch Template-Policys dargestellt wird.

template<class IF>
class Widget
{
public:
    void callFoo()
    {
        IF x;
        x.foo();
    }

    void callBar()
    {
        IF x;
        x.Bar();
    }
};

(Ist zwar en doofes Beispiel, aber letztlich sieht man, dass der Typ, der in die Klasse geschoben wird, das Interface wie oben haben muss, sonst kompilierts nicht.)

Was viele allerdings unter Vererbung verstehen ist:

class Ding
{
public:
    virtual void spezifischeMethode() {/*code*/} // virtual im nachhinein noch dran gepappt, damits "läuft"
};

class AnderesDing : public Ding
{
public:
    virtual void spezifischeMethode()
    {
        // Stuff ...
        Ding::spezifischeMethode();
        // Zeugs ...
    }
};

Und durch sowas blickst du ganz schnell nicht mehr durch. Und die Abhängigkeit zwischen Ding und AnderesDing ist so statisch und fest, da musst du selbst beim Refectorn richtig Zeit drauf verwenden.

Ganz doofes Beispiel. Und befremdliche Behauptung.

[Columbo]

Der Bestand aber nur aus "Edit: War falsch" oder so; jedenfalls als ich ihn gelesen habe.

Ja, ich hatte vorgeschlagen bei einer leeren Liste zu spezialisieren und die Member zu noppen oder so, mir ist aber schnell aufgefallen das das Unsinn ist. Dann habe ich "Edit: War falsch" darein editiert und abgewartet ob noch jemand Bezug darauf nehmen möchte. Da das keiner in absehbarer Zeit getan hat, habe ich ihn als Platzverschwendung abgetan und gelöscht.

je nach Kontext ist es auch illegal keine Argumente anzugeben.

Wie meinst du das?

[Skym0sh0]

volkard schrieb:

Skym0sh0 schrieb:

...

Ganz doofes Beispiel. Und befremdliche Behauptung.

Ich denke, wir können uns drauf einigen, keine Behauptung ohne Begründung abzugeben...

[volkard]

Arcoth schrieb:

je nach Kontext ist es auch illegal keine Argumente anzugeben.

Wie meinst du das?

Aus Sicht der Anwendung kanns Unfug sein. Wie leere Arrays oder vorzeichenlose 0-Bit-Zahlen.

[Columbo]

Aus Sicht der Anwendung kanns Unfug sein

Ja, Unfug. Mich hat nur das Wörtchen illegal verwirrt.

[volkard]

DANN FANG MAL AN!

Skym0sh0 schrieb:

Es gibt da verschiedene Arten von Vererbung und nicht jede ist in jedem Kontext falsch oder schlecht.

Leere Aussage, braucht keine Begründung, ok. Aber ich kann ja fragen, warum Du das gerade in den Vordergrund stellst: Warum?

Skym0sh0 schrieb:

class Interface
{
public
    virtual void foo() = 0;
    virtual void bar() = 0;
};

class FooBar : public Interface
{
public
    virtual void foo(){}
    virtual void bar(){}

};

So eine Interface-implementierung (wie in Java) ist ok.

Warum? Und ist es der Fall, daß Du Java-Stil gerade befürwortest? Warum? Und das Beispiel ist FooBar-Nichtssagend. Da keiner weiß, was FooBar ist, kann auch keiner wissen, ob hier "Interface-implementierung" passt.

Skym0sh0 schrieb:

Zumal diese Art der Verbung ja auch durch Template-Policys dargestellt wird.

Warum? Und übrigens ist das gar nicht der Fall. Oberschwachsinn! Ah, das willste von mir bewiesen haben? Sorry, geht nicht. Hab gar keinen Ansatzpunkt, mir einfallen zu lassen, wo man das verwenden würde, um dann langsam aufzuzählen, warum es nix taugt.

Skym0sh0 schrieb:

template<class IF>
class Widget
{
public:
    void callFoo()
    {
        IF x;
        x.foo();
    }

    void callBar()
    {
        IF x;
        x.Bar();
    }
};

*lachmichtot*
Begründe mal, warum wer sowas schreiben sollte! Java-Leute, die Klassen als namespaces für freie Funktionen benutzen? Dir muss doch auffallen, daß man kein x nur deshalb erzeugt, um darauf eine statische Methode aufzurufen.

Skym0sh0 schrieb:

(Ist zwar en doofes Beispiel, aber letztlich sieht man, dass der Typ, der in die Klasse geschoben wird, das Interface wie oben haben muss, sonst kompilierts nicht.)

Warum? Warum? Warum?
Die Behauptung ist doch vollkommen falsch.
Langsam begreife ich, was dependency inversion ist. Das ist, wenn der Programmierer vollends aufgibt und fürderhin nur noch Unfug betreiben will.

Skym0sh0 schrieb:

Was viele allerdings unter Vererbung verstehen ist:

class Ding
{
public:
    virtual void spezifischeMethode() {/*code*/} // virtual im nachhinein noch dran gepappt, damits "läuft"
};

class AnderesDing : public Ding
{
public:
    virtual void spezifischeMethode()
    {
        // Stuff ...
        Ding::spezifischeMethode();
        // Zeugs ...
    }
};

Und durch sowas blickst du ganz schnell nicht mehr durch. Und die Abhängigkeit zwischen Ding und AnderesDing ist so statisch und fest, da musst du selbst beim Refectorn richtig Zeit drauf verwenden.

Ja, viele verstehen Vererbung unter Vererbung. Warum stellste das als was Abwegiges hin? Warum blicktst Du da schnell nicht mehr durch? Was stört an der statischen Abhängigkeit, verdammt nochmal! Die Kuh ist ein Säugetier und es wäre javaesk, das anders zu sagen. Warum brauchen wohl die Javaianier so viele Refactorung-Tools in der IDE?

[happystudent]

volkard schrieb:

Ja, viele verstehen Vererbung unter Vererbung. Warum stellste das als was Abwegiges hin? Warum blicktst Du da schnell nicht mehr durch? Was stört an der statischen Abhängigkeit, verdammt nochmal! Die Kuh ist ein Säugetier und es wäre javaesk, das anders zu sagen. Warum brauchen wohl die Javaianier so viele Refactorung-Tools in der IDE?

Vielleicht meint er ja dass es oft nicht nötig ist so eine Abhängigkeit einzufügen, auch wenn eine Kuh ein Säugetier ist. Um mal bei dem Beispiel zu bleiben:

struct Tier
{
	virtual int lautstaerke() const = 0;
};

struct Kuh : Tier
{
	virtual int lautstaerke() const { return 1; }
};

struct Hund : Tier
{
	virtual int lautstaerke() const { return 2; }
};

bool IstLauterAls(Tier const &tier1, Tier const &tier2)
{
	return tier1.lautstaerke() > tier2.lautstaerke();
}

int main()
{
	Kuh kuh;
	Hund hund;
	IstLauterAls(kuh, hund);
}

kann man genauso gut mit templates machen:

struct Kuh
{
	int lautstaerke() const { return 1; }
};

struct Hund
{
	int lautstaerke() const { return 2; }
};

template<class First, class Second>
bool IstLauterAls(First const &first, Second const &second)
{
	return first.lautstaerke() > second.lautstaerke();
}

int main()
{
	Kuh kuh;
	Hund hund;
	IstLauterAls(kuh, hund);
}

Ist kürzer, perfromanter und funktioniert genauso gut. Es hat sogar noch die Vorteile dass man lokale Kopien in der Funktion anlegen kann
(etwa um den internen State einer Kuh zu speichern) ohne jeden Nutzer zu zwingen eine clone-Methode implementieren zu müssen und dass man die IstLauterAls Funktion auch für Motoräder oder Kirchturmglocken verwenden könnte.

Also ich würde hier auf jeden Fall die template Variante nehmen, obwohl man eine "Ist-Ein" Beziehung hat.

[volkard]

happystudent schrieb:

Also ich würde hier auf jeden Fall die template Variante nehmen, obwohl man eine "Ist-Ein" Beziehung hat.

Du hast überhaupt keine "Ist-Ein"-Beziehung.

Stopf mal die beiden Viecher in den selben Container.

[happystudent]

volkard schrieb:

Du hast überhaupt keine "Ist-Ein"-Beziehung.

Stopf mal die beiden Viecher in den selben Container.

Ne, ich meinte nicht dass ich programmiertechnisch eine "Ist-Ein"-Beziehung habe, sondern logisch: Eine Kuh ist ein Tier, ein Hund ist auch ein Tier. Trotzdem brauche ich diese Beziehung hier gar nicht, also kann ich sie mir auch sparen, das meinte ich.