Question

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 inheritance, 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.

Answer 1

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.