array vs vector

[Shade Of Mine]

@asmcode:
Ich liebe es wenn Halbwissen verwendet wird. Standardmaessig hat vector beim VC++ einen range check dabei, zB sind auch iteratoren standardmaessig langsamer da jeder iterator einen next zeiger auf einen anderen iterator hat und bei jedem invalidate von iteratoren (bei vector zB einem reallocate) oder auch wenn der container zerstoert wird, gibt es ein notify an alle iteratoren.

das kostet performance und es gibt viel streiterei ob man es im release code drinnen haben will. das muss jeder selbst entscheiden:
#define _SECURE_SCL 0
um es abzudrehen.

und dann sind array und vector auch exakt gleich schnell. natuerlich muss man mehr als einen durchgang testen, aber das sollte klar sein.

ich habe deinen code genommen und foo und bar jeweils dTimeDiff returnen lassen und dann abwechselnd 30 mal foo und bar gecallt:

30 runs.
vec: overall: 36.5086
arr: overall: 36.556

vec: average: 1.21695
arr: average: 1.21853

lustigerweise ist vec in der messung sogar schneller gewesen. aber das ist nichts anderes als ein messfehler, da der generierte code identisch sein muesste.

PS:
es scheint mittlerweile verloren gegangen zu sein. aber frueher war eines der wichtigsten features von c++ das zero cost principle: abstraktion ist gratis.

wenn ich ein normales array nehme und es in eine klasse stecke, dann habe ich dadurch keine runtime kosten. wenn ich jetzt aber zB range checking will, dann kostet das natuerlich schon. aber wenn ich das ohne vector machen wuerde, waere es ja auch nicht gratis.

dieses zero cost principle: ich zahle keine performance kosten fuer abstraktion, scheint irgendwo verloren gegangen zu sein - da ich solche threads wie diesen immer wieder lese. finde ich irgendwie schade.

denn das fasziniert mich an c++ eigentlich so: es gibt keine magie. alles liegt klar und deutlich vor einem...

[asmcode]

Und wie kommt MS auf die dumme Idee bei [] jetzt auch nen range check einzubauen. Ich bin davon ausgegangen, dass der nur bei at() gemacht wird. Steht das nicht im Standard drin, dass das so sein soll?

[asc]

asmcode schrieb:

Und wie kommt MS auf die dumme Idee bei [] jetzt auch nen range check einzubauen. Ich bin davon ausgegangen, dass der nur bei at() gemacht wird. Steht das nicht im Standard drin, dass das so sein soll?

Bei at ist die Prüfung Pflicht, bei [] ist sie erlaubt. Die Lösung über ein Makro halte ich durchaus für akzeptabel, hätte aber besser an einer Stelle stehen sollen wo man sie nicht so leicht übersieht (z.B. ein Schalter in den Projekteinstellungen).

cu André

[asmcode]

Oder einfach defaultmäßig aus. So ist es ja fast schon so wie ein Compiler der im Releasemodus defaultmäßig nicht optimieren würde.

[Shade Of Mine]

Es macht durchaus Sinn diese Sicherheitsfeatures einzubauen. Standardmaessig sind sie deshalb aktiv, da MS davon ausgeht dass Leute die es wollen ja ausschalten koennen und die Leute die das nicht interessiert, die sind mit den Ueberpruefungen besser dran.

Ob das Sinn macht ist natuerlich Diskussionswuerdig, aber das ist der Status Quo. Warum nicht mal Doku zum eigenen Compiler lesen...? Mich stoerts nicht, da ich es ja abdrehen kann wenn ich es brauche...

[hustbaer]

Ich finde das auch nicht so schlimm. Abgesehen davon ist der Zug abgefahren bezüglich opt-in vs. opt-out.

[Pellaeon]

Naja so prickelnd finde ich das von MS nicht. Das hat mir mal nen schönen Fehler eingehandelt. In einer DLL hatte ich mal testweise den Define drinne, die Hauptanwendnung hatte sie nicht. Nun gabs dauernd Laufzeitfehler. Gut, selber Schuld, aber bis man sowas manchmal entdeckt^^ Von daher mag ich dieses rumstellen per define als Compile-Schalter perse nicht. Das ist ja nicht mal als normale Option in den Eigenschaften drinne. Und auf die Laufzeit kann es sioch ja wirklich negativ ausüben, muss natürlich nicht.

