   headers and static lib: unwanted memory shift ?
  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   
Quote:Original post by rldivideWhen 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.   ;  Well the problem isstruct 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.hstruct 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.;  KulSeran: thanks for the tip, I'll see if I can adapt this to my libiMalc: 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 !   ;  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.   