Faster Virtual Method Dispatch

[Mike Capp]

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.)

>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. 

>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.

[And in a subsequent posting]

> 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.

cheers
Mike