Warum kein assert in boost::array operator[]

[weg mit at]

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.

[:live:]

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.

[tipp!]

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...

[Gläuber]

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

[rüdiger]

@MaSTaH
ist vorallem dann sinnvoll, wenn das assert in Code ist, den man nicht selbst geschrieben hat oder wo es lange her ist, dass man den geschrieben hat. Dann weiß man eben sofort, was genau los ist und wie man das umgehen könnte.

[Ben04]

volkard schrieb:

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.

?

18.6.1 Class exception
namespace std {
class exception {
public:
exception() throw();
exception(const exception&) throw();
exception& operator=(const exception&) throw();
virtual ~exception() throw();
virtual const char* what() const throw();
};
} The class exception defines the base class for the types of objects thrown as exceptions by C++ Standard library components, and certain expressions, to report errors detected during program execution.

Wo std::exception da ein std::string rumschleppt ist mir rätzelhaft.

[volkard]

Ben04 schrieb:

Wo std::exception da ein std::string rumschleppt ist mir rätzelhaft.

und ich habe immer geglaubt, da sein einer drin. danke für die aufkärung. das freut mich, ich werde meine exceptions also fein von std:.exception erben lassen können.

[rüdiger]

std::runtime_error hat wohl intern einen String