ich programmiere im Rahmen zweier Vorlesungen nun seid etwa 3 Monaten C(++). Genug Zeit um sich in eine Sprache einzuarbeiten, jedoch noch viel zu wenig um alle Details zu kennen.

Mich würde es nun mal interessieren, was ihr meint, was ich noch so an meinem Code verbessern könnte. Als Beispiel nehme ich hier einfach mal den Code, den ich für unsere aktuelle Übung geschrieben habe (Vektorklasse ohne Speicherung leerer Felder).

Konkret würde mich beispielsweise interessieren, ob es überhaupt Sinn macht kleine Funktionen wie get... und set... als inline zu deklarieren, oder ob das durch Compileroptimierung heute eh egal ist und ob man die +- und -Operatoren nicht irgendwie noch zusammen fassen kann um den redundanten Code zu vermeiden (ich dachte z.B. an eine Funktion, der man einen Operator (+/-) als Parameter übergibt, habe das allerdings nicht hinbekommen). Allerdings freue ich mich auch über alle weiteren Anmerkungen zum Code.

Hier nun der Quelltest (SparseVector.hpp):

#ifndef SPARSEVEKTOR_HPP_INCLUDED
#define SPARSEVEKTOR_HPP_INCLUDED

#include <stdexcept>

using std::invalid_argument;
using std::out_of_range;

// A linked-list node for our sparse vector elements.
template <class T> class Node {
	public:
		// Node constructor - simply initializes the data-members.
		Node(int idx, T val, Node *nxt)
		: index(idx), value(val), next(nxt) {}

		Node()
		: index(-1), next(NULL) {}

		inline int getIndex() const {
			return index;
		}

		inline void setIndex(const int idx) {
			index = idx;
		}

		inline Node * getNext() const {
			return next;
		}

		inline void setNext(Node<T> * nextNode) {
			next = nextNode;
		}

		inline T getValue() const {
			return value;
		}

		inline void setValue(const T val) {
			value = val;
		}

		bool operator == (const Node<T> & n) const {
			return (index == n.index) && (value == n.value);
		}

		bool operator != (const Node<T> & n) const {
			return !(*this == n);
		}

	private:
		int index; // Element number, in the range [0, size)
		T value; // The value of this element.
		Node *next; // A pointer to the next node in the linked-list.
};

