Rene Rivera wrote:
Edward Diener wrote:
I have argued this case before in general, and agree with it.
I think I've been in that argument ;-)
In all the dlls and libs which I have ever created as a Windows programmer I have followed this pattern.
I haven't. For me the choice of runtime has always been independent of the type of product I'm building.
When building products for yourself, you can choose your own mix. When distributing 3rd party libraries which use auto-linking, you need to decide how that should work for others. I still think that auto-linking should be dynamic rtl-dll and static rtl-static lib. Of course a more flexible system might allow auto-linking to be turned off and the end-programmer allowed to manually choose.
When distributing third-party libraries I think it is normal to distribute either an all dll system, with all dlls using the dll version of the compiler's run-time library, or a single executable, with all libraries linked being static libraries which use the compiler's static version of the run-time library.
That is not a binary comparison. It's common to distribute executables with dlls and use the dynamic runtime. It's also common to distribute libs that use the dynamic runtime, so that users can build either exes or dlls from that library.
What about the user who wants to use one's 3rd party library and wants to distribute the final executable as a self-contained file not relying on any other dlls ? This can not be done if you only have libraries, whether static or dynamic, which use the run-time dlls. Of course you may argue that a user who wishes to do this is not very common, but my experience is that they are, and are pretty adamant that such a scenario should be supported by 3rd party libraries which they use.