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

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-24 15:15:28

Hi Michael and thank you for bring my attention back to your original
reply on this topic.

On Wed, Nov 23, 2011 at 1:04 AM, Dean Michael Berris
<mikhailberis_at_[hidden]> wrote:
> 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

Let me understand better your point. Is this because Boost.Local
functions cannot be declared within expressions while C++11 lambdas
can?

> while falling short in #2. If

Again, let me understand your point better. Is this because
Boost.Local functions use macros?

> 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.

Thanks a lot for the clarifications.
--Lorenzo