Hi, 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... Furthermore, even though this mainly reminds me how little I actually know about C++, I have a few general tiny comments: > -<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. ... > +<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/ > +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><iostream></code> style I/O. > +For quick debugging code, > +<code><iostream></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, <iostream> requires less work. > +</p> The same applies here. Thanks, Martin > + > +<h3>Formatting Conventions</h3> > + > +<h4><a href="names">Names</a></h4> > + > +<p> > +Naming data members with a trailing underscore > +highlights the extra overhead of access to fields over local variables. > +Think of the trailing underscore > +like you would Pascal's postfix <code>^</code> dereference operator. > +</p> > + > +<p> > +When using the above convention, > +the constructor parameter names > +and getter member function names > +can use the more concise non-underscore form. > +</p> > + > +</body> > +</html> > > -- > Lawrence Crowl
