Roger Leigh <rleigh@xxxxxxxxxxxxx> 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@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