template <class T> class SparseVector {
	public:
		SparseVector(const int size = 1)
		: size(size), elements(new Node<T>()) {
			if (size <= 0)
				throw new invalid_argument("Argument must be greater than zero!");
		};

		SparseVector(const SparseVector<T> & spvc)
		: size(spvc.size), elements(new Node<T>()) {
			*this = spvc;
		};

		~SparseVector() {
			Node<T> * aktElem = elements;
			while (aktElem) {
				Node<T> * nextElem = aktElem->getNext();
				delete aktElem;
				aktElem = nextElem;
			}
		};

		void print(std::ostream & out, const std::string seperator) {
			for (int i = 0; i < size; i++) {
				out << getElement(i) << seperator;
			}
		}

		T getElement(const int col) const {
			if ((col < 0) || (col >= size))
				throw new out_of_range("Not a valid vector element!");
			Node<T> * elem = elements;
			while ((elem) && (elem->getIndex() < col))
				elem = elem->getNext();
			if (elem && (elem->getIndex() == col))
				return elem->getValue();
			return 0;
		};

		void setElement(const int col, const T value) {
			if ((col < 0) || (col >= size))
				throw new out_of_range("Not a valid vector element!");
			Node<T> * lastElem = elements;
			Node<T> * aktElem = elements->getNext();
			while ((aktElem) && (aktElem->getIndex() < col)) {
				lastElem = aktElem;
				aktElem = aktElem->getNext();
			}
			if (!aktElem || (aktElem->getIndex() != col)) {
				if (value != 0)
					lastElem->setNext(new Node<T>(col, value, aktElem));
			} else if (value == 0) {
				lastElem->setNext(aktElem->getNext());
				delete aktElem;
			} else {
				aktElem->setValue(value);
			}
		};

		inline int getSize() {
			return size;
		};

		SparseVector & operator = (const SparseVector & spvc) {
			if (this == &spvc)
				return *this;
			size = spvc.size;

			Node<T> * aktElem = elements;
			Node<T> * newElem = spvc.elements->getNext();

			while (aktElem->getNext() && newElem) {
				aktElem = aktElem->getNext();
				aktElem->setIndex(newElem->getIndex());
				aktElem->setValue(newElem->getValue());
				newElem = newElem->getNext();
			}
			if (newElem) {
				while (newElem) {
					aktElem->setNext(new Node<T>(*newElem));
					newElem = newElem->getNext();
					aktElem = aktElem->getNext();
				}
			} else {
				aktElem = aktElem->getNext();
				while (aktElem) {
					Node<T> * nextElem = aktElem->getNext();
					delete aktElem;
					aktElem = nextElem;
				}
			}
			return *this;
		}

		bool operator == (const SparseVector & spvc) const {
			if (spvc.size != size)
				return false;
			Node<T> * aElem = elements->getNext();
			Node<T> * bElem = spvc.elements->getNext();
			while (aElem && bElem && (*aElem == *bElem)) {
				aElem = aElem->getNext();
				bElem = bElem->getNext();
			}
			return !aElem && !bElem;
		}

		bool operator != (const SparseVector & spvc) const {
			return !(*this == spvc);
		}

		SparseVector operator + (const SparseVector & spvc) const {
			if (size != spvc.size)
				throw new invalid_argument("Dimension must be the same!");

			SparseVector result(size);
			for (int i = 0; i < size; i++) {
				result.setElement(i, getElement(i) + spvc.getElement(i));
			}
			return result;
		}

		SparseVector operator - (const SparseVector & spvc) const {
			if (size != spvc.size)
				throw new invalid_argument("Dimension must be the same!");

			SparseVector result(size);
			for (int i = 0; i < size; i++) {
				result.setElement(i, getElement(i) - spvc.getElement(i));
			}
			return result;
		}

		SparseVector & operator += (const SparseVector & spvc) {
			*this = *this + spvc;
			return *this;
		}

		SparseVector & operator -= (const SparseVector & spvc) {
			*this = *this - spvc;
			return *this;
		}
	private:
		int size;
		Node<T> * elements;
};

#endif // SPARSEVEKTOR_HPP_INCLUDED

Gruß Lars

also zum Thema Codequalität: Das meiste gefällt zumindest mir, allerdings bin ich eher ein Verfechter dieses Stils:

int blub(bool xyz)
{
    xyz = false;
    return -1;
}

Das ist allerdings Geschmackssache und bleibt dir überlassen.
Was ich dir allerdings dringenst empfehle: Teile deine Deklarationen und Definitionen auf zwei Files, also *.h und *.cpp auf.

Konkret würde mich beispielsweise interessieren, ob es überhaupt Sinn macht kleine Funktionen wie get... und set... als inline zu deklarieren, oder ob das durch Compileroptimierung heute eh egal ist und ob man die +- und -Operatoren nicht irgendwie noch zusammen fassen kann um den redundanten Code zu vermeiden (ich dachte z.B. an eine Funktion, der man einen Operator (+/-) als Parameter übergibt, habe das allerdings nicht hinbekommen). Allerdings freue ich mich auch über alle weiteren Anmerkungen zum Code.

Afaik werden solche Methoden eh entsprechend optimiert aber lass das inline doch einfach stehen, es stört ja nicht :).

Zum Stichwort Operator als Parameter, kuck dir doch mal an wie dass bei accumulate gelöst wurde:
http://www.cplusplus.com/reference/std/numeric/accumulate.html

