[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] C++11 keyword fallback
From: |
Roger Leigh |
Subject: |
Re: [PATCH] C++11 keyword fallback |
Date: |
Sun, 3 Feb 2013 23:16:48 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Sun, Feb 03, 2013 at 01:02:04PM -0800, Paul Eggert wrote:
> On 02/02/2013 06:01 PM, Roger Leigh wrote:
> > The attached patch introduces three macros:
> > AC_CXX_CONSTEXPR
> > AC_CXX_FINAL
> > AC_CXX_NULLPTR
> > which behave like AC_C_CONST et al but are for the new
> > C++11 constextr, final and nullptr keywords.
>
> Sorry, I don't know C++, so I'm not really qualified to judge
> the utility of these macros or of Miles's qualms about them,
> but would his comments be addressed by Autoconf macros that
> cause config.h to #define HAVE_CONSTEXPR rather than #defining
> constexpr, etc.? Or would that just be too awkward? I guess
> I don't know the usage scenario here.
My initial intention was that my substituting the keyword with
nothing, it would transparently allow code to build on non
C++11 compilers. HAVE_* would permit the user to do this
themselves if appropriate.
However, after looking into this a bit more, I'm becoming less
sure of the utility. In the case of nullptr, it's a type in
its own right (std::nullptr_t) which can be used to influence
template specialisation. So the substitution could easily
break code. Likewise for constexpr and final.
> > Would including macros such as AC_CXX_MEMORY, AC_CXX_TUPLE,
> > AC_CXX_REGEX etc. be acceptable?
>
> Is the pattern the same for all these? If so, it sounds
> like it'd be better to have one macro AC_CXX_STD and invoke
> it via AC_CXX_STD([memory]), AC_CXX_STD([tuple]), etc.
> Even if there are slight differences it still may be better
> to have one "smart" macro rather than lots of macros with
> repetitive innards.
The pattern is roughly the same. However... each needs a
bunch of different types importing into the std namespace, so
it's not /that/ slight. And for some (e.g. regex) the headers
are currently bust in GCC libstdc++ so need to be coupled with
a proper test instatiating and using the types to make sure they
work. We could certainly have a generic function like
AC_C_STD_TRY we pass all the details to.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800