1. Dashboard
  2. Forum
    1. Unerledigte Themen
  3. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team-Mitglieder
    4. Trophäen
    5. Mitgliedersuche
  4. Tutorial Bereich
  • Anmelden
  • Registrieren
  • Suche
Dieses Thema
  • Alles
  • Dieses Thema
  • Dieses Forum
  • Seiten
  • Forum
  • Lexikon
  • Erweiterte Suche
  1. Informatik Forum
  2. Webmaster & Internet
  3. Entwicklung

Generische Programmierung mit Templates und STL Containern

  • duracell
  • 1. Dezember 2005 um 21:06
  • Unerledigt
  • duracell
    5
    duracell
    Mitglied
    Punkte
    220
    Beiträge
    40
    • 1. Dezember 2005 um 21:06
    • #1

    Hi!

    Ich versuche gerade, einen generischen BinaryTree (Heap) in C++ zu implementieren und stosse da auf einige Schwierigkeiten. Der Heap soll eine Menge von HeapNodes (wegen konstantem Zugriff) in einer Map verwalten.

    Der generische Typ "HeapNode" ist folgendermaßen definiert:

    C
    template <class K, class D>
    class HeapNode
    {
        public:
        HeapNode(K key, D data);
        ...
    };
    
    
    #include heapnode.c


    soweit so gut, der Typ HeapNode funktioniert wie erwartet. Bei der Implementierung des Heaps beginnen allerdings die Probleme:

    Ich würde den "Heap" gerne so implementieren, dass die ihm als Datenstruktur zu Grunde liegende Map die Schlüssel vom Typ K, sowie die dazugehörigen Werte als generischen Typen HeapNode<K, D> speichert:

    C
    template <class K, class D>
    class Heap
    {
        public:
        Heap(map<K, HeapNode<K, D>> nodes);
    
    
        protected:
        map<K, HeapNode<K, D>> nodes;
    };
    
    
    #include heap.c
    Alles anzeigen


    Hier schreit aber der Compiler (g++ 2.8). Scheinbar stört ihn der generische Typ innerhalb des Wertetyps von map. Das gleiche passiert übrigens auch bei Verwendung von vector, z.B: vector<HeapNode<K, D>>. Sind hier nur "konkrete" Datentypen innherhalb von STL Containern erlaubt?

    ...was ich also benötige ist eine Einschränkung des Wertetypen der map auf Objekte vom Typ HeapNode mit key K und value V.

    Hat jemand einen Plan? Danke!
    lg, martin

  • Plantschkuh!
    24
    Plantschkuh!
    Mitglied
    Reaktionen
    163
    Punkte
    6.173
    Beiträge
    1.181
    • 1. Dezember 2005 um 21:41
    • #2

    Ein mehr oder weniger vollständiges (aber möglichst kleines) Programmfragment sowie die genaue Fehlermeldung wären hilfreich...
    Folgender Code:

    Code
    #include <map>
    
    
    template <class K, class D>
    class HeapNode
    {
        public:
        HeapNode(K key, D data);
    };
    
    
    template <class K, class D>
    class Heap
    {
        public:
        Heap(std::map<K, HeapNode<K, D> > nodes);
    
    
        protected:
        std::map<K, HeapNode<K, D> > nodes;
    };
    Alles anzeigen

    wird von meinem g++ 3.3 anstandslos akzeptiert. Mein Tip wär, daß deinen Compiler der Token >> stört; das ist der left-shift-operator. Will man zwei > hintereinander, so muß man sie durch ein Space trennen. (Mein g++ erkennt das schon und gibt nur eine Warnung aus.)

    (Source-Files in Headern #includieren ist übrigens böhse.)

    *plantsch*

  • tivolo
    5
    tivolo
    Mitglied
    Punkte
    240
    Beiträge
    48
    • 1. Dezember 2005 um 23:01
    • #3
    Zitat von Plantschkuh!

    Mein Tip wär, daß deinen Compiler der Token >> stört; das ist der left-shift-operator. Will man zwei > hintereinander, so muß man sie durch ein Space trennen.

    das wär auch mein tip gewesen.

    Zitat von Plantschkuh!


    (Source-Files in Headern #includieren ist übrigens böhse.)

    generell und in diesem fall: ja. kann aber durchaus auch sinn machen.

    -tiv

    Stefan Reinalter
    Lead Programmer @ Sproing Interactive

  • sauzachn
    17
    sauzachn
    Mitglied
    Reaktionen
    51
    Punkte
    3.101
    Beiträge
    606
    • 2. Dezember 2005 um 12:26
    • #4

    g++ 2.8 ist sowieso sehr veraltet. Grad im Umgang mit Templates lohnt sich einer aus der 3er Serie oder natürlich der 4er, der noch dazu bei exzessiver Verwendung von Templates (boost etc.) viel schneller ist.

    Dipper dipper dii dipper dii dipper dii duuu

  • hal
    32
    hal
    Mitglied
    Reaktionen
    52
    Punkte
    11.122
    Beiträge
    2.208
    • 2. Dezember 2005 um 13:38
    • #5
    Zitat von sauzachn

    Grad im Umgang mit Templates lohnt sich einer aus der 3er Serie oder natürlich der 4er, der noch dazu bei exzessiver Verwendung von Templates (boost etc.) viel schneller ist.

    >1GB RAM sind auch sehr zu empfehlen.

    [font=verdana,sans-serif]"An über-programmer is likely to be someone who stares quietly into space and then says 'Hmm. I think I've seen something like this before.'" -- John D. Cock[/font]

    opentu.net - freier, unzensierter Informationsaustausch via IRC-Channel!
    Hilfe und Support in Studienangelegenheiten, gemütliches Beisammensein, von und mit Leuten aus dem Informatik-Forum!

  • duracell
    5
    duracell
    Mitglied
    Punkte
    220
    Beiträge
    40
    • 3. Dezember 2005 um 14:44
    • #6

    :)

    ich dank euch für die ratschläge! funktioniert bestens!

    @Plantschkuh:
    ich weiss, das inkludieren des c-files im header-file ist im allgemeinen eine üble sache. ich habe allerdings gelesen, dass templates nicht automatisch exportiert werden. export template<class T> wurde zwar in den standard aufgenommen, wird aber von den aktuellen compilern (informationsstand 2004) noch nicht unterstützt. ich habe auf g++ 3.3 (letzte stable von debian sarge) upgedated und da wirds ebenfalls noch nicht unterstützt.

    um den template-typ zu inkludieren, muss also sowohl jeweiliges .h- als auch .c-file inkludiert werden. ich wollte mir das auf diese weise ersparen (natürlich dabei das c-file gegen mehrfaches inkludieren geschützt). weiss jemand eine bessere praxis, bzw. weiss jemand, ob die verwendung von "export template" bereits unterstütz wird? mir gefällt die lösung auch nicht!

    greets, martin

  • hal
    32
    hal
    Mitglied
    Reaktionen
    52
    Punkte
    11.122
    Beiträge
    2.208
    • 3. Dezember 2005 um 15:12
    • #7
    Zitat von duracell

    ich habe auf g++ 3.3 (letzte stable von debian sarge) upgedated und da wirds ebenfalls noch nicht unterstützt.

    Also so weit ich das seh weigern sich die gcc-Entwickler, das Feature einzubauen.

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8434

    [font=verdana,sans-serif]"An über-programmer is likely to be someone who stares quietly into space and then says 'Hmm. I think I've seen something like this before.'" -- John D. Cock[/font]

    opentu.net - freier, unzensierter Informationsaustausch via IRC-Channel!
    Hilfe und Support in Studienangelegenheiten, gemütliches Beisammensein, von und mit Leuten aus dem Informatik-Forum!

  • Fup
    12
    Fup
    Mitglied
    Punkte
    1.460
    Beiträge
    291
    • 3. Dezember 2005 um 15:16
    • #8

    Ich verstehe nicht ganz, wozu du die Implementierung inkludierst, die Schnittstelle reicht doch? Wenn nicht, kannst du dir ja die Klassen vordefinieren und Makro-Hacks verwenden.

    mfG Fup

  • tivolo
    5
    tivolo
    Mitglied
    Punkte
    240
    Beiträge
    48
    • 4. Dezember 2005 um 03:24
    • #9
    Zitat von Fup

    Ich verstehe nicht ganz, wozu du die Implementierung inkludierst, die Schnittstelle reicht doch? Wenn nicht, kannst du dir ja die Klassen vordefinieren und Makro-Hacks verwenden.

    sobald methoden verwendet werden, die nicht inline sind und somit im .c/.cpp file stehen, kommt es bei fast allen compilern zu linker errors. das ist lästig, weil sich definition/implementation bei templates dadurch nicht mehr schön trennen lassen. im C++-standard ist ein entsprechendes 'export' keyword definiert, um die implementation von template-klassen für den linker "sichtbar" zu machen. allerdings ist die zukunft des 'export' keywords ziemlich undefiniert. der einzige compiler, der das momentan unterstützt, ist der Comeau C++ compiler (http://www.comeaucomputing.com/tryitout/).

    interessanter read:
    http://www.gotw.ca/publications/mill23.htm
    http://www.gotw.ca/publications/mill24.htm

    eine andere möglichkeit wäre natürlich noch, 'explicit instantiation' zu verwenden, was angesichts der generalität deiner klasse jedoch nicht wirklich praktikabel ist.

    -tiv

    Stefan Reinalter
    Lead Programmer @ Sproing Interactive

  • Maximilian Rupp 27. Dezember 2024 um 12:06

    Hat das Thema aus dem Forum Programmieren nach Entwicklung verschoben.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden

Benutzer online in diesem Thema

  • 1 Besucher

Rechtliches

Impressum

Datenschutzerklärung