Re: [boost] Making two Boost libraries interoperate

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://lists.boost.org/mailman/listinfo.cgi/boost
>