Warum kein assert in boost::array operator[]
-
Hi,
weiß einer warum der operator[] von boost::array kein assert für Bereichsüberschreitungen eingebaut hat?
-
Zeitverschwendung?
-
Ich finde eher das es Zeitverschwendung ist einen Fehler zu lokalisieren, den man mit assert viel schneller finden würde.
-
ness schrieb:
Zeitverschwendung?
Dumme Aussage? Seit wann kostet ein assert Zeit?
@assert-Fan: Ich weiß es nicht wirklich, aber ich würde auf jeden Fall eins einbauen, ist ja schnell gemacht.
-
ist mir leider auch unverständlich. Schreib doch mal einen patch dafür. Wenn der Autor das nicht will, wird er dir auch Rede und Antwort stehen müssen
-
assert-Fan schrieb:
weiß einer warum der operator[] von boost::array kein assert für Bereichsüberschreitungen eingebaut hat?
Vielleicht weil es mit der Methode at() bereits eine Zugriffsmethode mit Range-Check gibt und weil boost::array möglichst nah an einem "normalen" Array sein sollte.
-
@HumeSikkins
es geht ja gar nicht um at. Sondern darum, dass man einfach eine Erleichterung beim Debugen haben will.
-
Also diese scheiss at Methode könnten die ruhig rausschmeissen. Wie konnte man sowas dummes nur einbauen?
-
@Optimizer: stimmt, hast recht, bezog mich auf Zugriffsprüfung (at())
-
HumeSikkins schrieb:
Vielleicht weil es mit der Methode at() bereits eine Zugriffsmethode mit Range-Check gibt und weil boost::array möglichst nah an einem "normalen" Array sein sollte.
Nur leider hat dann boost::array lediglich die vorteile, dass es die Operatoren definiert die einem Array fehlen. Was nicht wirklich eine so große Hilfe ist.
Ein assert() (bzw. BOOST_ASSERT) würde das Interface nicht ändern, aber garantieren dass kein undefiniertes verhalten auftritt. Denn genau _das_ ist IMHO das Hauptproblem.
Aber ich scheine mit meiner Meinung zu assert ziemlich alleine zu stehen
also: nevermind 
-
Shade Of Mine schrieb:
Aber ich scheine mit meiner Meinung zu assert ziemlich alleine zu stehen
also: nevermind Wieso? Fast alle hier im Thread haben sich doch für ein assert ausgesprochen. Oder verstehe ich hier alles falsch?
-
Hallo,
nur mal so: ich schrieb "vielleicht", weil das eine Vermutung war. Ich würde es anders machen (mit assert) und ich weiß nicht warum die boost-Array-Leute es so gemacht haben. Deshalb schrieb ich "vielleicht" gefolgt von einer denkbaren Begründung.
-
Alle stehen auf deiner Seite Shade.
-
Am besten jemand schreibt einen Patch und schickt den da einfach hin. Dann steht der Name sogar in den Boost Releases, wenn man Erfolg hat, ansonsten erklären die Leute sicher die Argumente, warum sie den Patch nicht in das Release aufnehmen wollen.
-
Das könnte einfach mal jemand in der Boost Mailinglist nachfragen.
-
Jester schrieb:
Oder verstehe ich hier alles falsch?
Hier ist es überaschenderweise anders. Normalerweise sind mehr assert() Gegner als Befürworter da...
-
Ich glaube hier ist kein einziger assert-gegner.
-
Meine Vermutung war, dass man mit selektiv gesetztem NDEBUG dann die ODR verletzen würde. Dann wäre op[] ja nicht in allen Übersetzungseinheiten gleich.
-
Shade Of Mine schrieb:
Jester schrieb:
Oder verstehe ich hier alles falsch?
Hier ist es überaschenderweise anders. Normalerweise sind mehr assert() Gegner als Befürworter da...
jo, ich war nicht da.
assert() ist böse.
aber nicht debuggen können ist die hölle.
also wer sich ein gutes assert-replacement schreiben kann, soll das tun.
wer nicht, soll assert nehmen.
alle sollen aber den op[] nehmen können.
destawegen ist es gut, daß er kein assert drin hat.
man kann es ja mit weniger als 100 tastendrücken leicht selbst nachrüsten. wer asser mach, shreibt sich das rein. wer was cooleres mag, schreibt sich jenes rein.zum cooleren. es sollte im release-mode einfach das gleiche wie assert machen. also nix. und im debug-mode sollte es ne exception werfen. das garantier, dass evtl ressourcen, dei echt unbedingt geschlossen werden müssen, auch zu gehen. ich mach in mein ASSERT auch ein "__asm int 3" rein, dann geht der debugger genau in der zeile auf, wo das ASSERT steht.
solange es kein geiles assert im standard gibt, isses besser, keinen zu einer variante zu zwingen und stattdessen die wahl frei zu lassen.
ok. man könnte es konfigurierbar machen. mach baut eine <assert>, in der neben ein paar includes ein makro lebt. #ifndef ASSERT #define ASSERT STD_DEFAULTASSERT #endif. uns sonst nix. und ein jeder kann sich das gerne umbiegen. aber so weit war einfach die c++welt beim letzten stanbdard noch nicht und jetzige implementierungen von zusatzlibs sollten nicht den standard forcieren, sondern möglichst verträglich mit ihm leben. die ... (den rest denkt euch)
-
@volkard
ja, das Standard assert ist nicht so toll.Das muss man ein wenig aufputschen. Neben dem, was du bereits vorgeschlagen hast (int 3 oder exception), finde ich es vorallem nützlich noch eine Textinformation mitgeben zu können, damit man den Fehler gleich erklärt. Ein "assertion failed i<3" ist ja nicht unbedingt verständlich