From: cfe-dev [mailto:firstname.lastname@example.org] On Behalf Of Joerg
Sonnenberger via cfe-dev
Sent: Thursday, March 02, 2017 4:02 AM
Subject: Re: [cfe-dev] Setting default dialect to C++11
Right, I don’t think it is a good idea for clang as a project to have
important default configuration flags that diverge between
platform/target, like the default language. This is reducing portability
and quite user hostile IMO.
I don't understand how it is "user hostile”
I expect `clang myprogram` to treat my program sanely (i.e. not change the language standard behind my back without me knowing). Requiring me to specify that I’m OK using C++22 seems fine.
to have our toolchain default
to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.
As you mentioned below, Xcode has default flags for clang that are always set. It does not mean that the clang supplied by Apple would change language default. I expect an SDK to help the user to setup the right flag. That different from changing the default inside the compiler.
We provide the correct target triple; we point to the correct directory
for our headers; we point to the correct directory for our libraries; we
set the correct target and subtarget [there is only one]; we do a variety
of other defaulting, as a service and convenience to our users.
I somewhat disagree and that's why I didn't have a problem with the
change. As long as we silently miscompile C++03 code when enabling C++11
or later, I don't think it should be a general default. In a somewhat
more restricted environment like the Playstation toolchain, they are in
a much better position to judge wether those miscompiles will be
triggered by their userbase or not.
For example if a platform does not support exception, the driver can
error if -fno-exceptions isn’t supplied, requiring an opt-in from the user.
We *support* exceptions, it's just not our *default* (same as for Xcode).
Erroring out on "clang -c t.cpp" seems incredibly user-hostile, but that
is the burden you are proposing on all of our licensees.
I don’t see any burden here.
Now let's look at it from the other side: What are the advantages of having
different defaults? The primary advantage I see is increased test coverage.
I don’t buy this: setup your SDK environment to invoke clang with the right set of flags and setup bots to test more configuration.
Internally we run lots of our tests in a pile of different configurations
(different optimization levels, with/without -g, with/without LTO, etc)
and this has proven to be very helpful in finding bugs.
I don't have statistics off the top of my head but the C++11 default has
found things; see for example PR32066. This tells me there is value to
avoiding a "configuration monoculture" and varying defaults is a good thing.
No it just means more testing coverage is good. Changing the default is not the right way to achieve this IMO.