On Thursday, 4 October 2012 at 17:55:45 UTC, Jonathan M Davis
wrote:
On Thursday, October 04, 2012 13:14:00 Alex Burton, @gmail.com
wrote:
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright
wrote:
> On 9/15/2012 5:39 AM, Henning Pohl wrote:
>> The way D is dealing with classes reminds me of pointers
>> because you can null
>> them. C++'s references cannot (of course you can do some
>> nasty
>> casting).
>
> Doing null references in C++ is simple:
>
> int *p = NULL;
> int& r = *p;
>
> r = 3; // crash
IMHO int * p = NULL is a violation of the type system and
should
not compile.
NULL can in no way be considered a pointer to an int.
Um. What? It's perfectly legal for pointers to be null. The
fact that *p
doesn't blow up is a bit annoying, but it makes sense from an
implementation
standpoint and doesn't really cost you anything other than a
bit of locality
between the bug and the crash.
I realise what is currently the case I am making an argument as
to why I this should be changed (at least for class references in
D).
In the same way this should fail:
Class A
{
}
A a;
And why would this fail? It's also perfectly legal.
I realise that this is currently legal, I am proposing that it
shouldn't be.
If I call a method on reference a (perhaps after it has been
passed around to a different part of the code) I get an acess
violation / segfault whatever - Undefined behaviour.
On windows you might get stack unwinding, but otherwise not.
Failing with a memory violation is a bad thing - much worse than
failing with an exception.
If I press a button in an app and it has a memory violation I can
loose all my work, and potentially leave parts of a system in
undefined states , locks on things etc.
If I get an exception, and the code is exception safe, the gui
can indicate that the button doesn't work right now - maybe
saying why, and the user can continue without loosing all their
stuff (hopefully not pressing the same button and finding the
same bug).
Alex
