generic way to access C++ libs?

Diez B. Roggisch deetsNOSPAM at web.de
Fri Nov 5 19:23:20 CET 2004


> let's assume we have a well-populatyed symbol table in the lib
> (which is usually the case, or, at least, not too hard a restriction).

So what? The names are mangled - and each one according to its compilers own
rules. Even if symbols themselves are defined: there is no data type
structure layout for structs and classes themselves stored in the symbol
table.

> that's not quite true.
> actually, each platform (wintel, linux, ...) has a pretty well-defined
> object file format (ELF under unix/linux, for instance).

I did not talk about binary executable formats, but the memory layout of C++
objects. The c++ standard doesn't define where e.g. the vtable of an
objects virtual method resides - or even if virtual methods have to be
implemented by a vtable at first place.

A c++ object created by g++ is total garbage passed to a VC lib that appears
to 

> current icc/linux and gcc/g++ work pretty well together in most cases, and
> icc/windows and cl, too.

No, they don't  - not for C++ code. Google for name mangling and the reasons
why every compiler uses its own scheme. Intel claims that there is binary
compatibility between them compiler and gcc, but thats only true for
certain compiler versions - which usage you have no control of in your
planned scenario.

I suggest you first delve somewhat more on the subject of c++ code
generation and difficulties observed by those trying to develop libraries
for c++ (libs that are shipped to customer/users not for their own projects
of course). Thats one major reason why there are only few c++ libs out
there - the pains e.g. trolltech has to go through to not break binary
compatibility between different versions can be observed here:

http://developer.kde.org/documentation/library/kdeqt/kde3arch/devel-binarycompatibility.html


-- 
Regards,

Diez B. Roggisch



More information about the Python-list mailing list