Ich an deiner Stelle würde die Operatoren jedoch so lassen wie sie sind, eine meiner Meinung nach sinnvolle Optimierung ist da nichtmehr möglich.

Hoffe ich konnte helfen,

Max

#edit: Wegen dem ; nach der Funktionsdeklaration, Afaik ist das so legitim allerdings würde ich den Strichpunkt grundsätzlich weglassen. Wenn du ihn möchteste dann mach ihn hinter alle Funktionsdeklarationen und nicht nur hinter manche.

Was ich dir allerdings dringenst empfehle: Teile deine Deklarationen und Definitionen auf zwei Files, also *.h und *.cpp auf.

nee nee nee
ist doch ein template. das bleibt brav im header leben.

blub² schrieb:

Was ich dir allerdings dringenst empfehle: Teile deine Deklarationen und Definitionen auf zwei Files, also *.h und *.cpp auf.

nee nee nee
ist doch ein template. das bleibt brav im header leben.

Hmm... vlt. sollte ich nicht über Sachen schreiben von denen ich nicht allzuviel Ahnung habe :S. Also bleiben bei Template Klassen grundsätzlich Deklarationen und Definitionen im Header vereint?

Gruß
Don06

Hmm... vlt. sollte ich nicht über Sachen schreiben von denen ich nicht allzuviel Ahnung habe

das wäre schlimm. dann hätten wir gar nicht drüber reden können, daß bei templates der compiler vor dem benutzen die definition lesen könen muss, weshalb die definition auch irgendwie inkludiert werden muss.

:S. Also bleiben bei Template Klassen grundsätzlich Deklarationen und Definitionen im Header vereint?

naja, grundsätzlich nicht. zum einen machen manche leute zwei headers, SparseVector.hpp und SparseVectorImpl.hpp,
zum anderen gibt es da noch (mehr als theoretische möglichkeit) sachen mit extern und templates.

naja, grundsätzlich nicht. zum einen machen manche leute zwei headers, SparseVector.hpp und SparseVectorImpl.hpp,
zum anderen gibt es da noch (mehr als theoretische möglichkeit) sachen mit extern und templates.

Was steht denn hier jeweils drin? Ist mir nicht so ganz klar geworden.

Danke schonmal & Gruss,

Max

SparseVector(const int size = 1) 
        : size(size), elements(new Node<T>()) { 
            if (size <= 0) 
                throw new invalid_argument("Argument must be greater than zero!"); 
        };

Wenn du size als unisgned definierst, dann sparst du dir diese Ueberpruefung (und du hast dann auch kein memory leak mehr).

SparseVector & operator -= (const SparseVector & spvc) {
            *this = *this - spvc;
            return *this;
        }

Viel besser ist es den operator- mit Hilfe des operator-= zu implementieren.

Im Prinzip aber ganz nett.

zum anderen gibt es da noch (mehr als theoretische möglichkeit) sachen mit extern und templates.

Du meinst wahrscheinlich export ... Soviel ich weiss, unterstützen das aber die wenigsten Compiler, und bei denen, die das Schlüsselwort unterstützen, zahlt es sich nicht wirklich aus.

Vielleicht noch operator+ und operator- global machen, und die dann auf die Member += und -= zugreifen lassen. Wieso wirfst du die Exception eigentlich auf dem Heap? Also

throw new invalid_argument("Argument must be greater than zero!");

volkard schrieb:

ich würde auch auf seltenes globales using im header verzichten.

Werde ich ändern.

volkard schrieb:

und }; am funktionsende ist falsch.

Der Compiler frisst es zwar so, aber du hast Recht. Ich hatte zunächst eine ganz normale Header-Datei (ohne Template) geschrieben und da steht ja immer ein ;. beim hinzufügen der Implementierung habe ich dies dann wohl vergessen zu entfernen.

---

kaffeeerkenner schrieb:

du hast vorher java gelernt, stimmts?

