On 4/24/19 8:17 AM, Peter Dimov via Boost wrote:
Andrzej Krzemienski wrote:
However, I do not understand what you do not find the situation symmetrical.
The situation is asymmetrical because there are many thousands of user-defined types, but only a handful of serialization frameworks.
In principle. In practice, taking a dependency on Boost.Serialization isn't desirable because it brings in half of Boost. Ideally, one ought to have been able to provide serialization support without including anything from Serialization, but I've been singing this song for more than ten years now and nobody's listening.
I've listened. It's just that it's hard to get motivated when no one really cares/notices the problem. Recently I investigated the issue and discovered that I had considered it in the course of the original library design. This is/was the motivation for creating the library in two halves - serialization and archive. The former is meant to be included in library code and has not dependency on library code or headers itself. The later implements the algorithms that actually do the serialization. This required a certain discipline to maintain. In the course of implementation/evolution of the library, this separate was compromised due to the demands of expediency and the fact that no one else seemed to care. This is one of the very few times that anyone has articulated the issue. It would be possible to make this enhancement. And it doesn't seem to be a huge job. But I'm sure it's pretty tricky and more time consuming than one would initially think. I've maintained the library (including backward compatibility for archives written under previous versions of boost!) for 15? years without too much drama. But it's hard to get motivated as I'm involved in other stuff. It's also not clear whether anyone really cares. I have no idea whether the library is used by 10 or 10,000,000 people so it's totally unclear as to what priority something like this should have. Also once such an effort is initiated, it might be difficult to keep it from spreading to addressing other subtle design issues which would unravel the effort to limit the scope to addressing this one particular issue. The problem is not limited to the serialization library, it's just more visible there. It's exacerbated by a flawed concept of "library dependency" which is a the heart of the difficulties on making progress on boost "modularization". I've pointed this outfor many years now and nobodies listening. off topic alert. It's pretty amazing that after 15 years the library is still widely? used. It's also very, very surprising that there have been no proposals for serialization in the C++ standard library that I know of. Boost has become a victim of it's own success. It needs to evolve to address Cmake/build systems, dependencies, incentivizing/recognizing boost library/tool authors, resources for library maintenance, better documentation, more reviews for libraries and more/better library submissions. Seems like we're stuck in 2010. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost