More about why SObjs: isn't a great idea

[Piru]

You didn't even run into the fun scenario: Two incompatible SObjs with the exact same name, but different ABI (this has happened at least once already). There hasn't been proper documentation about SObj creation and this has lead into all sort of trouble.

They're worse than amiga shared libraries anyway: SObjs aren't even shared, each opener gets their own copy in memory.

As far as I can tell the only reason they exist is that apparently OS4 coders are incapable of creating amiga shared libraries with per caller library base (and the static data in the library base possize). Or they're just too lazy to do it properly, and decided to take the shortcut by introducing the non-shared libraries.

A grave mistake if you ask me.

[Piru]

Yeah, it was a pain back when most people were migrating from gcc 2.95, the ABI changed a great deal. However, one of the reasons it changed so much was to avoid having to do it again for a long, long time. Don't expect to see changes of that magnitude any time soon. Unless C++0x throws a big spanner in the works. Not impossible...

Well actually what I was trying to say that there were two different libraries with different parameters, but the same name. Clearly this didn't end up well.

Sure, on AmigaOS, but not for OS that support .so files generally.

Obvously I was only talking about the shoddy SObjs implementation of AmigaOS here.

The only reason? I think that's being deliberately short sighted. My guess would be that one really obvious reason would the fact that traditional amigaos shared libraries offer no way to provide the required linker constructs for C++ and other languages that some people, myself included, like to use. The world is not tied to procedural programming.

C++ must die anyway