Quoting a quote of mighty Cuch:"Have we actually decided whether to use C++ 2011? Lambdas and variadics are awesome, but the support is not universal (next version of MSVC will still not support variadics) -- perhaps the safe way to proceed is to use Boost where applicable (e.g., Boost.StaticAssert) and decide the cases where it's not (C++ 2011 lambdas) on a case-by-case basis?"

You are too kind, it was Prof Polter whom I quotedOne aspect: Lambda.Here's an example of C++ 11 with STL algos

Yes! Quote of a quote!BTW, I'm quite undecided about the C++11 matter. Not using it is very meh.

QuoteOriginally posted by: outrunOur code should be portable and widely usable right?Yeah, and basically all the people I know (in industry) couldn't use C++11.

Let me also add this -- sounds reasonable?"> Does boost have a spec (document) where it mentions which new language features in C++11 are permitted to be used in new libraries?No, because the answer is that any C++11 feature can be used in newlibraries, and in old libraries too.The critical issue is support for compilers that don't supply aparticular shinny new feature. Today most Boost developers are tryingto support all compilers that (except for export) are C++03 compliant.A howl would likely go up from reviewers if someone submitted alibrary that didn't work on C++03 compilers.Even that isn't absolute. If a library's sole purpose was to supportor ease the use of some C++11 feature, then it might well not work oncompilers that don't supply that feature.Boost has a bunch of feature macros in the config library to identifywhich compilers have various C++11 features."// http://lists.boost.org/Archives/boost/2 ... 5839.phpIn other words -- if you can ensure support for a C++03-compliant compiler, using Boost config library macros (or an equivalent construct, but please avoid reinventing the wheel) to identify it and graciously fall back on a C++03-compliant implementation, then fine. Some libs from Boost do this for us, like the above-mentioned static-assert -- IMHO a preference should be given to those Boost libs in such cases, so as to avoid reinventing the wheel and dealing with compliance workarounds ourselves.Otherwise (if the lib itself is C++11-specific, for instance), it's subject to a case-by-case review by the community.The above is subject to change based on the degree of C++2011-compliant implementations availability and mainstream adoption.From Portability requirements:There is no requirement that a library run on C++ compilers which do not conform to the ISO standard.There is no requirement that a library run on any particular C++ compiler. Boost contributors often try to ensure their libraries work with popular compilers. The boost/config.hpp configuration header is the preferred mechanism for working around compiler deficiencies.In particular, see Macros that describe C++0x features not supportedFor reference, there's also been a (quite extensive) discussion before: http://lists.boost.org/Archives/boost/2 ... 2.phpSince we're likely to have dependencies on Boost, a minimal supported implementation would be as in Supported compilers and platforms. Since we're a much smaller community and don't have the resources to test on as many platforms, by minimal I mean minimal, as in: no support guarantees whatsoever for anything older than the compilers on the Boost list.

QuoteOriginally posted by: outrunQuoteOriginally posted by: DevonFangsQuoteOriginally posted by: outrunOur code should be portable and widely usable right?Yeah, and basically all the people I know (in industry) couldn't use C++11.If we *really* need features, we could put them in #ifdef compiler switching, however, that would imply double implementation.Maybe we should look at "compiler requirement"? I have the following compilers we can use for compatibility tests* VS 2008 on Windows XP in a a virtual machine* GCC 4.2.1 i686-apple-darwin10* GCC 4.4.5 x86_64-linux-gnu4.4? I'd go for 4.0.x if you want to be safe. Plus LLVM too

QuoteOriginally posted by: HansiPlus LLVM too No kidding, this is true.

QuoteOriginally posted by: outrunQuoteOriginally posted by: Hansi4.4? I'd go for 4.0.x if you want to be safe. Plus LLVM too just ran apt-get upgrade, but it's still 4.4.5, maybe I should go experimental, I'h half a year behind on debian Banks don't really work that way unless you kidnap some IT persons family and force them to give you admin rights

Let's be conservative and stick to C++03 for a while (next 2-3 years?).

QuoteOriginally posted by: renormLet's be conservative and stick to C++03 for a while (next 2-3 years?).I second that. Any other views?