Ken Kozman wrote:

> But all I really want is a nice, concise, compiler independent XPCOM API.
> And a pony.
>
> Ken

Ken,

Okay! Here's your pony ;^) and a possible fix,
although it may be too simplistic.

For your typical XPCOM module,

#include <nspr-stuff>
#include <xpcom-sugar-coatings>
// the first include might actually be buried in the second.

Use the XPCOM C++ wrappers as you normally would. The code should
expand inline and never actually be exported outside the module. The only
external symbols would be coming from NSPR which everyone agrees is
safe from name mangling inconsistencies.

If it's possible to do it this way, it should prevent having to go back and edit

every chunk of XPCOM code that uses any of the C++ wrappers.

Regards,
Rick




Reply via email to