Re: [patch] Extend AC_PROG_CXX to check for standards conformance

[Roger Leigh]

On Mon, Jan 21, 2013 at 10:02:01AM -0800, Paul Eggert wrote:
> On 01/21/2013 05:46 AM, Roger Leigh wrote:
> > For both C and C++, I think there are some considerations
> > here where it does make sense:
> > 
> > - If my project supports language standard n, enabling
> >   standard n+1 or n+2 enables language features which are
> >   actively harmful to use, since unintentional introduction
> >   of later language features will break building on systems
> >   which don't support it.
> 
> Yes, if this were a real problem, we'd have to do something
> about it.  But for C, it's not, and it hasn't been a problem
> ever since Autoconf was introduced.  Historically, the biggest
> problem in this area was when C89 supplanted K&R C; and even
> back then, Autoconf was firmly in the "let's default to the
> latest version".  This approach worked fine then and works
> even better now.

I think the fundamental issue is in the behaviour of what we
do when the system doesn't provide a required feature.  In the
case of many of the historical features, autoconf permits the
program to adapt to the system by implementing various
workarounds to enable the code to build and run when certain
features are missing or not compatible.  For C stuff like
const/restrict/volatile/inline, it's possible to achieve this
fairly simply, and autoconf does a very good job here.

However, if you look at the C++11 features like declspec,
automatic type inference, array initialisers, delegate
constructors, range-based for loops, lambdas, etc. these
features can not be substituted for.  If you use them, you
absolutely require a C++11 compiler; there is no sane fallback.
A fallback is certainly possible for some of the keywords,
e.g. "final" and is very much possible for library functionality
e.g. shared_ptr.  But for the core language changes, for the
most part this is simply impossible.

It's this situation that calls for the ability to disable the
fallbacks and require a specific version.

Note that this also applies to C11, but to a lesser extent.

> > - If my project supports language standard n, and autoconf
> >   autodetects n-1, configure will succeed unless I do
> >   additional feature tests.  It will of course fail at
> >   compile time, but the fallbacks are essentially useless to
> >   me.
> 
> They may not help, but in practice they don't hurt.  Right now,
> for example, one would be crazy to insist on C11, as that would
> prevent too many people from using one's package.  By the time
> it's safe to insist on C11, almost everyone will have it, and
> the few people who don't have it will all know what to
> do when the fallback kicks in.

At least from my perspective, my primary target is contemporary
GNU/Linux systems.  Given that the current compiler in use in
Debian is GCC 4.7 and in the next+1 stable release will be >=4.8,
and what I'm developing right now will target the next+1 stable
release, I have no reason not to use C++11 features today.  The
only current thing preventing this is lack of portable support
for it in autoconf, which this patch aims to solve.  This is
certainly not the norm, and I can quite understand people not
wanting to use it today, but I would certainly like to have
support for it sooner rather than later.

> I'm not saying that we shouldn't do anything in this area, but I am
> leery about adding a half-dozen published macros and the resultant
> complexity in documentation for a feature that hardly any developer will
> actually need, a feature that (unless carefully documented) is likely to
> confuse developers into thinking that they need it.

I quite accept that the default macros will serve the vast
majority of users well.  But with the many new keywords introduced
which don't have fallbacks, I do think that being able to select
"C++11 only" or "C++98 only" is needed here.

> I think the main issue here is philosophical.  Autoconf is designed
> to tailor the program to whatever the host provides.  The C and C++
> standards follow a different tradition: they specify what the host
> must provide.  Both approaches work, indeed the Autoconf way depends
> on a minimal standard substrate, but once you're in the Autoconf
> world it's better to do things the Autoconf way.

Agreed for the most part.  However, for both the C and C++ macros
it doesn't really /cost/ us anything to give the user the choice;
they can use the recommended way with autodetection and best-effort
fallback to the latest available standard, or choose a specific
standard.  While for both C and C++, using the latest by default
is certainly sensible, when your code is using features which
/unconditionally require/ a strict dependency on a minimum version,
I do feel that being able to request autoconf satisfy that need
is needed and useful.



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