On Tue, Nov 22, 2011 at 12:27 PM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote:
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?)).
Hello all, I wish I had find this link sooner not because it settle the discussion but because IMO it provides relevant input: http://wiki.apache.org/stdcxx/C++0xCompilerSupport 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) GCC: 4.5(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. HTH, --Lorenzo