This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: faq.html (was: "FAQ patch")
- To: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Subject: Re: PATCH: faq.html (was: "FAQ patch")
- From: churcher at ihug dot com dot au
- Date: Thu, 5 Jul 2001 01:45:22 GMT
- Cc: gcc at gcc dot gnu dot org
> 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.