On Mon, Jan 13, 2014 at 9:29 AM, Roy Stogner <royst...@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.
>
> https://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
>
> http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/
>
> http://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-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...
--
John
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
