[] vs. vector<>

Michael E.

Pro std::vector, u.a. weil:
- Selbstständiges Speichermanagement (new und delete brauchst du nicht mehr)
- Exceptions
- Grenzüberwachung
- Memberfunktionen, z.B. length()
- Iteratoren
- STL-Algorithmen können problemlos mit ihnen arbeiten

Woems

pro Vector

Michael E. schrieb:

- Selbstständiges Speichermanagement (new und delete brauchst du nicht mehr)

man brauch es nicht mehr zu löschen also delete kannste vergessen :p

Michael E. schrieb:

- Exceptions

mit try...catch kannste alle fehler abfangen

Michael E. schrieb:

- Grenzüberwachung

wird ne Exception ausgelöst, wenn du zu weit bist

Michael E. schrieb:

- Memberfunktionen, z.B. length()

vector<char> test;
test.resize(10,'t'); // 10x't'
cout<<test.length(); // 10

Michael E. schrieb:

- Iteratoren

for (vector<char>::iterator i=test.begin();i!=test.end();++i)
  cout<<(*i);

Michael E. schrieb:

- STL-Algorithmen können problemlos mit ihnen arbeiten

sort(test.begin(),test.end()); // bei 10x't' vielleicht nicht sinvoll*g*

virtuell Realisticer

Der []-op macht keine Bereichsueberpruefung.

mfg
v R

Woems

virtuell Realisticer schrieb:

Der []-op macht keine Bereichsueberpruefung.

stimmt, aber at() :p

Michael E.

Woems schrieb:

wird ne Exception ausgelöst, wenn du zu weit bist

IIRC wird bei at() ne out_of_range geworfen.

volkard

Guest1 schrieb:

Wie sieht es aus? Ist ein Einsatz von vector<> generell zu empfehlen und gegen [] zu ersetzen

auf gar keinen fall generell.
alle generalisierungen sind falsch.

oder sollte man doch die "alten Hausmittel" weiter verwenden? Was ist besser und warum?

also vector<vector<float> > als ersatz für 2-dimensionale arrays zu benutzen, ist performancetechnischer superoberdoppelriesenmist.

wenn überhaupt vector, dann nimm einen eindimenionalen und lies mal schnell nach, was slices sind.

und glaub heute ja keinem was. alle wollen dich nur in den april schicken.

*lol* @ volkard: das mit dem April glaub ich aber auch

Weiß trotzdem nicht was ich glauben soll. Entweder ich verwende weiter float** für meine Funktion oder vector < vector<float> >. Was denn nun?!

Achso, wenn ich nen vector löschen will, dann brauch ich schon delete, oder? War wohl ein ganz schlechter Aprilscherz?!

Ich glaube, ich hätte meine Frage morgen stellen sollen, heute hat das anscheinend wenig Sinn *grml*

Thx, Matze

volkard

Guest1 schrieb:

*lol* @ volkard: das mit dem April glaub ich aber auch

ok, nicht alle. ich meine natürich alles ernst. mich überrascht nur, daß alle anderen mit schlechten vorsachlägen kommen.

Weiß trotzdem nicht was ich glauben soll. Entweder ich verwende weiter float** für meine Funktion oder vector < vector<float> >. Was denn nun?!

du nimmst mich nicht erst, oder? schau nach, was slices (einzahl slice) sind. schau nach. schau nach. schau nach. schau nach.

Achso, wenn ich nen vector löschen will, dann brauch ich schon delete, oder?

nee. das macht der im destruktor alleine.

Ich glaube, ich hätte meine Frage morgen stellen sollen, heute hat das anscheinend wenig Sinn *grml*

kann heute aber schon mal lesen, was slices sind. es wird dich sicherlich inspirieren.

Michael E.

volkard schrieb:

Guest1 schrieb:

Wie sieht es aus? Ist ein Einsatz von vector<> generell zu empfehlen und gegen [] zu ersetzen

auf gar keinen fall generell.
alle generalisierungen sind falsch.

Eher nicht, aber in diesem Fall ACK.

oder sollte man doch die "alten Hausmittel" weiter verwenden? Was ist besser und warum?

also vector<vector<float> > als ersatz für 2-dimensionale arrays zu benutzen, ist performancetechnischer superoberdoppelriesenmist.

Das ist eine Generalisierung :p Außerdem stimme ich ihr nicht zu.

und glaub heute ja keinem was. alle wollen dich nur in den april schicken.

Glauben kann man schon, was ich geschrieben hab. Ich hab halt bloß die negativen Sachen weggelassen

Guest1: Wenn du nur die Funktionalitäten brauchst, die ein Array hat, dann nimm auch eins. Wenn irgendwas von den oben genannten Sachen gebrauchen kannst, solltest du Vorteile und Nachteile von nem vector feinsäuberlich abwägen.

