This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [wwwdocs] Update coding conventions for C++


On 6/26/12, Martin Jambor <mjambor@suse.cz> wrote:
> On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
> > > I have no idea.  I don't use emacs.  The two-space rule for
> > > members comes from the wiki.  The one-space rule for protection
> > > labels is common practice.  If folks want something else,
> > > changes are fine with me.
>
> I'll also need an emacs C++ indentation style that conforms to
> this in order to really be able to produce complying code myself.
> So if anybody else will be working on that, I'm interested (to
> use it and perhaps help crafting it) and I guess a number of
> other people on this list are too...

Alternatively, one could change the conventions to match an emacs
style.  Either is fine we me, as long as the style is reasonable.

> > -<h2>Miscellaneous Conventions</h2>
> > -
> > -<p>Code should use <code>gcc_assert(EXPR)</code> to check invariants.
> > -Use <code>gcc_unreachable()</code> to mark places that should never be
> > -reachable (such as an unreachable <code>default</code> case of a
> > -switch).  Do not use <code>gcc_assert(0)</code> for such purposes, as
> > -<code>gcc_unreachable</code> gives the compiler more information.  The
> > -assertions are enabled unless explicitly configured off with
> > -<code>--enable-checking=none</code>.  Do not use <code>abort</code>.
> > -User input should never be validated by either <code>gcc_assert</code>
> > -or <code>gcc_unreachable</code>.  If the checks are expensive or the
> > -compiler can reasonably carry on after the error, they may be
> > -conditioned on <code>--enable-checking</code>.</p>
>
> It seems we should mention gcc_checking_assert here then.

Jason had a suggestion, and I used that.

> > +<p>
> > +Single inheritance is permitted.
> > +Use public inheritance to describe interface inheritance,
> > +i.e. 'is-a' relationships.
> > +Use private and protected inheritance
> > +to describe implementation inheritance.
> > +Implementation inheritance can be expediant,

> s/expediant/expedient/

Fixed.

> > +but think twice before using it in code
> > +intended to last a long time.
>
> I think all committed code should be expected to have long-lasting
> quality.  I would not encourage people to think otherwise and would
> drop the "long time" reference here.  If anybody ever commits
> something ugly to bridge a short time period, it should only be done
> under the "maintainers grant exceptions" rule anyway.
>
> > +</p>> +<p>
> > +For long-term code, at least for now,
> > +we will continue to use <code>printf</code> style I/O
> > +rather than <code>&lt;iostream&gt;</code> style I/O.
> > +For quick debugging code,
> > +<code>&lt;iostream&gt;</code> is permitted.
> > +</p>
>
> Similarly here, no quick and dirty debugging output should ever be
> committed, we should not
>
> > +<h4><a name="stdlib">The Standard Library</a></h4>
> > +
> > +<p>
> > +At present, C++ provides no great advantage for i18n.
> > +GCC does type checking for <code>printf</code> arguments,
> > +so the type insecurity of <code>printf</code> is moot,
> > +but the clarity in layout persists.
> > +For quick debugging output, &lt;iostream&gt; requires less work.
> > +</p>
>
> The same applies here.

The value of these changes depends on when the rules are enforced.
If they are enforced only on trunk, then the changes seem fine
to me.  However, if they are enforced on branches, then they could
unnecessarily slow down development.

Comments?

-- 
Lawrence Crowl


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