z.B. eine Methode sort() oder get_low() die mir nach einem eigenem Algorithmus ein entsprechendes Element zurückgibt?

Wie kann man einen Vector um eigene Methoden erweitern?

Gar nicht.

ich empfehle dir auch ne globale (template) funktion.
<algorithm> oder auch <iostream> sind nicht umsonst auf globale funktions und operator-überladung ausgelegt

gerade für die gegebenen Beispiele wie sort() oder get_low() (der wohl eher mit min_element() denn mit einem Tiefschlag zu tun hat ) würde ich folgende Reihenfolge vorschlagen:
1.) Vorhandenes nutzen
2.) Vorhandenes nutzen
...
9.) Vorhandenes nutzen
10.) Nonmember-Funktion () schreiben, die die bestehenden Schnittstellen nutzt (über iteratoren z.B. kann man eigentlich alles über die Elemente herausfinden).
11.) Nonmember-Funktion schreiben, ...
...
99.) Nonmember-Funktion schreiben, ...
100.) Wenn es wirklich sein muss: Ableiten ... und sich den Beschränkungen und Gefahren bewusst sein.
() "Non-Memberfunktion" kann in diesem Zusammenhang auch eine Memberfunktion einer umgebenen Klasse sein.

Letzteres ist ein Weg, der (zurecht) in Verruf geraten ist .... aber nichtsdestotrotz ein Weg, der manchmal das geringste Übel ist.
Dazu hat Matthew Wilson in "Imperfect C++" ganz Interessante geschrieben.

Gruß,

Simon2.

Ok, dann werde ich mich mal intensiver mit Templates auseinandersetzen, Danke.

Hmmmm, das ist aber ein seltsames Fazit, was Du aus diesem Thread ziehst....
Ich hätte mich ja jetzt eher auf std::sort und Iteratoren geworfen.

Aber mach ruhig: Template-Know-How schadet nicht.

Gruß,

Simon2.

Die Attribute sind von unterschiedlichsten typen wie datetime, AnsiString, char, int usw.
Deshalb wohl Templates.

Ich dachte es waere moeglich:

vector <TClass> blub;
blub.push(a);
blub.push(b);
blub.get_low_attr1(); // gibt das Objekt mit dem niedrigsten wert bei attr1 zurueck
blub.get_attr1(y); // gibt alle Objekte mit dem wert y bei attr1 zurueck

sorry, das klingt für mich sehr nach einem der o.g. Fälle 1.)-3.) (höchstens).
Außerdem ist es keine gute Idee, die Struktur der Fachdaten mit der des Containers zu verheiraten.

Was spricht gegen:

vector <TClass> blub;

blub.push_back(a);
blub.push_back(b);
TClass x = get_low_attr1(blub); // gibt das Objekt mit dem niedrigsten wert bei attr1 zurueck
vector<TClass> y = get_attr1(blub); // gibt alle Objekte mit dem wert y bei attr1 zurueck

?
funktioniert prima und ist sehr stabil gegen Veränderungen von TClass oder die Verwendung eines anderen Containers als vector.

get_low_attr1() ist eigentlich auch nichts anderes als std::min_element(get_attr1()) ... und überhaupt kannst Du Vieles vermutlich sehr einfach mit <algorithm> implementieren - falls überhaupt noch eine separate Implementierung notwendig ist. Du kannst z.B. bei copy_if (was wohl Deinem get_attr1() entspricht) einen "Funktor" als Attribut mitgeben, über den Du steuerst, was bei dem jeweiligen Element geprüft werden soll. Ebenso für count_if, find_if, ....

Das meinte ich mit: Schau Dir mal an, wie das in den Standardfunktionen gemacht wird (freie Funktion und Funktor) ... da gibt's vermutlich schon alles, was Du brauchst.

Natürlich denkt JEDER erstmal "Ach, bevor ich mich da eingelesen habe, habe ich das schneller selbst geschrieben !" (typische Programmiererkrankheit ), aber
a) stimmt das eigentlich NIE; IMMER wird der tatsächliche Aufwand bei sowas unterschätzt - es gibt schon einen Grund, warum sich die Standardlibs seit 8 Jahren durchgesetzt haben. Und:
b) Mit der "selbstgestrickten" Lösung hat man sich üblicherweise einen Haufen Probleme eingehandelt, die einem später in den Hintern beißen (gerade, wenn es um Wartbarkeit geht oder jemand anders den Code übernehmen soll). Und schließlich:
c) Du hast hier die Möglichkeit, etwas wirklich Neues dazuzulernen. Nicht nur die Anwendung Deiner bisherigen Techniken auf ein etwas anders geartetes Problem, sondern neue Konzepte ... und einige davon sind ziemlich cool !
Denk dran: Man lernt nie aus.

Gruß,

Simon2.