Building Compatible Libraries

[Peter Olcott]

From what I understand data alignment is not one of the things that has been
standardized. If this is true, then how are libraries constructed such that one
vendor's compiler can directly access aggregate data types such as <struct>
where these types were compiled using another vendor's compiler?

 

[Noah Roberts]

From what I understand data alignment is not one of the things that has been
standardized. If this is true, then how are libraries constructed such that one
vendor's compiler can directly access aggregate data types such as <struct>
where these types were compiled using another vendor's compiler?

The standard says nothing about libraries.

 

[Gianni Mariani]

From what I understand data alignment is not one of the things that has been
standardized. If this is true, then how are libraries constructed such that one
vendor's compiler can directly access aggregate data types such as <struct>
where these types were compiled using another vendor's compiler?

It does not.

This only works if the compiler vendors make their implementations
compatible.

One thing that is guarenteed is the order in which struct members a laid
out, but nothing about padding is guarenteed.

Having said all this, there are alot of implementations that follow the
same methodology as well as supporting things like #pragma pack or other
alignment control mechanisms.

 

[Peter Olcott]

The standard says nothing about libraries.

Well then, how is this accomplished in real world practice?

 

[Noah Roberts]

Well then, how is this accomplished in real world practice?

The target platform usually has some sort of spec for dynamic
libraries. There may be other specs to work from as well. In other
words, it's platform specific and not really guaranteed to work.

see http://mingw.sourceforge.net/mingwfaq.shtml#faq-msvcdll for example.

 

[Ian Collins]

From what I understand data alignment is not one of the things that has been
standardized. If this is true, then how are libraries constructed such that one
vendor's compiler can directly access aggregate data types such as <struct>
where these types were compiled using another vendor's compiler?

Probably the only safe way is to keep types opaque and provide the
public interface as extern "C" functions.

 

[Peter Olcott]

Probably the only safe way is to keep types opaque and provide the
public interface as extern "C" functions.

That is what I was thinking. This eliminates alignment differences and
differences in the derivation of the underlying naming conventions.

 

[Noah Roberts]

That is what I was thinking. This eliminates alignment differences and
differences in the derivation of the underlying naming conventions.

Oh, I think you're looking for specs like Corba or COM.

 

[Peter Olcott]

Oh, I think you're looking for specs like Corba or COM.

For my purposes the prior suggestion will probably be optimal. I always try to
go with the simplest possible solution that completely solves the problem. Since
I am interfacing between C++ and a language following to "C" calling
conventions, the prior answer should work the best, and be entirely sufficient
for my needs.

 

[Noah Roberts]

For my purposes the prior suggestion will probably be optimal. I always try to
go with the simplest possible solution that completely solves the problem. Since
I am interfacing between C++ and a language following to "C" calling
conventions, the prior answer should work the best, and be entirely sufficient
for my needs.

I would at least look at those options and see if they meet your needs.
I've seen a lot of rather poor wheel "innovations".

 

[Peter Olcott]

I would at least look at those options and see if they meet your needs.
I've seen a lot of rather poor wheel "innovations".

I am extensively looking at COM for another purpose. For this purpose I need
none of the baggage of COM.