Ruling out arbitrary cost copy construction?

[Andrei Alexandrescu]

On 10/29/10 12:21 CDT, Jonathan M Davis wrote:
> Honestly, what I expect to happen if constant-copy cost is expected is that code
> won't be written that way and the code that expects a constant-copy cost is
> going to be slow. Really, I'd say that in the general case, either arbitrary
> copy construction is going to be expected, and there will be code which assumes
> constant-copy cost and so is slow, or constant-copy cost construction is going
> to be expected and any postplits which don't have a constant-copy cost will are
> going to be inefficient in various places.
>
> I really don't think that you have any hope of enforcing either scheme.

That is correct. I don't want to enforce as much as choosing one stance 
and sticking with it throughout the standard library. The STL is 
consistently making the following stated assumptions:

1. Functors and iterators are cheap to copy
2. General objects (including containers) are arbitrarily expensive to copy

Once STL chose a way, everyone using it could figure out a way to use it 
gainfully, or to debug performance problems if there were any.

> Programmers just won't think about it in the general case. So, unless the
> "mandatory refcounting for value type" (and I have no clue how you'd do that) is
> actually enforced, you can't enforce either, and you _will_ have inefficiencies.
> It's just a question of where and what kind.

Walter and I have been seriously discussing introducing @refcounted 
which would automate part of the process. The problem is you can't 
automate all or even most of it. Either you must assume client code uses 
const consistently, or that client code inserts manual calls whenever 
they plan to change the object.

> If anything, I'm inclined to say that we assume that the postblit is O(1) and
> let the programmer worry about any inefficiencies. We can point out that anything
> worse that O(1) will be a performance problem, but it seems to me that any
> attempt to either accomodate arbitrary cost postblit constructors or to try and
> use any kind of scheme which forces programmers to write postblits in a certain
> way is too complicated and doomed to failure. And even if it works, it will be
> highly annoying to deal with.

It sure is annoying, but it does work.

Don, can you estimate how difficult it would be to convert BigInt to a 
refcounted implementation?


Andrei