Jo, ich habe gut ein Jahr lang Java programmieren müssen. Eigentlich komme ich jedoh aus der Object-Pascal-Ecke. Merkt man das Java so sehr?

---

blub² schrieb:

Zum Stichwort Operator als Parameter, kuck dir doch mal an wie dass bei accumulate gelöst wurde:
http://www.cplusplus.com/reference/std/numeric/accumulate.html

Ich an deiner Stelle würde die Operatoren jedoch so lassen wie sie sind, eine meiner Meinung nach sinnvolle Optimierung ist da nichtmehr möglich.

Werde ich mir gleich dennoch mal ansehen

---

volkard schrieb:

wohl besser, du implementiertst den copy-ctor normal und dern op= mit copy&swap?

Aber im op= muss doch nicht immer jedes Element neu erzeugt werden, im cp-ctor aber schon. Deshalb wäre eine solche Implementierung doch langsamer.
Gibt es denn sonst noch Vorteile, die für eine Implementierung in deinem Sinne sprechen?

---

Shade Of Mine schrieb:

Wenn du size als unisgned definierst, dann sparst du dir diese Ueberpruefung (und du hast dann auch kein memory leak mehr).

Kurz: Vorgaben

Shade Of Mine schrieb:

Viel besser ist es den operator- mit Hilfe des operator-= zu implementieren.

Jo, stimmt. Das könnte man machen.

---

Nexus schrieb:

Wieso wirfst du die Exception eigentlich auf dem Heap? Also

throw new invalid_argument("Argument must be greater than zero!");

Wie sollte ich es denn machen?

volkard schrieb:

wohl besser, du implementiertst den copy-ctor normal und dern op= mit copy&swap?

Aber im op= muss doch nicht immer jedes Element neu erzeugt werden, im cp-ctor aber schon. Deshalb wäre eine solche Implementierung doch langsamer.
Gibt es denn sonst noch Vorteile, die für eine Implementierung in deinem Sinne sprechen?

oh, du verwendest ja die alten knoten weiter.
ich nehme meinen vorschlag zurück. aber irgendwie fühle ich mich unwohl dabei. weiß auch nicht, warum.

Wie sollte ich es denn machen?

Zum Beispiel so:

throw invalid_argument("Argument must be greater than zero!");

#ifndef SPARSEVEKTOR_HPP_INCLUDED
#define SPARSEVEKTOR_HPP_INCLUDED

#include <stdexcept>

// A linked-list node for the sparse vector elements
template <class T> class Node {
	public:
		// Node constructor - simply initializes the data-members.
		Node(int idx, T val, Node *nxt)
		: index(idx), value(val), next(nxt) {}

		Node()
		: index(-1), next(NULL) {}

		inline int getIndex() const {
			return index;
		}

		inline void setIndex(const int idx) {
			index = idx;
		}

		inline Node * getNext() const {
			return next;
		}

		inline void setNext(Node<T> * nextNode) {
			next = nextNode;
		}

		inline T getValue() const {
			return value;
		}

		inline void setValue(const T val) {
			value = val;
		}

		bool operator == (const Node<T> & n) const {
			return (index == n.index) && (value == n.value);
		}

		bool operator != (const Node<T> & n) const {
			return !(*this == n);
		}

	private:
		int index; // Element number, in the range [0, size)
		T value; // The value of this element.
		Node *next; // A pointer to the next node in the linked-list.
};

