QtD is suspended

[Andrei Alexandrescu]

On 9/17/10 9:18 CDT, Michel Fortin wrote:
> On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> On a funny note, we figured that for a number of reasons it would help
>> to allow C++-style constructors that offer access to the source; it
>> just turns out some idioms need to modify the source as well as the
>> destination.
>>
>> One obvious example is the built-in hashtable that is not shared
>> properly when it's null. Making the copy constructor spring the
>> hashtable to life would make it more uniform in behavior.
>
> At the basic level I feel uneasy with this whole idea of modifying the
> source while copying. It means that you can't copy the source if it is
> const. Do you really want to make const containers uncopyable?

Again, the scenario is motivated by this:

void main()
{
     int[int] hash;
     fun(hash);
     assert(!(42 in hash));
     hash[0] = 10;
     fun(hash);
     assert(42 in hash);
}

void fun(int[int] hash)
{
     hash[42] = 42;
}

Walter's idea was as follows. If the hash's copy constructor has access 
to the source, then that constructor could lazily initialize the pointer 
internally shared by the existing instance (the one in main()) and the 
one being created (the one passed to fun()). Then, the program would 
behave more predictably and also stay efficient - lazy initialization 
for the win.

Note that const objects don't have this problem.

Also note that the non-null reference matter is related to this one.


Andrei