Re: [boost] [local] Review

Subject: Re: [boost] [local] Review
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2011-11-21 21:33:06

> On Mon, Nov 21, 2011 at 8:30 AM, Hartmut Kaiser
> <hartmut.kaiser_at_[hidden]>wrote:
> [...]
> 
> > Ok. However this raises a more serious question. Should we as the
> > Boost community still encourage solutions and libraries solely for
> > portability with ancient compilers? I'd say no, but YMMV. Boost will
> > be still around 2, 5, or 10 years from now. What's the utility of
> > adding such a _solely_ backwards oriented library from this POV?
> >
> > Based on your arguments I'd suggest to make (Non-)Boost.Local
> > available somewhere for other people to use and for you to maintain in
> the long term.
> > You don't have to have it in Boost just for it to be used and useful
> > for others. What's the point in cluttering Boost with this?
> >
> > I'm sure, any review manager interested in keeping Boost healthy and
> > alive would agree with me. Adding each and every library which seems
> > to be cool just for the sake of it - without thinking about the long
> > term consequences
> > - hurts Boost. Badly.
> >
> > But I better shut up on this before I'm going to become wind up too
> much...
> >
> 
> Since this indirectly references myself, I'd like to point out that yes, I
> agree with your overall sentiment: "Adding each and every library which
> seems to be cool just for the sake of it [...] hurts Boost."
> 
> To answer your initial question, though ("Should we as the Boost community
> still encourage solutions and libraries solely for portability with
> ancient compilers?"), I don't know.  You seem to acknowledge that the
> Boost community, at one time, did encourage libraries solely for
> portability; indeed, Boost.Move comes to mind, and I think Boost.Atomic
> (just proposed?
> or also accepted? I forget) fits there as well.  And now, presumably with
> the advancement of C++11 (at least partially) compilers, you don't think
> we should.  Or, perhaps, the added value that Boost.Local provides is
> significantly less than that for Boost.Move and Boost.Atomic (and whatever
> else), hence doesn't meet the bar for acceptance given that it's almost
> entirely a portability solution.  Both of those are, I believe,
> justifiable opinions.

Boost.Move is an infrastructure library needed by Boost itself and
Boost.Atomics has no MACRO_BASED_INTERFACE. 

I might sound inconsistent, but it's probably the combination of all three
which trips me off: 'solves no real problem', 'just for the sake of
portability', and 'MACROS'.

> It's fortunate that the quality of the library under consideration has
> never really been questioned, and, indeed, it has been emphasized even
> among those who have voted against inclusion.  I will have to go back
> through all the threads (ugh!), but it thus seems that the two primary
> arguments against inclusion are "Is this actually solving a real problem?"
> (together with all the discussion about whether the solution that
> Boost.Local provides is actually better than existing alternatives) and
> "Does a library providing a portable interface in C++03 for C++11 features
> belong in Boost?".  Regarding the former issue, it *seems* there's been
> enough actual use to deem the library sufficiently "useful"; but, again, I
> will have to review the discussion.  I'm now thinking, though, that coming
> to a consensus on this latter issue (together with any qualifications) is
> too important for me to make a premature ruling on Boost.Local and risk
> setting an individual-decided precedent.
> 
> Am I making too big a deal out of this?  Or do you think this is
> misguided?

Jeff, I fully trust you will make the right decision, and no, you don't make
a big deal out of nothing, IMHO.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu