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
