generic way to access C++ libs?
jgrahn-nntq at algonet.se
Sat Nov 13 10:23:09 CET 2004
On Thu, 11 Nov 2004 12:07:57 GMT, Neil Hodgson <nhodgson at bigpond.net.au> wrote:
> Neil Hodgson:
> # Much of the time C++ code only has to be compatible with the other
> # modules it is delivered with.
> Jorgen Grahn:
>> But most of the time it has to be compatible with the standard library.
>> Even if these flags exist, I think it's very rare to encounter more than
>> layout, for one specific compiler/compiler version/architecture.
> The most commonly changed layout option is structure packing. Many C/C++
> projects decide upon a particular packing option often just to be compatible
> with files from the initial version or other applications and libraries.
> [...] C system libraries like standard I/O and platform
> libraries like Win32 use explicit compiler instructions to ensure they can
> deal with client option choice. The Win32 headers use #pragma pack(n) to
> ensure that client code will compile assuming particular packing of system
> structures no matter how the client code is packing its own structures.
I see. Then this seems to me to be a Windows culture issue which I've missed
because I'm a Unix person. The GNU and Solaris libcs (and all other Unix
shared libraries that I'm aware of) do not do this. Same thing with
AmigaDOS, as I recall it. Access these from code compiled with non-standard
packing and you're toast.
(Some Unix include files (things in /usr/include/netinet/, for example) have
structs with elaborate padding so that they can match e.g. an IP header
perfectly. This places a restriction on compiler writers, of course.)
That also explains to me why so many embedded projects I've been in have
messed with structure packing - the architects were Windows people.
One reason this is rare in the non-Windows world is (I suppose) that there's
often a huge run-time penalty for accessing misaligned words on non-x86
processors. The default layout is almost always the best possible, unless
you are low on memory.
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!
More information about the Python-list