Advantage of wrapping classes in DLLs

I've just finished a phase in my project where I wrote a small infrastructure to carry out a certain task, made of a core class with several auxiliary classes. The C++'ness is quite basic - single inherita开发者_JS百科nce, some STL containers, that's it. No threads - client runs the show.

What I would like to do now is wrap it all up in a DLL, version it, and use it as a standalone unit. I'd like that seperation in order to track changes and development better, and perhaps for other projects as well.

As I don't have experience with classes in DLLs, I would like to hear yours: What's your approach to this problem?

Specifically:

• Is it worth the trouble?
• Do you do that often or not at all?
• What about compatibiliy issues (like clients compiled using a different compiler)?

I'm not really asking for a debate (though that's the probable outcome), but rather an advice from experience.

Thanks for your time.

I find it hard to see any benefit with this. I can see plenty of problems:

• No type checking across a DLL boundary. Any version mismatches will result in runtime failures, harder to detect than compile time failures.
• Extra deployment headaches. You may be tempted to update some but not all modules and so deal with complex dependencies.
• All clients that want to use these DLLs must use the same compiler.

Only make this change if you can identify benefits that outweigh the negatives.

C++ code is not binary compatible between compilers, it's generally no use creating DLLs exposing C++ classes that aren't built as part of the project that uses them.

If you want to create a Windows DLL with a well-defined object-oriented interface that the rest of the world can use, make it a COM inproc server.