volkard

oder sollte man doch die "alten Hausmittel" weiter verwenden? Was ist besser und warum?

also vector<vector<float> > als ersatz für 2-dimensionale arrays zu benutzen, ist performancetechnischer superoberdoppelriesenmist.

Das ist eine Generalisierung :p [/quote]
ok, ist eine.

Michael E. schrieb:

volkard schrieb:

auf gar keinen fall generell.
alle generalisierungen sind falsch.

Eher nicht, aber in diesem Fall ACK.

aber das war erst recht eine.

Außerdem stimme ich ihr nicht zu.

ok. aber

float **transpose(float **array){

ist ne andere geschichte. hier geht es wohl um eher kleine arrays mit mickrigen elementen, die voll bestückt sind. also wenn du für eine 10*10-matrize gerne 11 mal die kosten für einen operator new zahlst, ist das dein problem. aber ich petze da gerne und erzähle, daß es unheimlich lahm ist.

Glauben kann man schon, was ich geschrieben hab. Ich hab halt bloß die negativen Sachen weggelassen

naja, hast ein bißchen arg weggelassen.

Michael E.

volkard schrieb:

Michael E. schrieb:

volkard schrieb:

auf gar keinen fall generell.
alle generalisierungen sind falsch.

Eher nicht, aber in diesem Fall ACK.

aber das war erst recht eine.

Hast du mich falsch verstanden? Ich hab gemeint, dass man auf die gestellte Frage keine generelle Antwort geben kann, aber Generalisierungen allgemein nicht zwangsläufig falsch sein müssen. Da war jetzt keine Generalisierung drin.

Außerdem stimme ich ihr nicht zu.

ok. aber
float **transpose(float **array){
ist ne andere geschichte.

ACK. Hier sollte man (soweit mans bisher beurteilen kann) Arrays benutzen.

also wenn du für eine 10*10-matrize gerne 11 mal die kosten für einen operator new zahlst, ist das dein problem.

Kommt ganz auf den Fall an. Aber hier würd ich das wie gesagt nicht machen.

Glauben kann man schon, was ich geschrieben hab. Ich hab halt bloß die negativen Sachen weggelassen

naja, hast ein bißchen arg weggelassen.

*indieeckestell*

otze

Michael E. schrieb:

float **transpose(float **array){
ist ne andere geschichte.
ACK. Hier sollte man (soweit mans bisher beurteilen kann) Arrays benutzen.

ne, ein vector geht auch hier:

//10*10 vector erstellen
std::vector<float> v(100);
//auf element 3,5 zugreifen
v[3*10+5]=15.3f;

aber wahrscheinlich will volkard auf valarray/slice_array hinaus, oder irr ich mich da?

life

alle generalisierungen sind falsch

lol ziemlich paradox oder?

Michael E.

otze schrieb:

Michael E. schrieb:
float **transpose(float **array){
ist ne andere geschichte.
ACK. Hier sollte man (soweit mans bisher beurteilen kann) Arrays benutzen.
ne, ein vector geht auch hier:
//10*10 vector erstellen
std::vector<float> v(100);
//auf element 3,5 zugreifen
v[3*10+5]=15.3f;
aber wahrscheinlich will volkard auf valarray/slice_array hinaus, oder irr ich mich da?

Natürlich *geht* es auch. Es geht aber ums Beste.

volkard schrieb:

Weiß trotzdem nicht was ich glauben soll. Entweder ich verwende weiter float** für meine Funktion oder vector < vector<float> >. Was denn nun?!

du nimmst mich nicht erst, oder? schau nach, was slices (einzahl slice) sind. schau nach. schau nach. schau nach. schau nach.

Klar nehm ich dich ernst. Hab ja nie was anderes behauptet :p

Also ok: hab mir die Slices mal im "Stroustrup" angeschaut und es scheint so, als ob man mit ihnen und mit nem valarray einen schönen effektiven Datentypen bauen kann, auf den man genauso zugreifen kann wie auf ein mehrdim. Array.

Auch wenn ich noch nicht alles davon verstanden habe, scheint das Konzept doch recht effektiv zu sein. Gleich mal an die Umsetzung machen, ich bedanke mich erstmal bis hierhin, dass ihr einem armen C-Programmierer ein wenig C++ Nachhile gegeben habt

Danke, Matze

volkard

Guest1 schrieb:

Also ok: hab mir die Slices mal im "Stroustrup" angeschaut und es scheint so, als ob man mit ihnen und mit nem valarray einen schönen effektiven Datentypen bauen kann, auf den man genauso zugreifen kann wie auf ein mehrdim. Array.

netterweise steht ne fertige Matrix-Klasse da.

man könnte ich noch überlegen, eine TempTransMatrix-Klasse zu bauen, die keinen eigenen speicher besitzt, sondern nur eine referenz auf ein val_array einer länger bestehenden Matrix und die slices anders definiert, so daß man beim elementzugriff gleich das gefühl hat, als sei die matrix transponiert, aber in wirklichkeit hat man gar nix transponiert. sozusagen ne virtuelle transponierte. könnte speed bringen, wenn man öfters nur transpose für zwischenergebnisse braucht. man könnt's aber auch sein lassen, weil das noch viel zu schwierig ist.

volkard schrieb:

netterweise steht ne fertige Matrix-Klasse da.

Du meinst in dem Buch?
Ja dort schon, da brauch man eigentlich nur abschreiben
Aber das "Verstehen" des Codes ist wichtiger...

Das mit dem transpose() war nur ein Beispiel, was zwar auch implementiert ist, aber nur einen mickrigen Bestandteil darstellt. Daher sollte dort nicht der Fokus drauf liegen...

Danke für alles,
Matze

volkard schrieb:

netterweise steht ne fertige Matrix-Klasse da.

Du meinst in dem Buch?
Ja dort schon, da brauch man eigentlich nur abschreiben
Aber das "Verstehen" des Codes ist wichtiger...

Das mit dem transpose() war nur ein Beispiel, was zwar auch implementiert ist, aber nur einen mickrigen Bestandteil darstellt. Daher sollte dort nicht der Fokus drauf liegen...

Danke für alles,
Matze

Oh oh, dass mit valarrays und slices war keine gute Idee
Ich habe mein Programm, welches ein Neuronales Netz anlernt von float** auf die Klassen mit valarrays und slices 1:1 umgeschrieben und das Ergebnis ist grauenhaft:

Beim selben Lernprozess des Netzes benötigt die neue Version 300% der Zeit von der alten - soviel zum Thema "ich benutze mal kein float** mehr". Werd ich mir wohl schnell wieder aus dem Kopf schlagen :|

volkard

Guest1 schrieb:

Oh oh, dass mit valarrays und slices war keine gute Idee
Ich habe mein Programm, welches ein Neuronales Netz anlernt von float** auf die Klassen mit valarrays und slices 1:1 umgeschrieben und das Ergebnis ist grauenhaft:
Beim selben Lernprozess des Netzes benötigt die neue Version 300% der Zeit von der alten - soviel zum Thema "ich benutze mal kein float** mehr". Werd ich mir wohl schnell wieder aus dem Kopf schlagen :|

und? war der code am ende schöner zu lesen? war es einfacher, nicht immer an new oder delete denken zu müssen? haste was über c++ gelernt und war das im moment wichtiger, als ein bißchen speed? vermutlich schon.

ich gehe davon aus, daß du eine feine Matrix-Klasse gebaut hast. und daß du den code von struppi auch kapiert hast. und daß das vorher viel zu kompliziert gewesen wäre, mir dir weiter über nette techniken zu quatschen. und da gibt es noch schrecklich viel zu erzählen.

so, von deiner Matrix-klasse zu sowas wie

//ungetestet
size_t roundedDownLog2(size_t x){
	int r=0;
	while(x/=2)
		++r;
	return r;
}
size_t roundedUpLog2(size_t x){
	return roundedDownLog2(x-1)+1;
}

template<typename T>
class Array{
private:
	T* data;
	Array(Array const&);
	Array& operator=(Array const&);
public:
	Array(size_t size){
		data=new T[size];
	}
	~Array(){
		delete[] data;
	}
	T& operator[](size_t index){
		return data[index];
	}
};

template<typename T>
class FastArray2d{
private:
	size_t shift;
	Array<T> data;
public:
	FastArray2d(size_t sizey,size_t sizex):
		shift(roundedUpLog2(sizex)),
		data(sizey<<shift){
	}
	struct Proxy{
		FastArray2d* array;
		size_t y;
		Proxy(FastArray2d* _array,size_t _y):
		array(_array),
		y(_y){
		}
		T& operator[](size_t x){
			return array->at(x,y);
		}
	};
	Proxy operator[](size_t y){
		return Proxy(this,y);
	}
	T& at(size_t y,size_t x){
		return data[(y<<shift)+x];
	}
};

ist es doch nur noch ein katzensprung.

setz die mal ein. und wenn die auch lahmer ist als rohe float**, dann packen wir einfach mal die float** in die Matrix-klasse und besorgen uns damit wenigstens das schöne automatische delete und müssen nicht mehr immer ** schreiben.

sag mal die zeiten von FastArray2d, das hab ich nämlich noch nie gemessen, es "fühlt" sich nur schnell an.

(wenn y die äußere und x die innere schleife ist) schneller ist als a[x][y]. also wie die eingebauten arrays.

[] vs. vector&lt;&gt;

[] vs. vector<>