template typedef



  • Hallo,
    ich weiß noch nicht, welcher STL-Container für mein Projekt besser geeignet ist und würde den deshalb gerne flexibel mit nem typedef einbauen.
    Nach dem Motto:

    template <class T>
    typedef vector<T> my_container<T>;
    

    Geht das irgendwie oder muss ich ableiten?



  • Nee, template typedef gibts (noch -> siehe C++0x) nicht. Aber eigentlich ist die STL ja so designt, dass du nie auf den konkreten Typ eines Containers angewiesen bist. Schreib deine Algorithmen mit Iteratoren und alles ist klar. (das löst natürlich nicht das generelle template-typedef-Problem, nur den Spezialfall mit den Containern)



  • Danke für die schnelle Antwort...

    Wie bekomm ich denn z.B. nen forward_iterator ohne entsprechenden container erzeugt? (die Klasse forward_iterator ist leider leer 😞 )

    Bzw. wie mach ich z.B. folgende Funktion container-unabhängig, ohne dabei die Funktion zum template (so machen es die STL-Algos) machen zu müssen?

    func(vector<int>& vec) {
      for (vector<int>::iterator i=vec.begin(); i<vec.end(); i++) do_something(i);
    }
    

    irgendsowas wäre nett:

    func(forward_iterator<int> beg; forward_iterator<int> end) {
      for (forward_iterator<int> i=beg; i<end; i++) do_something(i);
    }
    


  • C14 schrieb:

    Bzw. wie mach ich z.B. folgende Funktion container-unabhängig, ohne dabei die Funktion zum template (so machen es die STL-Algos) machen zu müssen?

    Ich glaub ohne Template gehts nicht.



  • Für template typedefs gibt es einen nicht ganz schönen Workaround (der sogar im Standard verwendet wird). Der sähe bei dir so aus:

    template<typename T> struct my_container
    {
        typedef std::vector<T> type;
    };
    

    Und dann statt "my_container<int> c;" eben "my_container<int>::type c;".



  • Und was spricht gegen ableiten?

    template <class T> class myCon : public vector<T> {};
    


  • Und was spricht gegen ableiten?

    Gegen ableiten allgemein spricht, dass std::vector keinerlei zusätzliche Angebote für abgeleitete Klassen anbietet. Es gibt also nichts, was du nicht auch durch Benutzung erreichen könntest.

    Gegen öffentliche Vererbung spricht, dass std::vector keinen virtuellen Destruktor hat. Die polymorphe Verwendung deines neuen Containers wäre also gefährlich. Allerdings sowieso sinnlos, da std::vector keinerlei virtuelle Methoden besitzt.

    Benutzung + optionale Zugriffs-Funktionen auf den drunterliegenden Container ist also besser.



  • Ich meinte jetzt eigentlich nur dieses spezielle "leere Ableiten", um eine Art typedef zu simulieren.

    Fällt das performancetechnisch ins Gewicht (z.B. extra std-konstruktur-/destruktor-Aufruf der abgeleiteten Klasse usw.)
    oder ist das vernachlässigbar / wird irgendwie wegoptimiert?



  • ableiten ist doof.

    wie willst du den Ctor aufrufen?

    alle 5000 ctoren die std::vector hat implementieren?
    sicher, das geht.

    aber du hast das problem, dass es logisch nicht passt 😉

    ausserdem hast du uU mehrkosten, da es eine 2. klasse gibt, die vielleicht auch speicher haben will. (eine empty derived optimization kenne ich nicht)


Anmelden zum Antworten