Large .lib project

use an interface class whose methods are pure virtual and a creator function. put those in the public header. then derive a class from the interface and implement everything. make the creator function allocate an instance of the implementation class, i.e. via new, and return a pointer to the interface implemented by it.

I don''t think I follow. What is the purpose? It sounds like you are trying to hide the inheritance heirarchy and all of the base class declarations. That can certainly be done and it is legitimate to do to protect intellectual property. You wrote it and it is yours to share or not share as you please. If you are doing it to protect the user from themselves then don''t waste your time. Spend your time doing something more productive instead. Most likely if the user is going to do what you fear then it is because you made a mistake. You left something that they need in order to use your library in their application out of the interface. So they are digging looking for a way to do what they need to do. You don''t want to keep them from doing that because the alternative is either writing code that is already there or abandonning the library. Put the time and effort into making sure you have the interface right. That means functionally complete and intuitive to use.

the idea is to remove implementation details from public interface, so that clients don''t have to be recompiled when you change implementation if you don''t change the interface.

With a statically linked library if you don''t recompile then nothing changes.

i think you''re confusing recompiling the library with recompiling the clients.

Thanks guys. Both answers were useful. I also kind of agree with you [LilBudyWizer], there is probably some work left to be done in order to make it all intuitive and easy to use.

But as you also said, I would like to hide the base class declarations so I don’t have to dump them all in the header-file that comes with the library, it gives even me a hard time finding what I''m looking to change as I''m working on it...

You said that it could be done, would you mind explaining your ideas?


And for niyaw''s method I think I understand what you mean. It’s a great idea. But wouldn’t it be better if I made a interface class derived form the baseclasses, then added the pure virtual functions. Then derived a new class from the one with the virtual functions and made the implementation there? If not, then what is the difference between the methods?

If you inherit off of the class then the class has to be declared. Generally unless you really know what you are doing the declaration should not vary from the definition. Specifically it should have the same data members and virtual functions in the same order. Those are part of the actual data storage. Change that and the compiler will generate the wrong code, i.e. access wrong offset for a data member or call the wrong function. To be perfectly honest even if you know what you are doing you still shouldn''t do that.

So if you want to hide the base class then you can''t inherit off of it. It is part of your implementation, you have to inherit off of it right? Wrong. You can put a wrapper around the class. All the user sees is a class with a void pointer and a bunch of functions. Within the library that same class is redefined as having a pointer to an instance of the implementation class. The implementation of the interface class just turns around and calls the implementation class it is pointing at. Now the inheritance heirarchy need only be exposed to the library and not the users application. One disadvantage is the overhead. Every call is two calls. The user calls interface::f and interface::f calls implementation::f. Another disadvantage can be viewed as an advantage and is that it is a complete mystery to the user how in the world that interface class manages to do what it does.

As far as confusing recompiling the client and library I don''t see it. A statically linked library is in the executable as far as I know. Now strictly speaking you don''t have to recompile the client to bring in a new version of the library, but you do have to relink it. Generally people will recompile when they need to relink so it is a petty distinction in my view. Certainly if it takes you a few hours to compile then you are going to have a strong preferance for only relinking. Under that scenerio you are most likely going to use dynamic libraries so that you don''t have to relink either and can instead simply reload the application.