Home Original page

generic way to access C++ libs?

Jorgen Grahn jgrahn-nntq at algonet.se
Sat Nov 13 04:23:09 EST 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
> one
>> 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.

/Jörgen

-- 
  // Jorgen Grahn <jgrahn@       Ph'nglui mglw'nafh Cthulhu
\X/                algonet.se>   R'lyeh wgah'nagl fhtagn!
More information about the Python-list mailing list