> Hello
> > I found another instance of this. nsMemory. It is defined as:
> > class nsMemory
> > {
> > public:
> > static NS_EXPORT void* Alloc(size_t size);
> > static NS_EXPORT nsIMemory* GetGlobalMemoryService(); //
AddRefs
> > };
> >
> > What would be nice would be, again, a C function wrapper around these
guys
> > so that they can be linked to in a compiler independant fashion.
> There are plenty of then - nsString, nsVoidArray, nsVoidBTree etc...
> What you propose is to declare *everything* as an interface and create a C
API
> function to create some of them - sort of hardcoded class factory. But I
think
> nsIString is not what we have in mind :) So using mozilla with different
> compiler is a pure theory...
Sorry, again I wasn't being too clear... The only bad thing about THIS class
(which is sort of like a namespace, since everything is static and there are
NO data members) is that it is in a class. Therefore the DLL will export the
methods by the compiler dependent name mangled fashion. This is just the
nature of the beast (I think.)
But, if we added the following:
// Some definition...
extern "C" {
NS_EXPORT void * NS_Alloc( size_t size );
NS_EXPORT nsIMemory* NS_GetGlobalMemoryService( );
// Other functions removed for brevities sake.
}
// and then some implementation...
extern "C" {
NS_EXPORT void * NS_Alloc( size_t size )
{
return( nsMemory::Alloc( size ) );
}
// Other functions removed for brevity...
}
I'm not saying we need interfaces in the XPCOM sense, we just need a C API
to these methods so they are compiler independant.
The C API version of the component manager could just be:
extern "C"
{
NS_EXPORT nsIComponentManager * NS_GetComponentManager( )
{
return( nsComponentManagerImpl::gComponentManager );
}
}
and that's it. All we want is to be able to access these global items but
not through an exported class, but through an exported function. Exported
classes are not (by nature) compiler independant. This is one reason why the
COM API (all the CoXXX functions and what not) are a C API.
I hope I made some more sense this time :)
Ken
