n = InterlockedCompareExchange(&m_strongcount, cmp + 1, cmp);

A little bit of a mix of C pseudo objects and Java in there.  I'm suprised I didn't
manage to throw in a perlism.

I've been trying to come up with an all interlocked increment/decrement solution since
you might get better performance on some platforms with native interlocked increment/decrement
 and this is, I gather, performance sensitive code.  Here is an almost all interlocked increment/decrement
solution.

  void shared_count::add_strong() {
     if (InterlockedIncrement(&m_strongcount) < 0) {
       InterlockedDecrement(&m_strongcount);   // good idea. LONG_MIN isn't  negative infinity
       throw some exception;
     }
     add_ref();
  }

  void shared_count::release_strong() {
    if (InterlockedDecrement(&m_strongcount) == 0)
         // attempt to set strongcount to LONG_MIN.  If attempt fails, some other
         // thread has incremented strongcount so object is still alive or already disposed of.
         if (InterlockedCompareExchange(&m_strongcount, LONG_MIN, 0) == 0)  v_dispose();
    release_ref();
  }

Some comments.  The exception throwing path I think is not performance critical since the
action on getting the exception should be to set the weakptr to something else or null.  So
the exception path shouldn't get used a lot.

If you have native interlocked increment/decrement, then this code is totally loop free.
Not that small compare and swap loops aren't usually a problem, but still it's nice.
Of course the typical heap manager still uses locks so we can't claim total lock-free
here.

Also, you might consider packing both refcount and strongcount into the same word and
manipulating both with a single interlocked operation to reduce the use of interlocked
instructions to a minimum.  For 32 bit words this would constrain your max refcounts to
64000 or so.  Maybe it would give you an excuse to implement a refcount overflow exception.  :)

Final comment to Alexander.  This is why I don't think you can come up something like
pthread_refcount_t.  There are too many ways to implement things here.  I'd think you'd be
better off trying to implement a more generic interlocked api with performance hints so
the various applications could customize optimal solutions for various platforms.

Joe Seigh