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: Do we really need a CPP manual?

On 16/12/16 11:55, Jonathan Wakely wrote:
> On 16 December 2016 at 06:46, Sandra Loosemore wrote:
>> Looking at the structure of the whole manual, though, I see that most of it
>> is in fact a tutorial on how to use the preprocessor language, like you
>> would find in a C programming book.  Is this a useful thing for us to be
>> providing?  Offhand I am not sure how up-to-date this material is or how
>> much of a maintenance burden it is, but it seems peculiar to be providing
>> such extensive introductory material on the preprocessor when we don't do
>> that for the C or C++ languages; we assume that people already know how to
>> program.
>> I'm wondering if it would be better to toss the tutorial and merge the
>> remaining useful/non-duplicate information about the preprocessor into the
>> main GCC manual.  I think the key things to cover are:
>> * Any GNU extensions to the preprocessor language
>> * Predefined macros
>> * Any pragmas not already documented in the GCC manual
>> * Any command-line options not already documented in the GCC manual
>> * Any implementation-defined behavior or implementation limits not
>>   already documented in the GCC manual
> Makes sense to me.
> The tutorial parts could always be moved to the wiki (the place where
> documentation goes to die ;-) if they're worth having at all.

I have found the CPP manual to be a useful reference on occasion - I
don't know of any better online pre-processor reference, and like many
people in these "paperless" times I don't have a decent C reference book
on hand.

I would agree that it makes sense to move the gcc specific stuff over to
the main gcc manual.  But please keep the CPP manual around - the wiki
would be fine.  If you remove the bits that might change, such as
pragmas, gcc-specific predefined macros, etc., then it is unlikely that
it will need any maintenance in the future.

>> On a related topic....  do we really need to retain implementations of
>> -traditional-cpp and the documented "obsolete features" (assertions)? It
>> seems especially weird to retain support for -traditional-cpp given that
>> support for pre-ANSI C was removed from the compiler proper at least a dozen
>> years ago.
> As Janne said, I think that's to support uses of the preprocessor that
> are separate from the compiler, i.e. not for C or C++ code.

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