Peter Dimov wrote:
Edward Diener wrote: [...]
Again John Maddock has used these #pragmas extensively in Regex++ to avoid data layout problems and I have used them in my libraries for the same reason, including my own components built on top of Regex++, and I have never encountered problems with them.
The issue is less clear-cut than you make it seem.
What we have here is a static library (Signals) that uses several header-only libraries (shared_ptr, Function, maybe others.)
OK, I do see this problem.
To "fix" the "alignment problem", we need not only #pragmify Signals, but those other header-only libraries as well. Furthermore, we need to be careful to not miss a header-only library that is used, directly or indirectly, by Signals, or any other static library.
I view it this way. The people who create libraries, whether header-only or implementation, should be responsible for setting reasonable data layout details. After all, as I have previously mentioned, Borland sets data layout #pragmas for all of their RTL code even when the header is a class template, and therefore likely to be a header-only implementation.
This impacts not only Signals users; it also affects those that only use header libraries. They don't need the "fix", and some of them may legitimately object to the binary compatibility settings that the headers have inflicted on them, especially if these settings lead to slower or larger code.
Yes, I agree in theory. But compiler implementors do do this and I don't think they really get complaints saying "Gee, I don't like your pack alignment for your XXX class. It's really slowing me down."
The alternative is simple: always build libraries and applications using the _exact same_ settings. This is a good general advice, and it also applies to settings that we cannot "fix" using the #pragma method.
I don't think the alternative is simple. Do you feel good forcing end-users of Boost to build their applications according to what settings you specify ? And what happens if another 3rd party developer tells their end-users that they must build their applications to settings they specify and it is not the same as the Boost settings ? And what if the end-user needs to change from the Boost settings for their own purposes ? Dictating to the end-user what you insist his settings must be in order to use libraries effectively is not my idea of a simple or good alternative. I recognize that you have brought up valid points, but I would still much rather protect the end-user against inadvertent data layout problems if they change their own global settings than worry that they might not like the data layout I set for my own classes.