On Sunday, 9 July 2017 at 10:37:53 UTC, Steven Schveighoffer
wrote:
On 7/9/17 5:14 AM, Walter Bright wrote:
On 7/7/2017 7:31 AM, Nicholas Wilson wrote:
asserts that the this pointer is not null, apparently which
is annoying because you'd crash anyway. I suppose you might
get a nicer error message but it doesn't add much.
If I recall correctly, the nicer message was the reason. (It
was a long time ago.)
This kind of thing has been asked for, a lot. The current
thread entitled:
"All asserts need to have messages attached! Explicit as
possible!"
is representative.
Wait, you have stated many many times, a segfault is good
enough, it's not worth the added cost to do null pointer
exceptions (a position I'm completely in agreement with). Yet,
here is an example of where we have effectively added a null
pointer exception. At the very least, this should be eliminated
on Linux and just use the signal handling null pointer error
mechanism!
Note that there is a significant difference between this
situation (where you are *adding* an extra check), and the
argument to add messages to asserts (where you are *already*
asserting). For the record, I also don't agree that all asserts
need messages.
Also noted, even if you inline, the assert is still there.
Those who want to keep asserts (particularly for safety
reasons), will pay this penalty.
In things like smart pointer wrappers or converters, many
things are properties. inlining these is supposed to boil down
to simply accessing the right field, with zero added cost. That
is also a lie.
Or factoring out pieces of a function into more modular member
functions. Now you are compounding the asserts. When calling
another member function from within one, there is no reason to
re-assert `this !is null`.
We need to get rid of this feature, or at least make it
optional (and by optional, I mean opt-in). And no, having
-release remove all asserts is not the same as having the
ability to eliminate asserts I never wrote or wanted. At least
the assert shouldn't appear in virtual functions (which will
never fail because the vlookup will segfault before it ever
gets there).
I've been using D for 10 years, and have never triggered this
assert. But I've apparently paid for it that entire time.
-Steve
In C++, but I recently ran across this problem debugging LLVM and
wasted a good while trying to figure out what was causing the
crash. This would have been a useful feature (actually if i had
been comping in debug mode I would have hit that informative
assert but I was too stubborn to recompile), so it does have its
place but I think on by default is not it and certainly if it is
not under my control.
The most annoying part is that the struct will _never_ be passed
by pointer, its a struct that contains a struct that contains a
pointer, POD if ever there was. In the older models of OpenCL you
can't have pointers to pointers _at all_ so by definition the
assert will never be triggered.
