On 9/17/10 9:18 CDT, Michel Fortin wrote:
On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu
<[email protected]> 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
