On Tue, 14 Apr 2009 11:34:05 -0400, Frits van Bommel
<fvbom...@remwovexcapss.nl> wrote:
Robert Jacques wrote:
On Tue, 14 Apr 2009 09:27:09 -0400, Frits van Bommel
<fvbom...@remwovexcapss.nl> wrote:
Robert Jacques wrote:
On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel
<fvbom...@remwovexcapss.nl> wrote:
Using D2 structs with a moving GC would need some extra bookkeeping
data anyway, to work out things like their postblit call.
Postblit is only called when generating an actual copy. For example
it is not called on assignment is the source is no longer used. So I
don't see any reason why it should, or it would be expected that
postblit would run when a struct was moved using the GC.
Oh, I didn't know that. (I haven't done much of anything with D2, I
mostly stick to D1)
I just presumed they were like C++ copy constructors.
As an aside: I can certainly think of some places where it would be
useful to have them get called whenever the address changes...
(Though "move constructors" would be even better for most of those
cases)
Could you document this use case? (i.e. give some examples as I can't
think of any)
Any situation in which structs register themselves somewhere for one
reason or another.
For example, I read that C++'s shared_ptr<> could be implemented by
having the instances keep a doubly-linked list of themselves instead of
using an extra heap allocation for the reference count. Such an
implementation would need to update the pointers in neighboring nodes
when moved, or insert itself before or after the original when copied.
Umm... aren't stack values not guaranteed to be stable? (i.e. isn't this
like play Russian roulette with your optimizer?)
Note that shared_ptr<> is not only useful for memory resources, it could
also be used to e.g. keep a file handle or socket open until all users
are done with it (and not longer, as you might get with a GC'ed file
class).
Of course, in this case the more traditional approach with a
heap-allocated reference (or even storing it in the Monitor structure
each object has a pointer to) would be just as viable.
But you could also implement weak references in a similar way, to let
the GC find them in a linked list and allow them to be nulled when
referred-to objects get collected.
Not all moving GCs or copy GCs for that matter, move every single object
all the time, so this hack doesn't work. On the other hand, GC-User cache
interaction would be nice (i.e. telling the GC about user free-lists, etc)
There are probably other use cases...
Well, these are a use cases for a language level move operator, as it
would allow for slightly better performance than a copy and dtor pair in
some cases. (Sorry, I was thinking only about moving GCs when I posted,
for which these aren't use cases)
