teplate <typename... Ts>
class mytype {
};

Diese soll als Member ein Tuple aus Vectoren haben, und zwar zu jeden Typ aus der Template-Argumentliste ein vector. Hier mal ein Beispiel;

also bei

mytype<A,B,C>;

soll der Member den folgenden Typ haben

std::tuple<std::vector<A>, std::vector<B>, std::vector<C>>

ich bin mir bisher nich so sicher wie ich da herangehen soll.

template <typename... Ts>
class mytype
{
    std::tuple<std::vector<Ts>...> mData;
};

Hierbei ist std::vector<Ts> das Expansionsmuster.

template <typename... Ts>
class mytype : std::tuple<std::vector<Ts>...>
{
    std::tuple<std::vector<Ts>...>& data() { return *this; }
    std::tuple<std::vector<Ts>...> const& data() const { return *this; }
};

Aus EBO-Überlegungen bei leerer Argumentliste ist es oft sinnvoll, von dem Tupel privat zu erben.

template <typename... Ts>
class mytype : std::tuple<std::vector<Ts>...>
{
    std::tuple<std::vector<Ts>...>& data() { return *this; }
    std::tuple<std::vector<Ts>...> const& data() const { return *this; }
};

EBO ? Hatte ich bisher noch nie was mit zu tun. Ich bin auch dagegen, weil ich versuche mein Projekt komplett frei von Vererbung zu halten. Es ist aber ein privates Versuchsproject und bisher funktioniert es recht gut.Aber danke für deine Meinung.

Arcoth schrieb:

Durch eine pack expansion:

template <typename... Ts>
class mytype
{
    std::tuple<std::vector<Ts>...> mData;
};

Hierbei ist std::vector<Ts> das Expansionsmuster.

danke, genau danach habe ich gesucht.

ch bin auch dagegen, weil ich versuche mein Projekt komplett frei von Vererbung zu halten.

Wieso denn das?
EBO ist die Empty Base Optimization.
In kurz: Leere Klassen (=nur (static) nicht virtuelle Funktionen und/oder Typedefs) haben in C++ die Größe (=sizeof) 1.
Erbt man allerdings von ihnen, kann oft EBO angewendet und das Objekt komplett wegoptimiert werden.
std::tuple<> scheint laut "ebo" leer zu sein, wenn man davon erbt hat man also keinen Overhead, falls jemand myclass ohne Argumente instantziiert.
Anwenden würde ich das aber hier auch nicht, je nach Kontext ist es auch illegal keine Argumente anzugeben.

Caligulaminus schrieb:

Hier ist irgendwie ein Beitrag von Sone verschwunden...

Ja, viel mir auch auf.
Der Bestand aber nur aus "Edit: War falsch" oder so; jedenfalls als ich ihn gelesen habe.

Krux schrieb:

ch bin auch dagegen, weil ich versuche mein Projekt komplett frei von Vererbung zu halten.

Wieso denn das?
EBO ist die Empty Base Optimization.
In kurz: Leere Klassen (=nur (static) nicht virtuelle Funktionen und/oder Typedefs) haben in C++ die Größe (=sizeof) 1.
Erbt man allerdings von ihnen, kann oft EBO angewendet und das Objekt komplett wegoptimiert werden.
std::tuple<> scheint laut "ebo" leer zu sein, wenn man davon erbt hat man also keinen Overhead, falls jemand myclass ohne Argumente instantziiert.
Anwenden würde ich das aber hier auch nicht, je nach Kontext ist es auch illegal keine Argumente anzugeben.

das ist mal interessant zu wissen mit dem EBO. Das mit der vererbung mache ich deshalb weil ich schon mehrfach schlaue menschen habe sagen hören dass vererbung viel zu viel missbraucht wird und es oft viel schlauere lösungen gibt.

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.

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.

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 schrieb:

...

Ganz doofes Beispiel. Und befremdliche Behauptung.

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

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.

Aus Sicht der Anwendung kanns Unfug sein

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

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?

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.

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.

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.