179278 - NSCAP_FEATURE_DEBUG_PTR_TYPES not worth the cost?

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Scott Collins]

A greatly annoying problem of |nsCOMPtr| is that compiling it with this switch
turned off and on produce two distinctly different libraries which are not link
compatible.  In the optimized case, |nsCOMPtr| has a base class |nsCOMPtr_base|
which factors storage and dtor and some other basic machinery.  Because storage
is factored, it doesn't have the specific type actually reflected in the
template.  I first added this machinery because our debuggers had trouble
investigating through this |nsISupports*| to the concrete type to which it
pointed.  With this debug machinery enabled, nothing is factored, so the storage
is exactly the type requested by the template, and some debuggers got happier. 
Unfortunately, people ended up building some parts of the world with this
switched one way, and some parts switched the other way; and ended up not being
able to link.  We hit this time and time again, and continually have to explain
to the next generation.

It turns out, if I recall correctly, this hack doesn't even end up helping on
Mac (at least under CodeWarrior).  Has VC++ evolved past the need for this? 
Where does GCC stand?  Can we get rid of this machinery?

Comment 1

[Scott Collins]

This bug suggests one way to solve this problem, bug #53646 suggests another.