Peter Dimov wrote:
Sorry for not following the thread properly, just a quick note:
(e.g. serialization support for core libraries should be supplied by serialization and not core [as I believe it is now, at least in many cases]).
This is not right. Serialization support for class X should be provided by X.hpp and it must be possible to do this without depending on any other header.
Appologies from me, too, as now we are getting even further from the original topic. I have seen at least one case where it was indeed X.hpp that introduced the dependency to serialization code. However, this generates another problem: If X is usable without serialization, users shouldn't be forced to also link to the serialization library, just because of this dependency. (In the particular case I have in mind this dependency was controlled by a preprocessor macro. That's not very practical, since packagers surely won't provide two sets of packages for X, one with and one without this dependency.) Thus, I'd suggest to encapsulate the X-serialization functionality into a separate library (may be header-only), such as X_serialization.hpp etc. Then I can still use X stand-alone, and drag in the rest whenever I need it. Thanks, Stefan PS: the library I'm thinking of is boost.wave, and there serialization was dragged in whenever BOOST_WAVE_SERIALIZATION is defined. -- ...ich hab' noch einen Koffer in Berlin...