On Mon, 25 Jun 2012, Diego Novillo wrote: > [ Added doc maintainers in CC ] > > While I'm not particularly interested in the details of the coding > conventions, I am interested in getting them in getting them installed > before we merge cxx-conversion to trunk. > > Joseph, Gerald, do we have a process for accepting changes to coding > conventions?
I suggest sending smaller (so easier to review) patches that are concrete and avoid speculation about possible future changes. > > + <a href="#C_Options">Compiler Options</a><br /> I don't like this repeated presentational markup; use appropriate logical markup instead. > > +<p> > > +We will periodically pick a stable version of GCC, > > +and require that that version of GCC be able to build > > +all versions of GCC up to and including the next stable version. > > +E.g., we may decide that all newer versions of GCC > > +should be buildable with GCC 4.3.5. The current version required is more important than speculation about future changes. E.g., say that code must build with GCC 4.1 and later. > > +<h4><a name="Assertions">Assertions</a></h4> > > + > > +<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> I don't think any of this is new - perhaps you could separate rearrangement from the actual changes and C++ conventions? > > +<h4><a name="Calls">Function Calls</a></h4> > > + > > +<p> > > +All current GCC code uses a space between the function name > > +and the left parenthesis in a function call. > > +Essentially all C++ code omits that space, > > +which is more consistent with C++ syntax. > > +For the present we will retain the space. > > +It is possible that in the future we will switch the code with a flag day. > > +</p> Avoid speculation. Avoid duplicating the GNU Coding Standards. Formatting can be assumed to follow the GNU Coding Standards except where they are meaningless for C++ or something explicitly overrides them. > > +<p> > > +Think carefully about the size and performance impact > > +of virtual functions and virtual bases > > +before using them. > > +</p> Explain in more detail what the size and performance impact is for people not familiar with the details of how C++ features are implemented. > > +<p> > > +Indent protection labels by one space. > > +</p> > > + > > +<p> > > +Indent class members by two spaces. Do all the listed indentation rules correspond to what a <TAB> will do by default when editing C++ code in GNU Emacs? If not, we have conflicting notions of GNU C++ indentation conventions. -- Joseph S. Myers jos...@codesourcery.com