bezüglich opt-in vs. opt-out.

Ich steh grad aufm Schlauch^^ Was willst du uns damit sagen?

Warum nicht mal Doku zum eigenen Compiler lesen...?

Wie weit bist du denn in der MSDN voran geschritten? Ist ja nicht gerade wenig
Ich muss sagen, dass der operator[] ne Überprüfung macht, habe ich auch net gewusst. Ich kannte auch nur das, was in meinem STL-Buch steht: nämlich das das at prüft und [] eben nicht! (und für so ein Buch hab ich 30 Euro gelöhnt^^)

Aber aufregen bringt ja nix. is halt so. Und deswegen wieder anfangen alles per Hand zu allokieren: sicher nicht!

[hehehe]

Pellaeon schrieb:

Warum nicht mal Doku zum eigenen Compiler lesen...?

Wie weit bist du denn in der MSDN voran geschritten? Ist ja nicht gerade wenig

Ich glaub der macht den ganzen Tag nix anderes als Dokus, Bücher und Diskussionen zu lesen.

[__Stefan__]

Ich sehe den Sinn dieses Range Checks nicht. Der wirft ja nicht mal eine exception. Als release schmiert das Programm einfach ab (Visual C++ 2008).

vector<int> v(10);

	try
	{
		v[10] = 0;
	}
	catch(exception &ex)
	{
		cout << ex.what();
	}
	catch(...)
	{
	}

[hehehe]

Schutz gegen Hacker?

[Don06]

Stefan schrieb:

Ich sehe den Sinn dieses Range Checks nicht. Der wirft ja nicht mal eine exception. Als release schmiert das Programm einfach ab (Visual C++ 2008).

Sei froh! Ohne Rangchecks läuft das Programme einfach durch, ohne das irgendwas passiert (ja, ich weiß undefiniertes Verhalten, bei mir, mit meinem Kompiler, auf meinem Computer, zu eben dieser Uhrzeit, an eben diesem Ort, bei dieser spezifischen Raumtemparatur passiert nichts). Es wäre doch fatal, wenn solche riesigen Programmierfehler sich in keinster Weise bemerkbar machen. Ein kleiner Programmierfehler in der Software fliegt also eventuell erst auf, wenn das Produkt schon beim Kunden ist. Und dann hat man noch das Problem, dass man nicht weiß, wo der Fehler aufgetreten ist.
Selbst, wenn sich eine Range-Überschreitung "nur" in einem Absturz bemerkbar macht, so lässt sich der Ort des Fehlers doch stark einschränken. In jedem größeren Software Projekt werden die Komponenten ja einzeln getestet. Je nach dem welcher Test dann abstürzt, kennt man dann die defekte Komponente.

[Nexus]

Ja, aber eine Exception wär trotzdem besser...

[Don06]

Geht auch: _SCL_SECURE_THROWS.

Gruß
Don06

[Shade Of Mine]

Nexus schrieb:

Ja, aber eine Exception wär trotzdem besser...

exceptions kann man ignorieren.

deshalb: nie nie nie nie nie eine exception werfen wenn es sich um logik fehler handelt. zumindest keine die man fangen kann. sonst kommt sowas raus was man in java hat, dass fehler einfach immer ignoriert werden "weil das programm ja eh problemlos durchlaeuft".

[Skym0sh0]

const_reference operator[](size_type _Pos) const
		{	// subscript nonmutable sequence

 #if _HAS_ITERATOR_DEBUGGING
		if (size() <= _Pos)
			{
			_DEBUG_ERROR("vector subscript out of range");
			_SCL_SECURE_OUT_OF_RANGE;
			}
 #endif /* _HAS_ITERATOR_DEBUGGING */
		_SCL_SECURE_VALIDATE_RANGE(_Pos < size());

		return (*(_Myfirst + _Pos));
		}

	reference operator[](size_type _Pos)
		{	// subscript mutable sequence

 #if _HAS_ITERATOR_DEBUGGING
		if (size() <= _Pos)
			{
			_DEBUG_ERROR("vector subscript out of range");
			_SCL_SECURE_OUT_OF_RANGE;
			}
 #endif /* _HAS_ITERATOR_DEBUGGING */
		_SCL_SECURE_VALIDATE_RANGE(_Pos < size());

		return (*(_Myfirst + _Pos));
		}

