C++ shared libs?

[andst]

Hey,

As you may know I'm working on wxWidgets for Amiga.  It's a C++ lib and can get pretty big, so making it shared is clearly desirable.  OS 4 shared objects should be straightforward enough, but I'm wondering about normal resident libraries:

Has anyone done a resident C++ library before?

I'd be interested in experiences and sample code if possible.  Both for ppc and m68k.

Are people using C++ on Amiga to any extent btw?  Or is it still mainly C and other languages?

//A.

[andst]

@billt

Ok Bill, that's a good suggestion.  Will do.

@SamuraiCrow

Ok thx, in theory I'm thinking it *should* work, but I'll allocate some thinking time to figure it out.

[andst]

Couldn't Andst use the Amiga's native OOP system, of BOOPSI or is that just too crude for this task... I must confess to not really reading what he is trying to do

Hey, a good discussion going on here!  And this is a fair question.

The wxWidgets toolkit can be described as a C++ wrapper for native API's.  So you'd write code using wxWidgets classes, and the resulting program would use Win32 on Windows, GTK on Linux, Cocoa on OSX, and on Amiga it would indeed be BOOPSI/Reaction.

What I've found is that it speeds up GUI generation a lot, and makes multi platform support a no-brainer.  And then use something like DialogBlocks, and it's as quick and powerful as anything out there on any platform.

[andst]

See my longer reply to Karlos re: the issues with making it a normal resident lib.

Re: shared objects: Be aware that C++ shared objects are *not* trivial. The name mangling is compiler specific, and other features also have lots of implementation dependency issues. You can avoid most of the problems if you can mandate a specific compiler, but C++ is really not well suited for this.

This may or may not be a big deal to you, but figured I'd make sure you're aware.

Thanks.  I expect this would be more or less the same as on other platform though (Unix) and not specific to Amiga shared objects.  wxWidgets already builds with shared objects on Linux, so the support is already there.

The libraries do end up being compiler specific on other platforms too though.  This is mostly a generic C++ issue as I understand it, and nothing I'll try to change in this project.  On Amiga it might be less of an issue as I understand G++ would be by far the most widely used C++ compiler atm.

As far as templates, I haven't looked in detail at what symbols g++ exports, but I expect if would be more or less the same as if the class were expanded, just like you describe.

[andst]

The gotcha's in general is generally exceptions, multiple inheritance, and assuming too much about memory (if MyClass has a virtual member function anywhere in its ancestry, it is likely to have a vtable pointer at a negative offset from the address you actually get returned from new, but if I remember correctly the exact layout is compiler dependent, so it's necessary to arrange for the user to free the memory with "delete" via a wrapper rather than try to free the memory themselves).

Vtables end up as regular symbols as far as I can tell.  Compiler dependent yes, but in theory should be fine.  Not sure if they could be shared between processes, but libs with some separate data per process is fully possible if I remember correctly.  I'm not sure I quite follow you w.r.t memory, do you mean correct C++ code might fail, or that broken user code would fail?

Multiple inheritance and exceptions aren't heavily used in wxWidgets so it might not be a huge issue.  I think exceptions can even be turned off without sacrificing too much functionality, in case they become a major bother.

[andst]

I don't want to rain on anybody's parade, but if C++ classes are being exposed via AmigaOS shared libraries then I fully expect it to work for trivial concrete classes only. Either that, or you write your library functions based on some C structure that then becomes embedded as a delagate within a C++ class wrapper in which a bunch of inline method calls trampoline into your LVO.

I really can't see proper C++ shared code working that way. Not when you factor in things like inheritence, polymorphism and templating. Especially templating...

Ok, well it definitely needs to work for abstract classes as well if it's going to work with wxWidgets.  There's not too much multiple inheritance, but plenty of inheritance, polymorphism and templating obviously.  wxWidgets doesn't use all the more recent complex features of C++, but these basic building blocks are used quite frequently.

The SAS/C example is evidence that at least *some* incarnation of a C++ shared library is possible on Amiga.  SAS/C won't be able to compile wxWidgets, but I'm perfectly open to modifying gcc/g++ if needed.  I'm also thinking that C++ shared libraries works with DLL's on Windows.  Without knowing in detail exactly how it's done for DLL's, in my experience regular DLL's have mostly similar functionality to Amiga resident libraries.  Or is there any critical feature of DLL's that is missing from Amiga resident libraries?

Thanks all for responding.  Keep it going!

[andst]

I'm not sure that you can derive from a C++ class in Windows DLL's either, that is what COM is for. COM standardises on what the vtable's look like and how to cast from one object type to another. I would guess that the AOS4 libraries are similar to COM.
 
There is no reason at all why it can't be done on AOS3, but you'll need to add compiler support & then you will be limited to that one compiler (but I guess you have that problem on AOS4 too). I don't know how SAS/C does it and whether it's worth copying their method or not.

Ok, well perhaps better to be limited to one compiler than no compiler at all.  But I guess it's also becoming clear to me that there is limited previous work in the area.  At least now I know a bit more about which areas need some thinking.

[andst]

Broken user code would fail. The only issue there is that for every function wrapping a "new" operator there needs to be an equivalent one calling "delete" and users of the library needs to know they *must* use those to free the objects rather than, say, calling FreeMem().

But this is the same as in any C++. I mentioned it mainly in the context of the possible scenario with wrapping the C++ API in a C layer which could make it less obvious to a user. If you hand a user the actual C++ objects and have them use it from code compiled with the same compiler, then having to call delete presumably wouldn't surprise anyone.

Okay.  There probably little need for FreeMem() in any wxWidgets user code, and in my experience it's even unusual to use the delete operator much, as object removal is pretty much always automatic.  It's different for library code obviously, but I guess there it's easier to influence code content  ;-)