template <class T> class SparseVector {
	public:
		SparseVector(const int size = 1)
		: size(size), elements(new Node<T>()) {
			if (size <= 0)
				throw std::invalid_argument("Argument must be greater than zero!");
		}

		SparseVector(const SparseVector<T> & spvc)
		: size(spvc.size), elements(new Node<T>()) {
			*this = spvc;
		}

		~SparseVector() {
			Node<T> * aktElem = elements;
			while (aktElem) {
				Node<T> * nextElem = aktElem->getNext();
				delete aktElem;
				aktElem = nextElem;
			}
		}

		void print(std::ostream & out, const std::string seperator) {
			for (int i = 0; i < size; i++) {
				out << getElement(i) << seperator;
			}
		}

		T getElement(const int col) const {
			if ((col < 0) || (col >= size))
				throw std::out_of_range("Not a valid vector element!");
			Node<T> * elem = elements;
			while ((elem) && (elem->getIndex() < col))
				elem = elem->getNext();
			if (elem && (elem->getIndex() == col))
				return elem->getValue();
			return 0;
		}

		void setElement(const int col, const T value) {
			if ((col < 0) || (col >= size))
				throw std::out_of_range("Not a valid vector element!");
			Node<T> * lastElem = elements;
			Node<T> * aktElem = elements->getNext();
			while ((aktElem) && (aktElem->getIndex() < col)) {
				lastElem = aktElem;
				aktElem = aktElem->getNext();
			}
			if (!aktElem || (aktElem->getIndex() != col)) {
				if (value != 0)
					lastElem->setNext(new Node<T>(col, value, aktElem));
			} else if (value == 0) {
				lastElem->setNext(aktElem->getNext());
				delete aktElem;
			} else {
				aktElem->setValue(value);
			}
		}

		inline int getSize() {
			return size;
		}

		SparseVector & operator = (const SparseVector & spvc) {
			if (this == &spvc)
				return *this;
			size = spvc.size;

			Node<T> * aktElem = elements;
			Node<T> * newElem = spvc.elements->getNext();

			// overwrite existing nodes
			while (aktElem->getNext() && newElem) {
				aktElem = aktElem->getNext();
				aktElem->setIndex(newElem->getIndex());
				aktElem->setValue(newElem->getValue());
				newElem = newElem->getNext();
			}
			if (newElem) { // add new nodes
				while (newElem) {
					aktElem->setNext(new Node<T>(*newElem));
					newElem = newElem->getNext();
					aktElem = aktElem->getNext();
				}
			} else { // delete existing nodes
				aktElem = aktElem->getNext();
				while (aktElem) {
					Node<T> * nextElem = aktElem->getNext();
					delete aktElem;
					aktElem = nextElem;
				}
			}
			return *this;
		}

		bool operator == (const SparseVector & spvc) const {
			if (spvc.size != size)
				return false;
			Node<T> * aElem = elements->getNext();
			Node<T> * bElem = spvc.elements->getNext();
			while (aElem && bElem && (*aElem == *bElem)) {
				aElem = aElem->getNext();
				bElem = bElem->getNext();
			}
			return !aElem && !bElem;
		}

		bool operator != (const SparseVector & spvc) const {
			return !(*this == spvc);
		}

		SparseVector operator + (const SparseVector & spvc) const {
			checkDimensionError(spvc);
			SparseVector result(*this);
			return result += spvc;
		}

		SparseVector operator - (const SparseVector & spvc) const {
			checkDimensionError(spvc);
			SparseVector result(*this);
			return result -= spvc;
		}

		SparseVector & operator += (const SparseVector & spvc) {
			checkDimensionError(spvc);
			for (int i = 0; i < size; i++) {
				setElement(i, getElement(i) + spvc.getElement(i));
			}
			return *this;
		}

		SparseVector & operator -= (const SparseVector & spvc) {
			checkDimensionError(spvc);
			for (int i = 0; i < size; i++) {
				setElement(i, getElement(i) - spvc.getElement(i));
			}
			return *this;
		}
	private:
		int size;
		Node<T> * elements;

		inline void checkDimensionError(const SparseVector & spvc) const {
			if (size != spvc.size)
				throw std::invalid_argument("Dimension must be the same!");
		}
};

#endif // SPARSEVEKTOR_HPP_INCLUDED

