Template <vector>

[evox]

natürlich t nicht ht sorry vertippt

[SeppJ]

Dann ändere die Frage dahin, ob t[i] existiert. Ich wette weiterhin dagegen.

[evox]

t wird doch hier erzeugt:

vector<DatenVektor> t

oder lieg ich da falsch

[yahendrik]

In dem Konstruktor fehlt wahrscheinlich

t.resize(groesse);

Edit: Oder besser direkt eine Initialisierungsliste nutzen.

[SeppJ]

Dann hast du ein t. Dieses hat 0 Elemente. Jedweder Zugriff auf irgendein Element von t geht daher schief.

Darf ich dir nahelegen, erst einmal die Grundlagen zu lernen, bevor du anfängst, deine eigenen Hashmaps (wozu eigentlich? Gibt's doch schon in tr1.) zu schreiben?

[asc]

evox schrieb:

hab das jetzt alles soweit eingearbeitet:

Du zeigst nur zu wenig und unvollständigen Code um deinen Fehler sicher zu lokalisieren.

Ich kann nur raten das Tabelle ein Konstruktor ist, und Add eine Methode der Klasse. Wo wird ht deklariert und gefüllt? t ist jedenfalls eine lokale Variable die am Ende des Konstruktors wieder gelöscht wird.

Tabelle::Tabelle(int m)  // m ist wohl kaum sprechend.
{
  vector<DatenVektor> t; // Lokale Variable, nur in Methode gültig.
                         // Falls es einen gleichnamigen Member gibt, überdeckst
                         // du ihn hier.
  groesse = m;           // Schon etwas von einer Initialisierungsliste gehört?
}

void Tabelle::Add(const Data& data)
{
    unsigned int i = data.func(groesse);

    ht[i].push_back(data); // ht ist was? und hat der äußere Vector auch
                           // das Element an der i-ten Stelle?
}

[evox]

yahendrik schrieb:

In dem Konstruktor fehlt wahrscheinlich

t.resize(groesse);

Edit: Oder besser direkt eine Initialisierungsliste nutzen.

das wars super vielen vielen dank

[XSpille]

SideWinder schrieb:

- Die Container der STL sind nicht zum Ableiten gedacht

Wieso eigentlich nicht?
'Nur' wegen den fehlenden virtuellen Destruktoren oder gibt es auch andere Gründe?

[SeppJ]

XSpille schrieb:

Wieso eigentlich nicht?
'Nur' wegen den fehlenden virtuellen Destruktoren oder gibt es auch andere Gründe?

Außerdem gibt es keinerlei protected-Member oder virtueller Funktionen. Du kannst folglich keine Funktionalität hinzufügen, die du nicht auch mit einer freien Funktion erreichen könntest. Daher stellt sich die Frage, wozu man dann noch erben soll.

[Nexus]

XSpille schrieb:

Wieso eigentlich nicht?

Sie sind nicht dafür konzipiert.

Generell hört man diesen Vorschlag vor allem von Leuten, die Funktionalitätserweiterung mit Vererbung gleichsetzen und für die globale Funktionen nicht objektorientiert sind, weil beim Aufruf kein Punkt vorkommt. Aber wir sind ja nicht in Java, wo man Stack von Vector ableitet :p

[SideWinder]

Nexus schrieb:

XSpille schrieb:

Wieso eigentlich nicht?

Sie sind nicht dafür konzipiert.

Generell hört man diesen Vorschlag vor allem von Leuten, die Funktionalitätserweiterung mit Vererbung gleichsetzen und für die globale Funktionen nicht objektorientiert sind, weil beim Aufruf kein Punkt vorkommt. Aber wir sind ja nicht in Java, wo man Stack von Vector ableitet :p

Die alten Collectiosn sind wirklich ein Horror. Das heißt aber nicht, dass das noch Java state-of-the-art ist Die neuen Collections bestehend aus Interfaces und Implementierungsklassen finde ich bis auf einige Details sehr gelungen.

MfG SideWinder

[314159265358979]

Neue Collections?