Template <vector>

[evox]

asc schrieb:

std::vector<std::vector<std::string> > meinedaten;
// Erstes Element (h[0]] mit Vektor für die untergeordneten Elemente
meinedaten.push_back(std::vector<std::string>());
// Die Elemente unterhalt h[0] einfügen (Beispiel)
for(int i=0; i<10; ++i)
    meinedaten[0].push_back("Test"); // Stellvertretend für die Werte...
// Zugriff wäre jetzt mit h[0][0] bis h[0][9] möglich (Besser natürlich über Iteratoren).

// Zweites Element (h[1]] mit Vektor für die untergeordneten Elemente
meinedaten.push_back(std::vector<std::string>());
//...

habs jetzt probiert und es ist genau das was ich wollte danke

P.S. Sorry für die Rechtschreibung werde dran Arbeiten

[evox]

so jetzt hab ich das nächste problem:

hab das jetzt alles soweit eingearbeitet:

Tabelle(int m){
     vector<DatenVektor> t ;  //typedef vector<Data> DatenVektor; 	

     groesse = m;
}

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

	ht[i].push_back(data);

}

func liefert mir einen schlüssel zurück (ähnlich einer hashfunktion), diese funktioniert auch.

erstellen kann ich das auch aber beim debuggen kommt

Eine nicht behandelte Ausnahme des Typs "System.AccessViolationException" ist in List.exe aufgetreten.

Zusätzliche Informationen: Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist.

kann mir jemand helfen? sitz schon den ganzen tag dran

ach ja wahlweise kommt auch

Expression: vector subscript out of range

mit dem verweis auf

bool _Inside(const _Ty *_Ptr) const
		{	// test if _Ptr points inside vector
		return (_Ptr < this->_Mylast && this->_Myfirst <= _Ptr);
		}

im vector template

[SeppJ]

Was ist denn ht[i] und existiert das überhaupt? Ich wette nicht.

[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?