Faster Virtual Method Dispatch

[Walter Bright]

Mike Capp wrote:
> In article <e2k12i$19bi$1 at digitaldaemon.com>, Walter Bright says...
>> 1) for every allocation, shared_ptr<> allocates an *extra* block of 
>> memory to hold its accounting information. So you've got, out of the 
>> box, twice as many allocations/deallocations happening.
> Not true for intrusive refcounting. (This isn't always feasible if you're
> dealing with third-party classes, which is why shared_ptr isn't intrusive, but
> if you _can_ use it it's very close to ideal.)

True, but shared_ptr<> is billed as the C++ answer to gc, and 
shared_ptr<> is not intrusive.

>> 2) for every copy of the shared_ptr<>, like passing one to a function, 
>> returning one, etc., the reference count has to be incremented, then 
>> decremented.
> Again, not true for intrusive refcounting. You can assign an intrusive
> smartpointer from a raw pointer or reference, so most of the time you can use
> those to pass/return. Refcount twiddling is only needed when changing an
> "owning" pointer, plus the rare "safety" case where you have a raw pointer but
> are calling code which might drop the last "real" owning ref. 

But that means just going back to the old way of being very, very 
careful about who "owns" the pointer and who doesn't. Refcounting is 
supposed to eliminate that nuisance.


>> And even with all that falderol, shared_ptr<> still can't do slicing, 
>> which are an important efficiency improvement.
> Agreed, but couldn't you do something very similar with a simple ptr class
> containing a pointer to the (refcounted) base string plus a couple of range end
> indices? That's worked well for me in the past, but there may be benefits of D
> slices that I'm missing.

Sure you could do that, but then slices and shared_ptr's are not 
interchangeable. In D, you can build a data structure that contains 
slices, references to the heap, and references to static data 
willy-nilly. In C++, because each of those would be a different type, 
you'd have to build a wall between each.

I think that's one of the key benefits of D slicing - the user of the 
slice need not know or care that its a slice. I don't have to have two 
versions of toupper(), one for shared_ptr and one for slices.


>> Another advantage of gc (that isn't implemented, but could be,
>> in D's gc) is that allocated memory can be compacted.
> Has there ever been a language that successfully combined compacting GC with raw
> pointers? How would this work? And it's going to be tough to drop raw pointers
> without breaking ease-of-use for C libraries.

Oh, it's quite doable <g>.