Because of the way GetIID/NS_GET_IID works, it's not very easy to get
the compiler to tell you when you're doing it wrong. So far I've come up
with a way to get the linker to do it. I'm trying to get the compiler to
do it, but the results aren't perfect. However along the way I have
noticed some common mistakes regarding IIDs.
The most popular mistake was to include a concrete class in
NS_IMPL_ISUPPORTS; nsSupportsWeakReference was typical.
I noticed a couple of places that queried for a concrete class which
didn't have its own IID, which means that you end up querying for the
base interface instead.
I noticed some code that appeared to be adding IIDs to concrete classes
just so that nsCOMPtr would compile. (In fact the objects in question
should probably have been managed using nsAutoPtr instead of refcounting.)
There were some cases which surprised me weren't already compile or link
errors:
* Defining the IID in a random cpp file instead of the header that
declares it. (Presumably the template that creates the storage for
the IID manages to get instantiated in one cpp file which allows
it to get linked to by the other consumers.)
* nsRDFQuery.h declares the IID for the nsITemplateRDFQuery, but
defines it for nsRDFQuery. (I'm wildly guessing here that the
compiler sees the inherited declaration and somehow defines it?)
* nsIFrame.h manages to use nsIPresShell in several ways using
nothing more than a forward reference. (Except for pointers and
references, I always thought this was a compile error.)
--
Warning: May contain traces of nuts.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
