Standardized name mangling is desirable if and only if it's part of a more general ABI. Defining a multivendor C++ ABI isn't impossible, but it's hard. Name mangling is one of the easy parts.
There is a group working on a C++ ABI for IA64 Unix. If that ABI succeeds for IA64 Unix, it may be adopted (in a modified form, of course) for other platforms too.
That will make it harder, yes. We try not to collide with the user's namespace, which means using macros that begin with __ or the like. Names like that are in the implementation's namespace, which means we have to make sure not to collide with names used by each of the implementations we target. Either we'll have to change the name of that macro, or else Borland will. Shouldn't be tremendously difficult on either side.
I wouldn't hold it against them that you can't use the SGI STL with them. We always have to make at least a few changes (to stl_config.h, if nothing else) when it's ported to a new compiler, and we haven't done any testing or porting with BC++ 5.5. We've tested with 5.0x, but that's quite a different compiler. I suspect that the necessary changes in this case are pretty small.
If anyone has tested with 5.5, and can send us modifications, we'd appreciate the help. The email address for comments and submissions is stl@sgi.com.
Slashdot Mirror
Standardized name mangling is desirable if and
only if it's part of a more general ABI. Defining
a multivendor C++ ABI isn't impossible, but it's
hard. Name mangling is one of the easy parts.
There is a group working on a C++ ABI for IA64
Unix. If that ABI succeeds for IA64 Unix, it
may be adopted (in a modified form, of course) for
other platforms too.
That will make it harder, yes. We try not to
collide with the user's namespace, which means
using macros that begin with __ or the like.
Names like that are in the implementation's
namespace, which means we have to make sure not
to collide with names used by each of the
implementations we target. Either we'll have to
change the name of that macro, or else Borland
will. Shouldn't be tremendously difficult on
either side.
I wouldn't hold it against them that you can't
use the SGI STL with them. We always have to
make at least a few changes (to stl_config.h,
if nothing else) when it's ported to a new
compiler, and we haven't done any testing or
porting with BC++ 5.5. We've tested with 5.0x,
but that's quite a different compiler. I
suspect that the necessary changes in this
case are pretty small.
If anyone has tested with 5.5, and can send
us modifications, we'd appreciate the help.
The email address for comments and submissions
is stl@sgi.com.