This is the mail archive of the gcc@gcc.gnu.org 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]

Re: PATCH: faq.html (was: "FAQ patch")



> If possible, lines shouldn't be longer than about 75 
> characters, even if your mail client does not wrap long 
> lines.
> 
> Reasons for this include that the mailers of *others* 
> might cause troubles if they produce patches at a later
> time, GNU coding standards, and that it's usually easier
> to read such patches in a mailer. (Of course, there
> are cases, like long URLs or perhaps the TOC of the FAQ
> where this is not feasible, but in general we prefer short
> lines.)

Thank you - that makes it very clear. Nice to have this in the archives now too.


> > 2001-07-03  Rich Churcher  <churcher@ihug.com.au>
> >
> > 	* Add question to cover lack of export keyword
> 
> I'd prefer that we enhance the corresponding item which we
> already have in bugs.html instead. And, if this is indeed 
> a FAQ, just refer that one from the FAQ.

It's perhaps not so much a FAQ to the GCC list (about two or three occurrences 
in the archives that I noticed) as it is to Usenet, where I encounter it a 
great deal in talking with beginners to the language. You're right, it fits 
better in bugs.html. Some related questions:

1. Would you like all three of the other questions in the "bugs and non-bugs" 
section moved out of the FAQ and into bugs.html?

2. In bugs.html I find the use of the definition list (<dl>) to be rather 
difficult to read. May I suggest the following:

  <dl><dt><b>Nested classes can access private types of the
          containing class.</b></dt>
      <dd><blockquote>G++ now implements type access control on
          member types. Defect report 45 clarifies that nested
          classes are members of the class they are nested in,
          and so are granted access to private members of that
          class.</blockquote></dd>
      <dt><b>Classes in exception specifiers must be complete
          types.</b></dt>
      <dd><blockquote>[15.4]/1 tells you that you cannot have
          an incomplete type, or pointer to incomplete (other
          than <code>cv void *</code>) in an exception
          specification.</blockquote></dd>
  </dl>

It takes up more space, but is easier to scan on the page.

3. Still looking at bugs.html, it's quite a long page. I suggest we provide a 
more detailed contents at the top, listing more of the subsections. Any 
objections to this?


> If you agree, could you craft a patch to that end? If not,
> try to convince me (which *is* feasible, I guess). :-)

Wouldn't dream of it :o)  I'll do separate patches for the above issues when I 
get home from work, and let you decide between them.

--
Cheers,
Rich.


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