Boost logo

Boost :

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2011-11-23 13:40:39

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

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

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.

> > - 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?
If so, Boost has really been bending over backwards to support compilers
that don't support all C++03 features. And that was to support compilers
that did not conform to any standard at all! 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at