also das ist der code zum []-operator mit dem range check...

[Bitte geben Sie einen]

Shade Of Mine schrieb:

Nexus schrieb:

Ja, aber eine Exception wär trotzdem besser...

exceptions kann man ignorieren.

deshalb: nie nie nie nie nie eine exception werfen wenn es sich um logik fehler handelt. zumindest keine die man fangen kann. sonst kommt sowas raus was man in java hat, dass fehler einfach immer ignoriert werden "weil das programm ja eh problemlos durchlaeuft".

Warum machts dann vector.at? http://msdn.microsoft.com/en-us/library/c6kkh778(VS.80).aspx

If _Off is greater than the size of the vector, at throws an exception.

[Shade Of Mine]

Bitte geben Sie einen schrieb:

Warum machts dann vector.at?

Weil man bei .at() explizit sagt "ich bin zu dumm auf size() zu pruefen".

[Bitte geben Sie einen]

Programmiert wirklich jemand so?

try{
  while(true)
    vector.at
}
catch(...){
}

[Shade Of Mine]

Bitte geben Sie einen schrieb:

Programmiert wirklich jemand so?

try{
  while(true)
    vector.at
}
catch(...){
}

jein, natuerlich nicht so in einer schleife.
aber wenn das programm eine exception wirft und ich fange die exception einfach und tue nichts und das programm laeuft "fehlerlos" durch - dann ist das problem geloest und ich kann es vergessen.

das sieht man zB in java gut, wo dank checked exceptions es massig try{foo()}catch(Exception e){} bloecke gibt.

die wirkliche frage bei exceptions ist aber auch: wie soll ich darauf reagieren?
wenn ich einfach mist gebaut habe und das programm sachen macht die es nie machen darf, zB out of bounds array zugriffe - wie soll ich darauf sinnvoll reagieren? eigentlich muss ich jetzt debuggen und die anwendung nicht mehr weiter ausfuehren - denn ich kann nicht garantieren dass alle komponenten in einem gueltigen zustand sind. wenn man jetzt normal weiter macht und den fehler ignoriert, kann man nciht mehr das fehlerfreie verhalten der software garantieren.

deshalb: nie logik fehler ignorieren.

hier hilft uebrigens auch keine VM wie java oder .net

[Nexus]

@ Shade Of Mine:
Du hast natürlich Recht, grundsätzlich ist es sicherer, das Programm direkt zu beenden. Von vernünftigen Anwender sollte man allerdings erwarten können, dass sie ihr Programm nicht mit sinnlosen catch(...) -Blöcken füllen (ich weiss, die Realität sieht anders aus). Trotzdem ist es ja schlussendlich das Problem des Anwenders, wenn er unfähig ist, auf Exceptions zu reagieren.

Exceptions haben aber den Vorteil, dass wenn man sie nicht fängt, man gerade sieht, wo sie aufgetreten sind und zusätzlich noch Information über den String erhält. Bei direktem Programmabsturz muss man evtl. mühsam durchdebuggen, bis man die Ursache findet. Aber es ist halt sicherer, weil der Absturz nicht ignoriert werden kann.

Shade Of Mine schrieb:

deshalb: nie nie nie nie nie eine exception werfen wenn es sich um logik fehler handelt. zumindest keine die man fangen kann.

Man kann jede Exception fangen. Oder was meinst du?

Und wenn man alles idiotensicher machen will, dürfte man im Prinzip nie Exceptions werfen, weil alle ignoriert werden können. Dann ist das Feature der Exceptions von C++ in deinen Augen unnötig oder sogar gefährlich? Oder wieso meinst du, betrifft das nur Logikfehler? Weil die eher ignoriert werden als andere Exceptions?