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 17:52:10

On Thu, Nov 24, 2011 at 5:40 AM, Nathan Ridge <zeratul976_at_[hidden]> wrote:
>
>> 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.
>
> I don't think Phoenix is an appropriate example here. The contribution of
> Phoenix to C++ goes far beyond just simulating polymorphic lambdas
> or providing a terser syntax for some lambdas. Phoenix allows representing
> pieces of code as data, which can then be traversed/analyzed/transformed.
> Adding polymorphic lambdas or nicer lambda syntax to C++1x isn't
> going to deprecate that use case.
>

My bad. Yes, Phoenix is not just for polymorphic lambdas and yes code
as data is a nice feature.

Point still stands though if C++1x gets that runtime introspection
capability on normal code.

>> > 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.
>
> The name "Boost" carries with it a certain standard of excellence, quality of
> implementation, and ubiquity. As a result, it is often much more feasible to
> use a library in a project/team/company if it's part of Boost than if it isn't.
>

Agreed.

> Case in point: at my company, we use Boost extensively, but management
> is very hesitant to introduce a dependency on other libraries, especially
> if the library "merely" makes coding in general more convenient, rather
> than providing some domain-specific features or API. I think the situation
> is similar in many other companies and projects.
>
> For this reason, I think libraries whose purpose is to make general-purpose
> coding more convenient, rather than some domain-specific use, are especially
> appropriate for inclusion in Boost.
>

Unfortunately I don't think this is Boost's problem but rather an
organizational problem. Boost serves to be proving grounds for
libraries for future inclusion into the standard or as a reference
implementation for a proposal to be made part of the standard. It's
also a place for libraries that augment and work with the current
standard library.

My point still stands that in reality there's nothing stopping users
from using libraries that are not part of Boost since any library
(even Boost) has to be vetted for and evaluated by users in any case.

>> > - 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.
>
> Do you consider C++03 as having been ubiquitous for the past 7-10 years?

Yes.

> If so, Boost has really been bending over backwards to support compilers
> that don't support all C++03 features.

Yes it does.

> And that was to support compilers
> that did not conform to any standard at all!

Which is unfortunate.

> I would expect just as much
> sympathy and support for compilers which do support a standard (C++03),
> just not the latest one (C++11), for at least as much time.

This sounds (and if history is the judge, is really) needless and
unsustainable in my opinion.

Cheers

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