Danke auf jeden Fall schonmal für die vielen Kommentare - wer weitere hat: immer her damit ^^

Gruß Lars

//umsortieren zu index,next,value oder next,index,value. je nachdem, was 
//schneller sein soll, index oder next. value ans ende, weil größe unbekannt, 
//um kein überraschendes padding hervorzuholen

Kannst du das ein bißchen näher erläutern? Warum sollte das Padding (mit Standard-Compiler-Optionen) zum Problem werden? Und vor allem, welchen Unterschied macht die Reihenfolge von index und next?

volkard schrieb:

//umsortieren zu index,next,value oder next,index,value. je nachdem, was 
//schneller sein soll, index oder next. value ans ende, weil größe unbekannt, 
//um kein überraschendes padding hervorzuholen

Kannst du das ein bißchen näher erläutern? Warum sollte das Padding (mit Standard-Compiler-Optionen) zum Problem werden? Und vor allem, welchen Unterschied macht die Reihenfolge von index und next?

das erste member hat potentiell den schnellsten zugriff, denn da muß keine arithmetik mehr geschehen zwischen dem objektzeiger und dem zeiger aufs member.
also sucht man sich aus, ob index oder next den ehrenplatz bekommen soll. falls man jetzt schon abschätzen kann, welches attribut deutlich häufiger verwendet wird. kann man's nicht, isses vermutlich auch nicht deutlich messbar. dann läßt man es oder verschiebt die reihenfolgenfestlegung bis man einen praxisnahen datensatz hat und mißt kurz.
padding wird überraschend bei int(32)index, double(64)daten, T*(32)next, wenn der compiler die daten 64-aligned halten will, dann steht da int(32)index, dummy(32), double(64)daten, T*(32)next, dummy(32). und weil vermutlich sizeof(T*)==sizeof(size_t) ist man's vermutlich immer los, wenn die daten am ende stehen.

das erste member hat potentiell den schnellsten zugriff, denn da muß keine arithmetik mehr geschehen zwischen dem objektzeiger und dem zeiger aufs member.
also sucht man sich aus, ob index oder next den ehrenplatz bekommen soll. falls man jetzt schon abschätzen kann, welches attribut deutlich häufiger verwendet wird. kann man's nicht, isses vermutlich auch nicht deutlich messbar. dann läßt man es oder verschiebt die reihenfolgenfestlegung bis man einen praxisnahen datensatz hat und mißt kurz.

Macht das wirklich einen Geschwindigkeits-Unterschied, der in der Praxis relevant ist? Ich bezweifle nicht, daß der Zugriff auf das erste Member schneller sein kann, aber trotzdem wäre das so ziemlich das letzte, worüber ich mir beim Schreiben des Codes Gedanken machen würde (das böse P-Wort spare ich mir jetzt mal ;)).

volkard schrieb:

padding wird überraschend bei int(32)index, double(64)daten, T*(32)next, wenn der compiler die daten 64-aligned halten will, dann steht da int(32)index, dummy(32), double(64)daten, T*(32)next, dummy(32). und weil vermutlich sizeof(T*)==sizeof(size_t) ist man's vermutlich immer los, wenn die daten am ende stehen.

Nur daß ich das richtig verstehe: es geht dir um den Speicherbedarf des Objekts, nicht um die Geschwindigkeit der Zugriffe?

Macht das wirklich einen Geschwindigkeits-Unterschied, der in der Praxis relevant ist?

nicht relevant, unter besten umständen vielleicht ein prozent. aber hier kostenlos und unbedenklich. später denke ich nicht mehr dran, da mach ichs gleich.

dooooomi schrieb:

volkard schrieb:

padding wird überraschend bei int(32)index, double(64)daten, T*(32)next, wenn der compiler die daten 64-aligned halten will, dann steht da int(32)index, dummy(32), double(64)daten, T*(32)next, dummy(32). und weil vermutlich sizeof(T*)==sizeof(size_t) ist man's vermutlich immer los, wenn die daten am ende stehen.

