Subject: Re: [boost] Making two Boost libraries interoperate
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-24 15:47:05
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://listarchives.boost.org/mailman/listinfo.cgi/boost
>