Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-25 11:50:41
On Tue, Nov 22, 2011 at 12:27 PM, Jeffrey Lee Hellrung, Jr.
> 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 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.
> - 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 wish I had find this link sooner not because it settle the
discussion but because IMO it provides relevant input:
C++11 feature: Lambda expressions and closures
N-papers: v0.9: N2550, v1.0: N2658, v1.1: N2927
HP aCC: No support
EDG eccp: 4.1(v0.9)
Intel C++: 11.0(v0.9), 12.0(v1.0)
MSVC: 10.0(v1.0), 11.0(v1.1)
IBM XLC++: No support
Sun/ Oracle C++: No support
C++ Builder 2009/10: No support
Digital Mars C++: No support
Clang: No support
Missing information are:
1) Which of these compilers is supported by Boost.
2) Which of these compilers can handle Boost.Local (currently tried on
GCC, MVSC, and Clang but not others).
3) When these compilers will support lambdas (assuming there's
currently a plan for that).
Assuming 1) Boost supports the compilers with "no support" and 2)
these compilers can handle Boost.Local (e.g., this is the case for
Clang) then without Boost.Local there's no alternative to use
statement syntax to define closures at local scope on these compilers.