Warum kein assert in boost::array operator[]

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

Tankian

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.

Wie du ja bereits gesagt hast, kannst dir ja selbst schreiben. Soweit ich weiß
war std::logic_error sogar dafür gedacht, assert irgendwie ersetzen zu können.
Blöd is es nur wenn solche Fehlermeldungen bei einem catch(...) untergehen ..

operator void

volkard schrieb:

jo, ich war nicht da.
assert() ist böse.

Rumbasteln könnte man aber auch, wenn assert() als Standard vorgegeben wäre - und dann könnte man per search&replace auch viel komfortabler sein eigenes assert reinschmuggeln. Es ist ja nicht nur op[], den man falsch benutzen kann.

Ich bleib bei der traurigen ODR-Theorie