C++ standard library ABI

[Christophe de Dinechin]

My suggestion was actually to separate the 'ABI' from the 'API'.  
That is: try to agree on the support library (all the functions  
beginning with __, typically), but not necessarily on the standard  
library, iostream, and so on. So you could reuse the support library,  
but you would need, say, the "RogueWave" library if you want to run  
code that included it, and the "Sun" library if you want to run code  
that included it.

For various reasons, EH format needs not be identical between  
compilers, but a few other things in EH processing need to if we want  
to pass exceptions around. We can discuss that also.

Regards
Christophe.

> Christophe suggested that the way around the C++ standard library ABI 
> problem is to move the C++ runtime support library (which includes the 
> standard library, as well as compiled code support routines) along with 
> the binaries for the application, when moving from one system to  
another.
>
> This would mean that multiple C++ RTS libraries might be present on a 
> system at once (I guess you could refer to them as one "native" and  
> zero or more "foreign" libraries).
>
> I think that if we have the C++ RTS travel with the C++ generated  
code,
> this might allow us to duck a lot of complicated areas - for  
instance there's
> no need to specify in the ABI exactly what EH tables look like.   
The same
> for some other things like array new/delete, ctor/dtor  
registration, etc.
> Interfaces between compiled code and the RTS in general don't have  
to be
> specified, but rather just compiled code -> compiled code interfaces  
> (the basic object model stuff) and some RTS -> RTS interfaces  
(e.g. memory
> management from multiple systems has to coexist together) and some 
> RTS -> OS interfaces (e.g. iostreams has to work on top of libc, rather 
> than depending on anything within it).
>
> I think you could see this as a quasi-OO setup:  generated code  
has "objects"
> which carry with them "methods" in the RTS.  Some objects would be  
fully
> specified in the ABI, while the rest can be overridden in any  
particular
> implementation.
>
> Jonathan Schilling		SCO, Inc.		jls at sco.com
>
>