Libs/dll on the device?

But on the other hand, DLL:s used by your app are loaded when the app is started, so it's not like you're saving memory by using statically linked DLL:s instead of statically linked libraries.

I split projects for faster build times. Sometime I need to do a clean rebuild, and with big projects it is very irritating.

Wouldn't you need to rebuild all dlls of your project to do a real "clean rebuild" anyway?

If you need to rebuild source file, it is because it has binary dependencies on some other part.
You don't solve this problem by splitting it in separate dlls.
You solve it by getting rid of the binary dependency
And you can do that with just proper moduling in different source files.

It might be easier to keep track of though if you keep it in separate dlls, because it will kick you in the nuts if you mess it up, but on the other hand it might be trickier to resolve dependency problems when they arrive, and they might be there without you realizing it, because the build environment doesnt warn you properly..

I dont see the point to split your program into several binaries just for abstractions sake.
Dlls is for shared code, all other code could just as well be statically linked.

Actually, you often gain a bit memory from useing a static linked lib, if you have a big lib with lots of functions, of wich you only use a few.


And, what do you gain by abstracting it in a dll as opposed to a static lib?

just my 2 cents

Yes. As I said. Shared code in dlls.
Everything else statically linked.

Clarification:
If you have a big pile of code that doesn't change much (compared to the rest of your system), it could be a good idea to put it in a (statically linked) lib.

But there really isn't much point in a dll unless you share the code.

Or want to be able to upgrade the dll independently from the rest of the system.

If you don't, putting it in a dll will just give you more work for no gain.

Also, it will take more memory to have it in a dll then in a static lib if it is only used by one binary.

Nope. You need only to rebuild one DLL and a sis file for main project. Unless you use project references that forces clean+rebuild of child projects.

Just wanted to add another note why useing a DLL might give you more work then needed:

You also need to maintain binary compatibility (that is, the size of the object too), not just the API entry function order (freeze .def file), if you want to avoid having to rebuild "everything"

This can be quite a hassle in early development.

It means you can not add any new members variables to the exported class, and nor can you add any virtual functions too it, or you will open a can of User:42. (until you makes sure you clean up .lib files (which the build system have a a habit of leaving, even if you do a reallyclean), and relink the user of the DLL)

This is not a problem with static libs.