Sign in to follow this  
rldivide

headers and static lib: unwanted memory shift ?

Recommended Posts

Hello, When I compile my static lib I use a full header (with everything needed). Then, I made a lite header (without private members and unwanted functions, not needed for the use of the static lib in another project). But I feel like it's causing some trouble: memory seems to shift on some values. Some variables are fine, others have completely weird values (which doesn't happen when using the full header). How can I solve this without having to include the full headers (which contain functionnalities I don't want to distribute, and implies lot of other dependencies) ? Thanks

Share this post


Link to post
Share on other sites
Quote:
Original post by rldivide
When I compile my static lib I use a full header (with everything needed).

Then, I made a lite header (without private members and unwanted functions, not needed for the use of the static lib in another project).
Yeah you can't do that, it violates the One Definition Rule.

Using COM is one way to handle this. Everything is done through an interface, and nothing can access any members directly.
You could use a similiar approach too even if not actually using COM. Just make an abstract base class and have the implementation in your lib derive from that. Your external client app only ever gets passed a pointer to this interface of the object.

Just ask if you'd like more info on how to do it.

Share this post


Link to post
Share on other sites
Well the problem is
struct foo
{
private:
int x;
};

needs the x in there or foo just isn't the same foo.

The simple way around it that many libraries do is have everything opaque. This can be acomplished through having external classes that only contain pointers, handles, unique identifiers to internal classes. Think of things like creating threads usually returning a "thread id" that you pass into all further operations on that thread.

distributed.h :

struct foo
{
private:
struct foo_opaque;
foo_opaque *opaque;
};


internal.h
struct foo
{
private:
struct foo_opaque
{
int x;
char y;
float etc;
};
foo_opaque *opaque;
};


This doesn't however fix the issues of:
Externally used templates still need everything available.
And I believe removing functions/virtual functions is going to screw up the internal tables of functions thusly causing stuff to stop working.

Share this post


Link to post
Share on other sites
KulSeran: thanks for the tip, I'll see if I can adapt this to my lib

iMalc: Yes I'm interested in having more details about that, since COM has another interest for me: I'd like to address my 32bit lib from a 64bit application. But I know nothing about COM: how would you do considering KulSeran example, for instance ?

Thanks !

Share this post


Link to post
Share on other sites
I think KulSeran's example may also violate the ODR, though it practice it would probably work.
Have a look at how to declare an Abstract Base Class in C++, and then try deriving your class from this ABC. If you can do that bit then there's not much more to it, but it could help to have some information about how the client app would use your library.

It's late and I really need to go to sleep about now sorry.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this