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
- Request for Compiler Independent Extern "C" APIs... Ken Kozman
- Re: Request for Compiler Independent Extern "C&q... Rick Parrish
- Re: Request for Compiler Independent Extern "C&q... Valeri Todorov
- Re: Request for Compiler Independent Extern "C&q... Ken Kozman
- Re: Request for Compiler Independent Extern "... Rick Parrish
- Re: Request for Compiler Independent Extern "C&q... Pierre Phaneuf
- Re: Request for Compiler Independent Extern "C&q... Ari Heitner
- Re: Request for Compiler Independent Extern "C&q... Brendan Eich
- Re: Request for Compiler Independent Extern "C&q... Ari Heitner
- Re: Request for Compiler Independent Extern "C&q... Pierre Phaneuf
- Re: Request for Compiler Independent Extern "C&q... Braden McDaniel
- Re: Request for Compiler Independent Extern "C&q... Ari Heitner
- Re: Request for Compiler Independent Extern "... Pierre Phaneuf
- Re: Request for Compiler Independent Extern "C&q... Braden McDaniel
