Re: [boost] New libraries implementing C++11 features in C++03

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-11-23 01:04:59

On Wed, Nov 23, 2011 at 4:27 AM, Jeffrey Lee Hellrung, Jr.
<jeffrey.hellrung_at_[hidden]> wrote:
> Within the discussion for the review of the proposed Boost.Local library,
> Hartmut Kaiser raised a concern that I think should be addressed more
> broadly by the community, if possible. Â I quote Hartmut:
>
>> 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?
>
> Indeed, I ask the community, do such libraries belong in Boost? Â If so, is
> the bar for acceptance of such libraries automatically and necessarily
> higher than libraries that introduce genuinely new capabilities in C++11?
> If so, what additional criteria must such a library meet?
>

I have been watching the discussions around the reviews for the
proposed Boost.Local library. I would like to weigh in on this issue
that seems to be important to address from a non-involved perspective
(mostly because I haven't sent in a review for Boost.Local nor would I
do that even now).

First, I think there's two problems here that we're all trying to solve:

1) C++11 is good but apparently people don't think it's good enough
for production yet. There's a temporal dimension to this problem which
means it's just a matter of time when compilers support C++11 as the
de-facto version of the language that is supported. During this delay
though people want to get the features in C++11 approximated in C++03.

2) C++11 doesn't include a feature that some people find may be useful
but can be forced onto users (or at least is being tried to make it
popular by getting it into Boost) using whatever facilities are
available in the language. The categorical dimension here is not tied
to time, effort, or anything else but rather the state of the
standard.

For solutions that address #1, I would say it depends -- if
Boost.Move, Boost.Shared_ptr, Boost.Scoped_ptr, etc. get deprecated
when C++11 has been made ubiquitous (which I would believe should be
the correct way forward) then yes. Boost.Local unfortunately doesn't
belong with the grouping of these libraries precisely because it
addresses #2 however "semantically equivalent" local functions are to
C++11 lambdas.

For solutions that address #2, I would say probably if it's done in
good taste and follows the traditions of Boost in terms of quality of
implementation, quality of execution, and utility of the solution. I'd
say though that addressing issues that fall under the #2 category
should be implemented as compiler extensions instead of hacks using
existing current language features. This is to say that although
Boost.Concept_check is there as a good proof of concept for Concepts,
it by itself stands as something that shows the utility of the library
in the tradition of Boost's quality. Same goes for things like Phoenix
and Proto -- Phoenix allows polymorphic lambdas while Proto allows for
doing DSEL building in C++.

I would imagine that if/when C++1x gets polymorphic lambdas and maybe
expression template building facilities built in then it's worth
deprecating those libraries as well. Note that neither of these things
resort to using macros which are cheap alternatives to people writing
it down themselves.

So applying my logic to the discussion on Boost.Local, I see it as
doing a not-so-good job of doing #1 while falling short in #2. If
however it proves that local functions would be a good addition to the
language, I would suggest that the library live outside of Boost, get
critical mass, and then be proposed as an extension to the language in
the form of a proposal for local functions. Although I don't see how
local functions are better than C++11 lambdas that are auto-captured
to a local variable, maybe other people would like to use local
functions as a different syntax.

> I add two additional notes to help put the discussion in context:
> - Within the proposed Boost.Local review discussion, several individuals
> pointed out that they will likely have to work professionally on C++03
> compilers for at least a few more years.

I would then think that there's nothing stopping them from using the
library even if it's not in Boost.

> - Recall that Boost has several (recent) libraries that could easily be
> labelled as "transitional" libraries: Move, Atomic (at least proposed, not
> sure if accepted), Container. Â Further, several older libraries are now
> part of the C++11 standard (e.g., Thread (right?)).
>

I would think though that these transitional libraries would be
deprecated as soon as the standard counterparts become ubiquitous.

Cheers

-- 
Dean Michael Berris
http://goo.gl/CKCJX