On Thu, Nov 24, 2011 at 5:40 AM, Nathan Ridge <zeratul976@hotmail.com> 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