where should C++ options be documented?

Martin Sebor msebor@gmail.com
Wed Apr 4 06:24:00 GMT 2018


On 04/03/2018 06:20 AM, David Brown wrote:
> On 03/04/18 03:33, Martin Sebor wrote:
>> Jason,
>>
>> The manual mentions some C++-only options in the language
>> independent section 3.8 Options to Request or Suppress
>> Warnings and others in 3.5 Options Controlling C++ Dialect.
>>
>> For example, -Wcatch-value, -Wconditionally-supported,
>> and -Wzero-as-null-pointer-constant are mentioned only
>> on the former page, while -Wabi-tag, -Wctor-dtor-privacy,
>> -Wliteral-suffix, and -Wclass-memaccess are mentioned only
>> on the latter.
>>
>> That makes C++ options harder to find than they should be.
>> It also makes it difficult to tell which C++ options are
>> included in -Wall or -Wextra.  I think we should converge
>> on the same approach for all C++ options that doesn't have
>> these problems.  What should it be?
>>
>> An approach that I think might work well is to continue
>> to mention even C++-only options in 3.8 but move their
>> descriptions to 3.5 (i.e., have the entry for each link
>> to the full description of the option on the C++ page).
>>
>> Should I try to make this happen for GCC 8?
>>
>> Martin
>>
>
> What about the C only options?  If the C++ specific options get their
> own page, perhaps so should the C specific options (like "-Wimplicit")?
>  There are not as many of them, however.

I'm just trying to tackle warning options for now but even
those are distributed between several sections (Options
Controlling Objective C and Objective C++, and Options
Controlling C++ Dialect, in addition to Options to Request
or Suppress Warnings).

So I'm thinking that in the first pass I'll do just C++
Warnings), and if we like it we can extend to warnings
for other dialects, and eventually maybe even the rest
of the options if it makes sense.

>
> (Ideally, IMHO, warning flags that only apply to one language should be
> silently accepted and ignored by the other languages.  That would
> simplify my makefiles :-) )

I suppose that might make sense as an extension but it's
beyond what I can do for GCC 8.

Martin



More information about the Gcc mailing list