View mode: basic / threaded / horizontal-split · Log in · Help
May 30, 2010
Re: Copy constructors for lazy initialization
On Fri, 28 May 2010 20:26:50 -0500, Andrei Alexandrescu wrote:

> Walter has had a great idea last night: allow classes to define
> 
> this(ref S src);
> 
> where S is the name of the struct being defined, as an alternative for
> 
> this(this);
> 
> The result would be a function similar with a C++ copy constructor.
> 
> Such an abstraction allows us to perform lazy initialization in a way
> that allows the kind of problems associated with non-shared hash tables:
> 
> void foo(int[int] x)
> {
>     x[5] = 5;
> }
> 
> void main()
> {
>     int[int] x;
>     foo(x);
>     assert(x[5] == 5); // fails
> }
> 
> If you change the first line of main() with
> 
> int[int] x = [ 42:42 ];
> 
> the assert passes.
> 
> The idea of the copy constructor is to lazy initialize the source and
> the target if the source has null state. That would take care of this
> problem and the similar problems for shared state.
> 
> There is still a possibility to call a method against an object with
> null state. I think that's acceptable, particularly because lazy
> initialization saves some state allocation.
> 
> What do you think?
> 
> 
> Andrei

Nothing wrong with yet another widely available constructor tool if the 
user optionally wants to have it available and use it that way, and its 
usage is well defined.

Good if no cost if the programmer does not use the facility.

What seems to be missing, in this example of the unintentional creation 
of 2 AAs because initially a null AA is passed, if there was a way of 
explicitly initialising the AA first without having to insert something 
into it.   That subject seems to be taboo.  Of course, an empty but setup 
AA can be kludged by adding an arbitrary value and then removing it, and 
as such begs the need for a setup property / function.

\\
May 30, 2010
Re: Copy constructors for lazy initialization
On Fri, 28 May 2010 20:26:50 -0500, Andrei Alexandrescu wrote:

> Walter has had a great idea last night: allow classes to define
> 
> this(ref S src);
> 
> where S is the name of the struct being defined, as an alternative for
> 
> this(this);
> 
> The result would be a function similar with a C++ copy constructor.
> 
> S.
> 
> What do you think?
> 
> 
> Andrei


Thats great.
Yet another way to initialize an AA, without having to insert and then 
remove a value.  I just have to make a dummy function and pass the AA to 
it.

Maybe a setup property / function would be easier.
June 03, 2010
Re: Copy constructors for lazy initialization
On 29/05/2010 03:02, Jonathan M Davis wrote:
> Andrei Alexandrescu wrote:
>
> Not knowing what other implications there are, I'm fine with the change, but
> the fact that D creates the array when you try and insert into it (or append
> to it in the case of normal arrays IIRC) rather than blowing up on null
> seems like a source of subtle bugs and that perhaps it's not the best design
> choice. But maybe there was a good reason for that that I'm not aware of, so
> it could be that it really should stay as-is. It's just that it seems
> danger-prone and that the situation that you're trying to fix wouldn't be an
> issue if the array stayed null until the programmer made it otherwise.
>
> - Jonathan M Davis

Yeah, I agree. I mean, for me the problem here is that the 
map/associative-array is not really a value type, nor a reference type, 
but something in between. I think it might be better for it to be just a 
proper reference type.

I'm not saying that Andrei suggestion has no merit though. Rather, I 
have to admit I am not familiar with these C++ idioms and techniques. 
Can someone explain me why we need a copy constructor in the first 
place, instead of just using a reference object, aka a class, and an 
optional clone method?



-- 
Bruno Medeiros - Software Engineer
June 03, 2010
Re: Copy constructors for lazy initialization
On 06/03/2010 06:30 AM, Bruno Medeiros wrote:
> On 29/05/2010 03:02, Jonathan M Davis wrote:
>> Andrei Alexandrescu wrote:
>>
>> Not knowing what other implications there are, I'm fine with the
>> change, but
>> the fact that D creates the array when you try and insert into it (or
>> append
>> to it in the case of normal arrays IIRC) rather than blowing up on null
>> seems like a source of subtle bugs and that perhaps it's not the best
>> design
>> choice. But maybe there was a good reason for that that I'm not aware
>> of, so
>> it could be that it really should stay as-is. It's just that it seems
>> danger-prone and that the situation that you're trying to fix wouldn't
>> be an
>> issue if the array stayed null until the programmer made it otherwise.
>>
>> - Jonathan M Davis
>
> Yeah, I agree. I mean, for me the problem here is that the
> map/associative-array is not really a value type, nor a reference type,
> but something in between. I think it might be better for it to be just a
> proper reference type.

An associative array is a reference type. The problem discussed above 
applies to all reference types.

> I'm not saying that Andrei suggestion has no merit though. Rather, I
> have to admit I am not familiar with these C++ idioms and techniques.
> Can someone explain me why we need a copy constructor in the first
> place, instead of just using a reference object, aka a class, and an
> optional clone method?

The problem is that null objects don't obey reference semantics. The 
example discussed in this group is:

void fun(int[int] a) { a[5] = 10; }

void main(string[] args) {
    int[int] x;
    if (args.length & 1) x[0] = 42;
    fun(x);
    assert(x[5] == 10);
}

The program will fail or not depending on the number of arguments passed.


Andrei
June 03, 2010
Re: Copy constructors for lazy initialization
On 03/06/2010 14:48, Andrei Alexandrescu wrote:
> On 06/03/2010 06:30 AM, Bruno Medeiros wrote:
>> On 29/05/2010 03:02, Jonathan M Davis wrote:
>>> Andrei Alexandrescu wrote:
>>>
>>> Not knowing what other implications there are, I'm fine with the
>>> change, but
>>> the fact that D creates the array when you try and insert into it (or
>>> append
>>> to it in the case of normal arrays IIRC) rather than blowing up on null
>>> seems like a source of subtle bugs and that perhaps it's not the best
>>> design
>>> choice. But maybe there was a good reason for that that I'm not aware
>>> of, so
>>> it could be that it really should stay as-is. It's just that it seems
>>> danger-prone and that the situation that you're trying to fix wouldn't
>>> be an
>>> issue if the array stayed null until the programmer made it otherwise.
>>>
>>> - Jonathan M Davis
>>
>> Yeah, I agree. I mean, for me the problem here is that the
>> map/associative-array is not really a value type, nor a reference type,
>> but something in between. I think it might be better for it to be just a
>> proper reference type.
>
> An associative array is a reference type. The problem discussed above
> applies to all reference types.
>
>> I'm not saying that Andrei suggestion has no merit though. Rather, I
>> have to admit I am not familiar with these C++ idioms and techniques.
>> Can someone explain me why we need a copy constructor in the first
>> place, instead of just using a reference object, aka a class, and an
>> optional clone method?
>
> The problem is that null objects don't obey reference semantics. The
> example discussed in this group is:
>
> void fun(int[int] a) { a[5] = 10; }
>
> void main(string[] args) {
> int[int] x;
> if (args.length & 1) x[0] = 42;
> fun(x);
> assert(x[5] == 10);
> }
>
> The program will fail or not depending on the number of arguments passed.
>
>
> Andrei

In my notion of reference type (which you may argue is not the correct 
one, but that's a different issue) a null object cannot be used at all 
(other than checking its identity against other objects). Thus that 
program would always fail, either on 'a[5] = 10;' or 'x[0] = 42;', 
according to these semantics


-- 
Bruno Medeiros - Software Engineer
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home