View mode: basic / threaded / horizontal-split · Log in · Help
April 17, 2012
Re: Aquivalent References as in C++?
> For that, you have static if contitions, and indeed you can 
> make it a compile-time error.

Can you show me this as code? And are there any plans to realize 
non-null references or strategies to avoid such things? Otherwise 
there would really be something important missing in D.
April 17, 2012
Re: Aquivalent References as in C++?
> Yes, you must because whetheer obj is null is only known at 
> runtime.

Yes, but if i forget the assert i get an Access Violation error 
with no more informations. Problem is nobody knows _why_ he gets 
this error, because the error message gives no information.
So it must be a better solution then to write in every method 
"assert(obj_param !is null");". Best of all solutions would be 
that a special keyword, for example  scope, ensure that lvalues 
would except but _no_ null-references.
April 17, 2012
Re: Aquivalent References as in C++?
On 04/17/2012 10:37 AM, Namespace wrote:
>> Yes, you must because whetheer obj is null is only known at runtime.
>
> Yes, but if i forget the assert i get an Access Violation error with no
> more informations. Problem is nobody knows _why_ he gets this error,
> because the error message gives no information.

In order to get a meaningful error, the compiler would have to inject 
code that checked every access through a class reference. Unfortunately 
that would bring too much overhead and not be acceptable in a system 
language.

But it could be a part of the non-release builds. I don't have any idea 
how slow program would become if every class dereferencing would be 
checked against null like that. (?)

> So it must be a better solution then to write in every method
> "assert(obj_param !is null");".

Not in every method, but only in methods that actually dereference that 
pointer. Intermediate functions that simply pass the parameter to 
another function need not check the condition.

In the end, null references are a part of D. The code must be written in 
a way to accept it.

As an aside, enforce() may be more suitable and a little shorter:

  enforce(obj_param, "Even with a message");

Whether to use assert() or enforce() depends on the function.

> Best of all solutions would be that a
> special keyword, for example scope, ensure that lvalues would except but
> _no_ null-references.

Yes, the keyword would be a little shorter than the assert() or 
enforce() above but D already has very many keywords. :)

Finally, actually it is possible to have bugs of the same sort even with 
references in C++:

// C++ code

struct S
{
    int i;

    S(int param_i)
        :
        i(param_i)
    {}
};

S * make_S(int i)
{
    return (i == 42) ? new S(i) : 0;
}

void use_S(const S & s)
{
    int i = s.i;
}

int main()
{
    use_S(*make_S(100));
}

The output is the same as in D:

Segmentation fault

So, as you see, neither C++ provide any help here.

C++'s references have these meanings:

* On the parameter list: "I would like to have a real object please." As 
seen above, it is so easy to violate that. The caller of use_S() 
realizes that a reference is needed and just dereferences the pointer at 
hand. See, the caller must ensure even in C++ that the pointer that is 
available is not NULL.

* On the return type: "What I give you is an alias to an existing 
object." Even this is a false promise without tool support, because the 
reference may be of an automatic local object.

Ali
April 17, 2012
Re: Aquivalent References as in C++?
> > Best of all solutions would be that a
> > special keyword, for example scope, ensure that lvalues would
> except but
> > _no_ null-references.
>
> Yes, the keyword would be a little shorter than the assert() or 
> enforce() above but D already has very many keywords. :)

Yes, but scope is an unused storage keyword, isn't it?
So it could be an idea to avoid speed losses with the current 
method and ensure that the object is not null, if it's 
intentional.
April 17, 2012
Re: Aquivalent References as in C++?
On 04/17/2012 08:10 PM, Namespace wrote:
>> > Best of all solutions would be that a
>> > special keyword, for example scope, ensure that lvalues would
>> except but
>> > _no_ null-references.
>>
>> Yes, the keyword would be a little shorter than the assert() or
>> enforce() above but D already has very many keywords. :)
>
> Yes, but scope is an unused storage keyword, isn't it?

It is used.

> So it could be an idea to avoid speed losses with the current method and
> ensure that the object is not null, if it's intentional.

Define 'ensure'.
April 17, 2012
Re: Aquivalent References as in C++?
> Define 'ensure'.

Guarantee, that the given object parameter isn't a null reference.
April 17, 2012
Re: Aquivalent References as in C++?
On 04/17/2012 08:40 PM, Namespace wrote:
>> Define 'ensure'.
>
> Guarantee, that the given object parameter isn't a null reference.

But C++ does not do that either.
Are you asking for a full-blown non-null type system?
April 17, 2012
Re: Aquivalent References as in C++?
> But C++ does not do that either.
> Are you asking for a full-blown non-null type system?

Yes, but of course only with a special Keyword/Storage class.
April 17, 2012
Re: Aquivalent References as in C++?
On 04/17/2012 09:16 PM, Namespace wrote:
>> But C++ does not do that either.
>> Are you asking for a full-blown non-null type system?
>
> Yes, but of course only with a special Keyword/Storage class.

If it is not the default, how would you enforce it at the caller side?
April 17, 2012
Re: Aquivalent References as in C++?
On Tuesday, 17 April 2012 at 19:56:11 UTC, Timon Gehr wrote:
> On 04/17/2012 09:16 PM, Namespace wrote:
>>> But C++ does not do that either.
>>> Are you asking for a full-blown non-null type system?
>>
>> Yes, but of course only with a special Keyword/Storage class.
>
> If it is not the default, how would you enforce it at the 
> caller side?

By the compiler who throws an error message or a warning.
A warning or a better error message would help also, if a 
null-reference was in use.
But only the message "Access violation" without any information 
isn't enough, imo.

It seems that not-null references wouldn't be a part of D in near 
future.
1 2 3
Top | Discussion index | About this forum | D home