>> This gets to the larger question of when we will require C++11, >> which in my mind is probably a good year or so from now. In the >> meantime, should we bother trying to track partially implemented >> subsets? > > Using C++11 (or TR1) when it's available can be beneficial for making > sure there's an unordered_set and unordered_map available for us to > use. We fall back on set and map otherwise, but the asymptotic > complexity is worse (otherwise we'd have specified a set or map > instead of one of my ugly macros to begin with) when we do. > > Making sure we compile with C++11 turned on is critical; we especially > don't want to break when someone tries to pull in one of our headers > into the new standard.
Agreed, > Actually *requiring* C++11, I'd prefer to wait for another year or two > at least; last time I checked (which admittedly was a while ago) even > Intel wasn't entirely up to spec yet, and I'll bet there's people > stuck on older icpc and other old commercial compilers out there. I > could be talked into an earlier upgrade if nobody screams too loud, > though; getting some of the best Boost-isms without requiring Boost > would be nice. I think the slower, deliberate plan is the way to go. Some of the nice features unfortunately can't be worked around (auto, lambdas, etc…) so we need to wait until there is widespread reliable support. As for the particular fparser issue, I'll see about not passing it our compiler flags as a simple fix. -Ben ------------------------------------------------------------------------------ The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
