On Monday, July 10, 2017 11:26:43 AM MDT Walter Bright via Digitalmars-d
wrote:
> On 7/9/2017 6:37 PM, Jonathan M Davis via Digitalmars-d wrote:
> > For some assertions, having more than a file and line number is nice
> > (e.g. if you have messages for your pre-condition assertions, then you
> >
On 7/9/2017 4:37 AM, Steven Schveighoffer wrote:
On 7/9/17 7:00 AM, Walter Bright wrote:
On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:
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
On 7/9/2017 6:37 PM, Jonathan M Davis via Digitalmars-d wrote:
For some assertions, having more than a file and line number is nice (e.g.
if you have messages for your pre-condition assertions, then you can make it
so that when it fails, the programmer doesn't even need to look at the
source
https://github.com/dlang/dmd/pull/6982
On Sunday, July 9, 2017 4:00:33 AM MDT Walter Bright via Digitalmars-d
wrote:
> On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:
> > 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
On 7/9/17 8:04 AM, Timon Gehr wrote:
On 09.07.2017 13:57, Steven Schveighoffer wrote:
3. Classes are where you might see this issue, as people declare a
class and try to use it without allocating one all the time. But in
this case, when you are calling a virtual function, the segfault
occurs
On 09.07.2017 13:57, Steven Schveighoffer wrote:
3. Classes are where you might see this issue, as people declare a class
and try to use it without allocating one all the time. But in this case,
when you are calling a virtual function, the segfault occurs before the
assert can ever be used.
On 7/9/17 7:45 AM, Nicholas Wilson wrote:
On Sunday, 9 July 2017 at 11:37:55 UTC, Steven Schveighoffer wrote:
On 7/9/17 7:00 AM, Walter Bright wrote:
On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:
Yet, here is an example of where we have effectively added a null
pointer exception. > At
On 7/9/17 7:10 AM, Walter Bright wrote:
On 7/7/2017 7:26 AM, Steven Schveighoffer wrote:
And since when did we care about null pointers causing segfaults?
Remember Tony Hoare's "The Billion Dollar Mistake"? That added a lot of
fuel to the fire that a null pointer seg fault is supposed to be
On Sunday, 9 July 2017 at 11:37:55 UTC, Steven Schveighoffer
wrote:
On 7/9/17 7:00 AM, Walter Bright wrote:
On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:
Yet, here is an example of where we have effectively added a
null pointer exception. > At the very least, this should be
eliminated on
On 7/9/17 7:00 AM, Walter Bright wrote:
On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:
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
On Sunday, 9 July 2017 at 11:13:02 UTC, Walter Bright wrote:
On 7/7/2017 7:08 AM, Nicholas Wilson wrote:
It is certainly unacceptable in the long run to demand that if
users wish to use DCompute that they can't have asserts _in
the code running in the host_.
One thing you can do is replace:
On 7/7/2017 7:08 AM, Nicholas Wilson wrote:
It is certainly unacceptable in the
long run to demand that if users wish to use DCompute that they can't have
asserts _in the code running in the host_.
One thing you can do is replace:
assert(i > 3);
with:
if (!(i > 3)) assert(0);
On 7/7/2017 7:26 AM, Steven Schveighoffer wrote:
And since when did we care about null pointers causing segfaults?
Remember Tony Hoare's "The Billion Dollar Mistake"? That added a lot of fuel to
the fire that a null pointer seg fault is supposed to be avoided at all costs,
leading to wanting
On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:
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).
That's right.
Yet, here is an example of where we have effectively
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
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
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
On 07.07.2017 16:17, Jonathan M Davis via Digitalmars-d wrote:
On Friday, July 7, 2017 1:38:13 PM MDT Stefan Koch via Digitalmars-d wrote:
On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer
wrote:
On 7/7/17 4:21 AM, Nicholas Wilson wrote:
The compiler seems to inset an `assert(this
On Friday, July 7, 2017 2:31:42 PM MDT Nicholas Wilson via Digitalmars-d
wrote:
> On Friday, 7 July 2017 at 14:17:34 UTC, Jonathan M Davis wrote:
> > What does it even do?
>
> asserts that the this pointer is not null, apparently which is
> annoying because you'd crash anyway. I suppose you might
Steven Schveighoffer wrote:
On 7/7/17 4:26 PM, ketmar wrote:
Steven Schveighoffer wrote:
On 7/7/17 2:27 PM, ketmar wrote:
ketmar wrote:
yeah, this is annoying. while checking for "null this" in *class*
method may look hacky
tbh, i see nothing wrong in checking for "null this" even in
On 7/7/17 4:26 PM, ketmar wrote:
Steven Schveighoffer wrote:
On 7/7/17 2:27 PM, ketmar wrote:
ketmar wrote:
yeah, this is annoying. while checking for "null this" in *class*
method may look hacky
tbh, i see nothing wrong in checking for "null this" even in class
methods, but this is a
Steven Schveighoffer wrote:
On 7/7/17 2:27 PM, ketmar wrote:
ketmar wrote:
yeah, this is annoying. while checking for "null this" in *class*
method may look hacky
tbh, i see nothing wrong in checking for "null this" even in class
methods, but this is a completely different story.
In
On 7/7/17 2:27 PM, ketmar wrote:
ketmar wrote:
yeah, this is annoying. while checking for "null this" in *class*
method may look hacky
tbh, i see nothing wrong in checking for "null this" even in class
methods, but this is a completely different story.
In *final* methods maybe. Virtual
ketmar wrote:
yeah, this is annoying. while checking for "null this" in *class* method
may look hacky
tbh, i see nothing wrong in checking for "null this" even in class methods,
but this is a completely different story.
Steven Schveighoffer wrote:
Hm... it doesn't look like an invariant, it just looks like an inserted
assert inside every function.
An incorrect assert, IMO:
struct Foo
{
int x;
void foo() {}
}
void main()
{
Foo *foo;
foo.foo(); // shouldn't assert, wouldn't crash anyway.
}
On Friday, 7 July 2017 at 14:26:57 UTC, Steven Schveighoffer
wrote:
Hm... it doesn't look like an invariant, it just looks like an
inserted assert inside every function.
Ahh, thats why I get duplicate asserts when I add an assert.
And since when did we care about null pointers causing
On Friday, 7 July 2017 at 14:17:34 UTC, Jonathan M Davis wrote:
What does it even do?
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.
I don't see how it makes any
On 7/7/17 9:38 AM, Stefan Koch wrote:
On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer wrote:
On 7/7/17 4:21 AM, Nicholas Wilson wrote:
The compiler seems to inset an `assert(this !is null, "null this");`
into my struct.
which is for all intents and purposes.
struct Foo {
Bar
On Friday, July 7, 2017 1:38:13 PM MDT Stefan Koch via Digitalmars-d wrote:
> On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer
>
> wrote:
> > On 7/7/17 4:21 AM, Nicholas Wilson wrote:
> >> The compiler seems to inset an `assert(this !is null, "null
> >> this");` into my struct.
> >>
On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer
wrote:
On 7/7/17 4:21 AM, Nicholas Wilson wrote:
The compiler seems to inset an `assert(this !is null, "null
this");` into my struct.
which is for all intents and purposes.
struct Foo {
Bar b;
}
struct Bar {
void* ptr;
}
On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer
wrote:
On 7/7/17 4:21 AM, Nicholas Wilson wrote:
The compiler seems to inset an `assert(this !is null, "null
this");` into my struct.
which is for all intents and purposes.
struct Foo {
Bar b;
}
struct Bar {
void* ptr;
}
On 7/7/17 4:21 AM, Nicholas Wilson wrote:
The compiler seems to inset an `assert(this !is null, "null this");`
into my struct.
which is for all intents and purposes.
struct Foo {
Bar b;
}
struct Bar {
void* ptr;
}
What? When is this invariant called? I've never heard of a hidden
On Friday, 7 July 2017 at 08:21:50 UTC, Nicholas Wilson wrote:
The compiler seems to inset an `assert(this !is null, "null
this");` into my struct.
which is for all intents and purposes.
struct Foo {
Bar b;
}
struct Bar {
void* ptr;
}
I tried disabling the invariant but it complained
On Friday, 7 July 2017 at 08:35:28 UTC, Nicholas Wilson wrote:
On Friday, 7 July 2017 at 08:24:22 UTC, Stefan Koch wrote:
On Friday, 7 July 2017 at 08:21:50 UTC, Nicholas Wilson wrote:
[...]
Looks like you'd need to do your own hack to disable this
particular assert.
When it's used in a
On Friday, 7 July 2017 at 08:24:22 UTC, Stefan Koch wrote:
On Friday, 7 July 2017 at 08:21:50 UTC, Nicholas Wilson wrote:
[...]
Looks like you'd need to do your own hack to disable this
particular assert.
When it's used in a dcompute-context.
Problem is it gets decided wy before.
On Friday, 7 July 2017 at 08:21:50 UTC, Nicholas Wilson wrote:
The compiler seems to inset an `assert(this !is null, "null
this");` into my struct.
which is for all intents and purposes.
struct Foo {
Bar b;
}
struct Bar {
void* ptr;
}
I tried disabling the invariant but it complained
37 matches
Mail list logo
