On Sun, Jan 13, 2013 at 3:19 PM, Roy Stogner <roystgnr@...> wrote:
> In a tangential aside to a now-closed GitHub ticket, John wrote:
>> std::auto_ptr has actually been deprecated in C++11
>> So for that one I'd say let's just wait a few more years and replace
>> AutoPtr with std::unique_ptr instead...
> From what I'm reading about C++11, std::unique_ptr could basically be
> described as "auto_ptr, but using rvalue references to turn run-time
> errors into compile-time errors". So we could probably typedef
> unique_ptr as AutoPtr just as soon as we add a --enable-cxx11 option
> to configure.
It's actually legal to use unique_ptr's in (move-enabled) versions of
standard containers, whereas it's never legal for auto_ptr's.
unique_ptr's are also supported in some algorithms (std::sort OK,
std::copy NOT OK,
So it could be tricky to use a typedef: if I'm writing C++11 code and
putting "libmesh_typedefd_ptr" into containers, it will compile fine
for me but fail for anyone who's running a non-C++11 compliant
> Although I still don't want to require C++11 any time soon, it might
> be nice to have as an option, with some macros to enable selective
> backwards-compatible enabling of a few features. It appears that
> constexpr, move constructors, and rvalue-moving operator overloads, if
> used properly, can be easily omitted (or in the constexpr case
> replaced with const) to get equivalent C++03 code that's merely less
> well optimized. Static asserts can be omitted to get equivalent C++03
> code that's merely less well tested. And method override identifiers
> can be omitted to get legal C++03 code that's merely less of either.
According to compiler.m4, it looks like we always pass -std=c++0x for
GCC 4.4, 4.5, and 4.6, but we don't (that I know of) have any
configure tests specifically for the features you mentioned... maybe
create a github issue for this to be done?
Googling reveals this...
> There doesn't seem to be any way to allow for lambdas, auto, range
> loops, or other niceities without breaking C++03 compatibility, which
> I'd rather not do for any existing libMesh subsystems.
Agreed. Sadly, writing:
crazy<templated<type > >::thing
foo = bar();
kind of defeats the purpose...