It has to do with the fact that the list of dependencies passed into the linker is often only a subset of the total set. Your main argument against the #pragma, the way I understood it, was that the #pragma hided information that would be otherwise visible. That limitation is there for dynamic libraries as well.Chris wrote:Passing "complex" resources, such as std::string, between DLL/module boundaries has always been problematic. You can't safely pass such resources between them as anything but raw externally-owned memory if you're not sure you're using the same library since they can expect different sizes and layouts. But I don't see what that has to do with the given discussion of a library's own separate dependencies being a problem for the main app.
I agree with you that an ideal written dynamic library uses a plain C interface with no reliance on other libraries in its public interface. But it is also an unreasonable proposition for a lot of types of projects. We don't even have to bring C++ into this. Let's imagine that I'm writing a dynamic library adding a QMainWindow equivalent for Gtk+. My library extends another library, so I don't really have a choice - my public interface has to expose Gtk+ types unless you expect me to spend the majority of the time writing wrapper binding code. Thus in the real world there's lots and lots of dynamic libraries where their internal dependencies very much matter to the main executable.
