On Aug 31, 2007, at 16:36, Lawrence Crowl wrote:
The most likely problem will be mangled names. Do the two ABIs use the same mangling scheme? If so, you could have a problem with a function from one ABI stepping on another. You can reduce this problem by forcing bindings to a particular library, which is pretty much automatic on Windows, but requires extra work on Unix systems. You can also, on some systems, restrict the set of symbols. Visible to other libraries.
If symbol versioning is in use, it shouldn't matter. But when it's not... I would assume (from the ignorant point of view of someone doing very little C++ work) that most compiler vendors would be converging on a common name mangling scheme to promote interoperability, which would mean more name conflicts.
Don't use the global operators new and delete.Don't use exceptions. Set the compiler option that turns them off.Don't use RTTI functions.If you use the standard library, make sure you link it statically intoyour library and restrict the resulting symbol scope. (E.g. using map files.) In summary, it can be done but you'll need to manage more symbols than you'd expect.
It's sounding like the remaining benefits wouldn't be worth the hassle... And yet, some people do manage to program in C++. :) Is the usual procedure, then, to just require that the application builder consistently use the same compiler implementation for everything? This would be particularly annoying if the library in question were being provided by the OS vendor, and not always downloaded and built by the application builder.
Or do people just do random applications and not system software in C++? Thanks for the feedback. Ken
