This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [wwwdocs] Update coding conventions for C++
On 6/27/12, Chiheng Xu <chiheng.xu@gmail.com> wrote:
> On Jun 19, 2012, Lawrence Crowl <crowl@google.com> wrote:
> > <p>Function prototypes for extern functions should only occur in
> > header files. Functions should be ordered within source files to
> > minimize the number of function prototypes, by defining them before
> > @@ -121,13 +208,13 @@
> > necessary, to break mutually recursive cycles.</p>
>
> If you always put entry functions in the bottom of a source file, and
> generically, always put upper layer functions below the lower layer
> functions. Then probably there will be no need for function prototypes
> in a source file.
This text is not a change. I would prefer to not address changes
to it in this patch.
>> +<h4><a name="Namespace_Use">Namespaces</a></h4>
>> +
>> +<p>
>> +Namespaces are encouraged.
>> +All separable libraries should have a unique global namespace.
>> +All individual tools should have a unique global namespace.
>> +Nested include directories names should map to nested namespaces when
>> possible.
>> +</p>
>
> Do all people have a consensus on the use of namespace ?
Well, we really only know about objections, and I have not seen any.
>> +<p>
>> +Header files should have neither <code>using</code> directives
>> +nor namespace-scope <code>using</code> declarations.
>> +</p>
>> +
>> +<p>
>> +There is no alternative to <code>using</code> declarations
>> +in class definitions to manage names within an inheritance hierarchy,
>> +so they are necessarily permitted.
>> +</p>
You must have a draft copy. That second paragraph is not in
the patch.
>> +<h4><a name="Standard_Library">The Standard Library</a></h4>
>> +
>> +<p>
>> +Use of the standard library is permitted.
>> +Note, however, that it is currently not usable with garbage collected
>> data.
>> +</p>
>> +
>> +<p>
>> +For compiler messages, indeed any text that needs i18n,
>> +should continue to use the existing facilities.
>> +</p>
>> +
>> +<p>
>> +For long-term code, at least for now,
>> +we will continue to use <code>printf</code> style I/O
>> +rather than <code><iostream></code> style I/O.
>> +For quick debugging code,
>> +<code><iostream></code> is permitted.
>> +</p>
>
> Is iostream really suitable or necessary for GCC ?
It is sometime suitable and not necessary.
> Have you think about writing another thinner interface, like
> Java's IO stream.
We probably should not implement yet another I/O interface. We
should either use the existing GCC facilities, or use the standard
C/C++ facilities. A third set would increase the learning curve.
--
Lawrence Crowl