On 8/31/07, Ken Raeburn <raeburn@xxxxxxxxxxx> wrote: > 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. Several compilers have adopted the GNU mangling, but mostly because that is the system mangling for Linux. Other vendors, for compatibility reasons, still use other manglings. > > > 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 into > > your 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++. :) Yes, and I applied the principles in building a demangling library that has no dependence on the C++ runtime system. > Is the usual procedure, then, to just require that the application > builder consistently use the same compiler implementation for > everything? Yes, though this is not as onerous as you might think. > 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. On systems with strong binary compatibility guarantees, shipping binaries with an agreed upon base compiler is not terribly difficult. Generally, there is one compiler associated with the OS that serves as the reference compiler, and all others must conform. On Windows, that compiler is Microsoft's. On Solaris, that compiler is Sun's. On HPUX, that compiler is HP's. On Linux, the binary story is not as strong, but the compiler is GNU's. > Or do people just do random applications and not system > software in C++? People do system software in C++, it just takes more care. It also presupposes an ABI that is larger than the normal system ABI (e.g. SysV). Hence, the desire to avoid dependence on any C++ run-time library. -- Lawrence Crowl
