struct _struktur_;
typedef vector<_eine_andere_struktur> _vect_;

map<_struktur_,_vect_> _mmap_;

Nun haut das aber leider nicht hin.
Welche andere Möglichkeit habe ich, um die struktur mit dem vector zu paaren?

Danke
T.

Nun haut das aber leider nicht hin.

Warum? Compiler Error?

map<_Key,_T>

1. Wert kein _Key Value

Edit: Zeig doch mal dein struct, welches der Key sein soll.

Simon

Eine map legt sortiert ab und muss dazu bei 2 Keys feststellen können, welcher kleiner ist (bzw. ob sie beide gleich sind). Bei einem selbstgebauten Typen musst Du das selbst ausdenken und implementieren (z.B. über einen operator<()).
Wenn Dein Typ nicht "sortierbar" ist, hilft Dir auch eine multimap nicht weiter.
Kann es sein, dass Du einfach nur die Teile "irgendwie zusammenpacken" und von der schnelleren Suche der map profitieren möchtest?
Dann musst Du aber etwas dafür tun, denn die map kann nicht zaubern, sondern lediglich Eigenschaften des Keytyps geschickt ausnutzen ... Eigenschaften, die Du aber implementieren musst.
Wenn Du beschreibst, woraus Dein Keytyp (CommandLabelContent) besteht, können wir Dir auch beim Schreiben eines Vergleichsoperators helfen. Wenn es sich um eine Sammlung voneinander unabhängiger Attribute handelt, kann man sie natürlich einfach hintereinanderhängen .... aber damit bezahlt man (bei größeren Strukturen) den Performancevorteil, den map mitbringt mit einem relativ "teuren" Vergleichsoperator - kann im Endeffekt nach hinten losgehen.

Übrigens: Ich persönlich finde verschiedene Deiner Stilentscheidungen ("exzessive-Unterstriche-Stil", "C-typedef-struct"-Stil, "Ungarische-Notation-Rudimente"-Stil, ...)- nicht nur total überflüssig, sondern auch schrecklich zu lesen.
Das hier tut's doch genauso (und ist leserlicher):

struct CommandLabelContent {
              //components
    };
    struct ParseCommand    {
        //components
    };

    typedef vector<ParseCommand> ParseCommandContainer;
public:
    ParseCommand sonderParseCommand; // wieso braucht's noch einen separaten ParseCommand, wenn es unten schon einen ganzen vector voll davon gibt? 
    // wenn er eine besondere Rolle einnimmt, sollte sich das in seinem Namen widerspiegeln
    CommandLabelContent commandLabelContent; // ebenso hier ....

    ParseCommandContainer parseCommandContainer;
    multimap<CommandLabelContent, ParseCommandContainer> CommandLabelContainer;

Gruß,

Simon2.

gut...
bleibt nur die frage, wie ich den < operator implementiere.
Gruss
T.

Da hat sich Deine Antwort mit meiner letzten Ergänzung überschnitten:

Simon2 schrieb:

...
Wenn Du beschreibst, woraus Dein Keytyp (CommandLabelContent) besteht, können wir Dir auch beim Schreiben eines Vergleichsoperators helfen. Wenn es sich um eine Sammlung voneinander unabhängiger Attribute handelt, kann man sie natürlich einfach hintereinanderhängen .... aber damit bezahlt man (bei größeren Strukturen) den Performancevorteil, den map mitbringt mit einem relativ "teuren" Vergleichsoperator - kann im Endeffekt nach hinten losgehen.
...

Am Einfachsten ist es, wenn Dein CommandLabelContent bereits sowas wie eine "ID" hat, die fachlich eindeutig ist. Z.B. sowas wie:

struct CommmandLabelContent {
   string name;
...
};

bool operator<(CommmandLabelContent const& c1, CommmandLabelContent const& c2) {
   return c1.name < c2.name;
}

Also kein Hexenwerk.

Komplizierter ist es, wenn es keine derartige "ID" gibt, aber in den allermeisten Fällen kann man dan was basteln..

Gruß,

Simon2.

Grüsse
Theresa

Übrigens: Ich persönlich finde verschiedene Deiner Stilentscheidungen ("exzessive-Unterstriche-Stil", "C-typedef-struct"-Stil, "Ungarische-Notation-Rudimente"-Stil, ...)- nicht nur total überflüssig, sondern auch schrecklich zu lesen.

Gerade Teile des "exzessive-Unterstriche"-Stils sind sogar verboten - doppelte Unterstruíche sind für den Compiler/Die Implementation reserviert, ebenso führende Unterstriche gefolgt von Großbuchstaben.

Übrigens: Ich persönlich finde verschiedene Deiner Stilentscheidungen ("exzessive-Unterstriche-Stil", "C-typedef-struct"-Stil, "Ungarische-Notation-Rudimente"-Stil, ...)- nicht nur total überflüssig, sondern auch schrecklich zu lesen.

Was anstrengend zu schreiben war, soll gefälligst auch anstrengend zu lesen sein.