On Mon, Jan 13, 2014 at 9:29 AM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

On Mon, 13 Jan 2014, Kirk, Benjamin (JSC-EG311) wrote:

> I'd like to polish a release this week if possible.  Roy'd previously mentioned calling it 1.0, but I'd like to go with v0.9.3 because
> 1) I'm not aware of anything drastically different vs 0.9.2, but correct me if I'm wrong;
> 2) In any case I'd like to wire brush the code and remove all the APIs that have been deprecated for ages;
> 3) I'd like to remove the default comm_world business for 1.0.
> So v0.9.3 could be imminent with then 1.0 a API cleanup follow-on.

This all sounds great.  Just to be clear, we're talking 0.9.3 this
week, then 1.0-rc1 ASAP after we go through and shred deprecated
stuff?  My "warnings fixes" branch might be worth merging into the
latter too.

> But what about C++11?  I could see 1.0 as a 'maintenance stream'
> where we back port important bug fixes but otherwise leave it alone.
Gah.  I can't believe *I'm* objecting (my current app development is
using C++1y features, which like C++11 features are awesome), but
AFAIK full C++11 support is *still* limited to g++ and clang++.  I'm
not sure I want to deal with the hassles of trying to remember what's
in C++11 versus what's in Lowest-Common-Denominator-Compiler.


I can already see a feature I'd like to use that didn't make it into
icpc 13, and three features that aren't even in icpc 14.

I could probably be talked into us supporting the intersection of
"stuff in C++11" and "stuff in a single broken compiler, X", where X
is something I can get auto-testing in buildbot, preferably icpc 11.1,
12.1, or 13.1.  But then everyone with older pgc++ or other "not quite
C++11 compatible" compilers will be gambling.

Is there anything in C++11 that can be treated analogously to the "LIBMESH_BEST_UNORDERED_MAP" business we've got now?  That's actually been pretty useful in the past.

Off the top of my head, the C++11 features I'd really like to use (auto, range-based for loop syntax, lambdas) don't really lend themselves to preprocessor detection/macros like this.

But what about easing in to the C++11 world with the new static_assert?  We can use configure to see if the compiler supports it, and then have a libmesh_static_assert that either uses it or falls back on libmesh_assert as the case may be.

At the very least, this would force us to start a c++11.m4 file of some kind to test for specific features, which I don't think we have at the moment...