dsimcha wrote:
== Quote from Don ([email protected])'s article
Andrei Alexandrescu wrote:
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?
At the moment, I think it's impossible.
Has anyone succesfully implemented refcounting in D? As long as bug 3516
(Destructor not called on temporaries) remains open, it doesn't seem to
be possible.
Is that the only blocker, or are there others?
Can someone please clarify something for me? I thought BigInt was already COW
(though I guess COW w/o ref counting is still pretty inefficient).
Yes, it's COW, but without refcounting. Which isn't really too terrible,
because very few BigInt operations can be performed in-place. Even ++x
can trigger a memory allocation.
The most important issues would be fixed with a small-value optimisation
(values x where -long.max <= x <= long.max stored in the struct).
