Warum kein assert in boost::array operator[]

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.

rüdiger

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

HumeSikkins

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.

rüdiger

@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?

ness

@Optimizer: stimmt, hast recht, bezog mich auf Zugriffsprüfung (at())

Shade Of Mine

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

Jester

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?

HumeSikkins

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.

rüdiger

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.

Shade Of Mine

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.

operator void

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.

volkard

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)

rüdiger

@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

Walli

Wieso brauchst du das? Im Idealfall bringt dich die Assertiation doch in die entsprechende Codezeile.

volkard

kingruedi schrieb:

(int 3 oder exception)

und statt oder

finde ich es vorallem nützlich noch eine Textinformation mitgeben zu können

solange es kein std::string ist. kann mir immer nochz nocht erklären, was die leute gedacht haben, als sie std::exception mit std::string implementiert haben. sollen jetzt meine WinException mit dem int aus GetLastError drin den text mit FormatMessage auslesen und gleich in den std::string schreiben. nee. ist schwach. lieber erst beim anzeigen. und dann führe ich immer in der basisklasse nen nutzlosen string mit.

damit man den Fehler gleich erklärt. Ein "assertion failed i<3" ist ja nicht unbedingt verständlich

die netten "Datei konnte nicht geöffnet werden" aus win sind normalerweise zufriedenstellend. ganz extravagant wäre es noch, den dateinamen mitzugeben.

aber i<3-fehler können eigentlich so stehen bleiben ohne text. die muss man ja eh mit dem debugger angucken und sie sind schneller weggemacht als hingemacht. und finden sich im code von heute oder gestern.

Tankian

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

Na wenns dir so wies jetzt ist nicht reicht, dann kannst es doch so benutzen:

#include <cassert>

void f()
{
    int i = 5;
    std::assert(i != 5 && "i ist nicht gleich 5");
}

Konsole:
Assertion failed: i != 5 && "i ist nicht gleich 5", file ..., line ...

Ist zwar nicht die schönste möglichkeit, wird aber
sowieso nur beim debuggen benutzt.

Tankian