|
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.
Regards,
Nate
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk