This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: where should C++ options be documented?

On 04/03/2018 06:20 AM, David Brown wrote:
On 03/04/18 03:33, Martin Sebor wrote:

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?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]