Re: [PATCH] C++11 keyword fallback
Paul Eggert egg...@cs.ucla.edu writes: 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. Sure, that would work too. configure.ac: AC_CXX_FINAL() my-common-header.h: #if HAVE_FINAL # define MY_PKG_FINAL final #else # define MY_PKG_FINAL #endif [My suggestions was just to have autoconf do that stuff too, and it seems likely that in most cases people would want this. Even if autoconf does, it's probably good to advertise the HAVE_... macro anyway, in case some more complicated action is needed.] The only crucial bit is that autoconf shouldn't be defining the standard identifiers. [The same is true of const in many cases as well (it can effect overloading etc, in a way that means it can't simply be turned into a nop), but I expect these days pretty much every significant compiler supports const anyway, so the autoconfiscation never actually does anything in practice...] -miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [PATCH] C++11 keyword fallback
On 02/04/13 00:51, Miles Bader wrote:
I expect these days pretty much every significant compiler
supports const anyway,
I think that was always true for C++, which is why the
issue never came up for 'const' and C++. There were
a few old C programs that used 'const' as identifiers,
but they had to get changed for C89 anyway. No old
.h files happened to use 'const' as an identifier, so
we lucked out.
In contrast, '#define final /**/' is likely to cause problems,
e.g., on Fedora 17, /usr/include/gcrypt-module.h does this:
extern C {
...
typedef struct gcry_md_spec
{
...
gcry_md_final_t final;
...
} gcry_md_spec_t;
...
}
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [PATCH] C++11 keyword fallback
On Sun, Feb 03, 2013 at 01:52:18PM +0900, Miles Bader wrote: Roger Leigh rle...@codelibre.net writes: 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. All of these seem a bit questionable... I think the common thread here is that even when C++ programs are written with certain constraints in mind (e.g. don't use final) in order to cooperate with their autoconf-iscation, they almost always use external header files which they _don't_ control. As such, maybe autoconf macros that explicitly took an identifier to define would be safer. E.g., AC_CXX_FINAL([MY_PACKAGE_FINAL]) would define MY_PACKAGE_FINAL to either be final or . The package my-package could then safely use MY_PACKAGE_FINAL with this autoconf-iscation in mind, without worrying about conflicts with external headers. If you feel that this would be generally useful, I'll be happy to update the patch to do this. OTOH, if they all introduce extra complications WRT replacement of non-keyword names as you mention with final, maybe this is best to leave until there's a demand for such headers. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://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 ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [PATCH] C++11 keyword fallback
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. 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. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [PATCH] C++11 keyword fallback
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/Linuxhttp://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 ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [PATCH] C++11 keyword fallback
Roger Leigh rle...@codelibre.net writes: 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. All of these seem a bit questionable... The problem with final is that it's not a normal keyword, and so remains a valid identifier in C++11 programs and headers. Nulling it out is probably a bad idea; even when a program decides to avoid it, it cannot assume library headers won't use it. When constexpr matters, it's often not really optional, and although are cases where this isn't true, in general I'm not sure if an implementation that just nulls-it-out is reasonable. [It seems to me that the main case where constexpr can be safely nulled-out is library header files etc, which may define something constexpr only as an aid to external users. However such library headers, etc, should not freely redefine keywords, and typically aren't autoconf'd at all.] nullptr may be similarly problematic, as when used, it serves to disambiguate overloads in cases where 0 won't... I think the common thread here is that even when C++ programs are written with certain constraints in mind (e.g. don't use final) in order to cooperate with their autoconf-iscation, they almost always use external header files which they _don't_ control. As such, maybe autoconf macros that explicitly took an identifier to define would be safer. E.g., AC_CXX_FINAL([MY_PACKAGE_FINAL]) would define MY_PACKAGE_FINAL to either be final or . The package my-package could then safely use MY_PACKAGE_FINAL with this autoconf-iscation in mind, without worrying about conflicts with external headers. -miles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