Nur daß ich das richtig verstehe: es geht dir um den Speicherbedarf des Objekts, nicht um die Geschwindigkeit der Zugriffe?

ja.

Zunächst muss ich allerdings mal ein Missverständnis korregieren: Das ganze soll einen Vektor im mathematischen sinne darstellen. Size ist somit die Dimension des Vektors. Das ganze sollte so umgesezt werden, dass Elemente, die 0 sind nicht gespeichert werden (aber es gibt eben dennoch alle Elemente im Bereich 0 <= x < size). Dementsprechend macht meine Implementierund dann hoffentlich auch wieder an vielen Stellen Sinn.

Von deinen Tips habe ich noch einige umgesetzt:

• Node habe ich nun als Memberklasse von SparseVector implementier (da muss ja eh kein anderer dran) und die ganzen Getter/Setter entfernt (Klasse private aber alle Attribute public)
• copy-ctor: Anfangsinitialisierung von size entfernt.
• getSize konstant deklariert

Weiter schreibst du aber noch, dass du die ganzen Operatoren global deklarieren würdest. Warum?

Weiter schreibst du aber noch, dass du die ganzen Operatoren global deklarieren würdest. Warum?

wenn du mal nen ctor baust, der zum beispiel einen vector<int> nimmt.
dann kannste ja machen
vector<int> a=holeVectorVonFremdanbieter();
SparseVector<int> b;
//...b initialisieren
SparseVector<int> c=b+a;
aber nicht
SparseVector<int> c=a+b;
das verwirrt.
also globaler op+ sind linker und rechter operand gleicher.

Size ist somit die Dimension des Vektors.

ok.

Das ganze sollte so umgesezt werden, dass Elemente, die 0 sind nicht gespeichert werden (aber es gibt eben dennoch alle Elemente im Bereich 0 <= x < size). Dementsprechend macht meine Implementierund dann hoffentlich auch wieder an vielen Stellen Sinn.

ja, aber meinen vorschlag beim operator+ mag ich nochmal darlegen.
erstmal vorweg: wenn der vector immer sortiert vorliegen würde, wären die suchläufe im durchschnitt nur halb so lang bei treffern und genausolang bei nichttreffern. es kostet also wohl nix dazu, die liste als sortierte liste zu machen. und es ist auch ohne großen aufwand machbar.
nun nehme ich mal an, ich hab zwei dünn besetzte vektoren jeweils mit dimension 1000 und jeweils nur 50 komponeneten, die ungleich 0 sind.
das sollte doch dein hauptanwendungsgebiet sein, hoffe ich.
dein operator+ läuft in der äüßeren schleife von 0 bis 999 und sucht für beide vektoren von anfang bis ende, was zusammen 100 angeschaute elemente ergibt. also 1000-mal müssen alle elemente angeschaut werden.
mein gegenvorschlag braucht nur einmal alle elemente anzuschauen. der geht ungefähr wie der merge-schritt im merge-sort.

erstmal vorweg: wenn der vector immer sortiert vorliegen würde, wären die suchläufe im durchschnitt nur halb so lang bei treffern und genausolang bei nichttreffern. es kostet also wohl nix dazu, die liste als sortierte liste zu machen. und es ist auch ohne großen aufwand machbar.

Die Liste ist doch sortiert

volkard schrieb:

dein operator+ läuft in der äüßeren schleife von 0 bis 999 und sucht für beide vektoren von anfang bis ende, was zusammen 100 angeschaute elemente ergibt. also 1000-mal müssen alle elemente angeschaut werden.
mein gegenvorschlag braucht nur einmal alle elemente anzuschauen.

Da hast du recht. das könnte man noch beschleunigen, indem man die Listen beider Vektoren durchgeht, bei gleichem Index addiert und ansonsten das jeweilige Element direkt einfügt.