<li><a href="#ll_assert">Assert Liberally</a></li>
<li><a href="#ll_ns_std">Do not use 'using namespace std'</a></li>
<li><a href="#ll_virtual_anch">Provide a virtual method anchor for
- clases in headers</a></li>
+ classes in headers</a></li>
<li><a href="#ll_preincrement">Prefer Preincrement</a></li>
<li><a href="#ll_avoidendl">Avoid <tt>std::endl</tt></a></li>
</ol></li>
<b>File Headers</b>
-<p>Every source file should have a header on it that
-describes the basic purpose of the file. If a file does not have a header, it
-should not be checked into CVS. Most source trees will probably have a standard
+<p>Every source file should have a header on it that describes the basic
+purpose of the file. If a file does not have a header, it should not be
+checked into Subversion. Most source trees will probably have a standard
file header format. The standard format for the LLVM source tree looks like
this:</p>
//
// The LLVM Compiler Infrastructure
//
-// This file was developed by the LLVM research group and is distributed under
-// the University of Illinois Open Source License. See LICENSE.TXT for details.
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
file. This is important when printing out code and flipping though lots of
pages.</p>
-<p>The next section in the file is a concise note that defines the license that
-the file is released under. This makes it perfectly clear what terms the source
-code can be distributed under.</p>
+<p>The next section in the file is a concise note that defines the license
+that the file is released under. This makes it perfectly clear what terms the
+source code can be distributed under and should not be modified in any way.</p>
<p>The main body of the description does not have to be very long in most cases.
Here it's only two lines. If an algorithm is being implemented or something
<li>System <tt>#includes</tt></li>
</ol>
-<p>... and each catagory should be sorted by name.</p>
+<p>... and each category should be sorted by name.</p>
<p><a name="mmheader">The "Main Module Header"</a> file applies to .cpp file
which implement an interface defined by a .h file. This <tt>#include</tt>
like to print out code and look at your code in an xterm without resizing
it.</p>
+<p>The longer answer is that there must be some limit to the width of the code
+in order to reasonably allow developers to have multiple files side-by-side in
+windows on a modest display. If you are going to pick a width limit, it is
+somewhat arbitrary but you might as well pick something standard. Going with
+90 columns (for example) instead of 80 columns wouldn't add any significant
+value and would be detrimental to printing out code. Also many other projects
+have standardized on 80 columns, so some people have already configured their
+editors for it (vs something else, like 90 columns).</p>
+
+<p>This is one of many contentious issues in coding standards, but is not up
+for debate.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<tt>#include</tt>'ing speeds up compilation.</p>
<p>It is easy to try to go too overboard on this recommendation, however. You
-<b>must</b> include all of the header files that you are using, either directly
+<b>must</b> include all of the header files that you are using -- you can
+include them either directly
or indirectly (through another header file). To make sure that you don't
accidently forget to include a header file in your module header, make sure to
include your module header <b>first</b> in the implementation file (as mentioned
<ol>
<li>The time to run the static c'tors impacts startup time of
- applications—a critical time for gui apps.</li>
+ applications—a critical time for GUI apps.</li>
<li>The static c'tors cause the app to pull many extra pages of memory off the
- disk: both the code for the static c'tors in each .o file and the small
- amount of data that gets touched. In addition, touched/dirty pages put
- more pressure on the VM system on low-memory machines.</li>
+ disk: both the code for the static c'tors in each <tt>.o</tt> file and the
+ small amount of data that gets touched. In addition, touched/dirty pages
+ put more pressure on the VM system on low-memory machines.</li>
</ol>
+<p>Note that using the other stream headers (<tt><sstream></tt> for
+example) is allowed normally, it is just <tt><iostream></tt> that is
+causing problems.</p>
+
+<div align="center">
<table>
<tbody>
<tr>
<td align="left"><pre>#include "llvm/Support/Streams.h"</pre></td>
</tr>
<tr>
- <td align="left"><pre>DEBUG(std::cerr << ...);</pre></td>
- <td align="left"><pre>DOUT << ...;</pre></td>
+ <td align="left"><pre>DEBUG(std::cerr << ...);
+DEBUG(dump(std::cerr));</pre></td>
+ <td align="left"><pre>DOUT << ...;
+DEBUG(dump(DOUT));</pre></td>
</tr>
<tr>
<td align="left"><pre>std::cerr << "Hello world\n";</pre></td>
<td align="left"><pre>std::stringstream</pre></td>
<td align="left"><pre>llvm::StringStream</pre></td>
</tr>
- </tbody>
-</table>
+ <tr>
+ <td align="left"><pre>void print(std::ostream &Out);
+// ...
+print(std::cerr);</pre></td>
+ <td align="left"><pre>void print(llvm::OStream Out);<sup>1</sup>
+// ...
+print(llvm::cerr);</pre>
+
+</td> </tbody> </table>
+</div>
+
+<div class="doc_text">
+<p><sup>1</sup><tt>llvm::OStream</tt> is a light-weight class so it should never
+be passed by reference. This is important because in some configurations,
+<tt>DOUT</tt> is an rvalue.</p>
+</div>
</div>
<p>You get the idea...</p>
+<p>Please be aware when adding assert statements that not all compilers are aware of
+the semantics of the assert. In some places, asserts are used to indicate a piece of
+code that should not be reached. These are typically of the form:</p>
+
+<div class="doc_code">
+<pre>
+assert(0 && "Some helpful error message");
+</pre>
+</div>
+
+<p>When used in a function that returns a value, they should be followed with a return
+statement and a comment indicating that this line is never reached. This will prevent
+a compiler which is unable to deduce that the assert statement never returns from
+generating a warning.</p>
+
+<div class="doc_code">
+<pre>
+assert(0 && "Some helpful error message");
+// Not reached
+return 0;
+</pre>
+</div>
+
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
- <a name="ll_ns_std">Do not use 'using namespace std'</a>
+ <a name="ll_ns_std">Do not use '<tt>using namespace std</tt>'</a>
</div>
<div class="doc_text">
<p>In LLVM, we prefer to explicitly prefix all identifiers from the standard
-namespace with an "std::" prefix, rather than rely on "using namespace std;".
-</p>
-
-<p> In header files, adding a 'using namespace XXX' directive pollutes the
-namespace of any source file that includes the header. This is clearly a bad
-thing.</p>
-
-<p>In implementation files (e.g. .cpp files) the rule is more of a stylistic
-rule, but is still important. Basically, using explicit namespace prefixes
-makes
-the code <b>more clear</b> - because it is immediately obvious what facilities
-are being used and where they are coming from - and <b>more portable</b> -
-because namespace clashes cannot occur between LLVM code and other namespaces.
-The portability rule is important because different standard library
-implementations expose different symbols (potentially ones they shouldn't) and
-future revisions to the C++ standard will add more symbols to the std
-namespace. As such, we never 'using namespace std;' in LLVM.</p>
-
-<p>The exception to the general rule (i.e. it's not an exception for the std
-namespace) is for implementation files. For example, all of the code in the
-LLVM project implements code that lives in the 'llvm' namespace. As such, it
-is ok, and actually more clear, for the .cpp files to have a 'using namespace
-llvm' directive at their top, after the #includes. The general form of this
-rule is that any .cpp file that implements code in any namespace may use that
-namespace (and its parents), but should not use any others.</p>
+namespace with an "<tt>std::</tt>" prefix, rather than rely on
+"<tt>using namespace std;</tt>".</p>
+
+<p> In header files, adding a '<tt>using namespace XXX</tt>' directive pollutes
+the namespace of any source file that includes the header. This is clearly a
+bad thing.</p>
+
+<p>In implementation files (e.g. .cpp files), the rule is more of a stylistic
+rule, but is still important. Basically, using explicit namespace prefixes
+makes the code <b>clearer</b>, because it is immediately obvious what facilities
+are being used and where they are coming from, and <b>more portable</b>, because
+namespace clashes cannot occur between LLVM code and other namespaces. The
+portability rule is important because different standard library implementations
+expose different symbols (potentially ones they shouldn't), and future revisions
+to the C++ standard will add more symbols to the <tt>std</tt> namespace. As
+such, we never use '<tt>using namespace std;</tt>' in LLVM.</p>
+
+<p>The exception to the general rule (i.e. it's not an exception for
+the <tt>std</tt> namespace) is for implementation files. For example, all of
+the code in the LLVM project implements code that lives in the 'llvm' namespace.
+As such, it is ok, and actually clearer, for the .cpp files to have a '<tt>using
+namespace llvm</tt>' directive at their top, after the <tt>#include</tt>s. The
+general form of this rule is that any .cpp file that implements code in any
+namespace may use that namespace (and its parents'), but should not use any
+others.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
- <a name="ll_virtual_anch">Provide a virtual method anchor for clases in headers</a>
+ <a name="ll_virtual_anch">Provide a virtual method anchor for classes
+ in headers</a>
</div>
<div class="doc_text">
<ol>
-<li><a href="http://www.aw-bc.com/catalog/academic/product/0,1144,0201310155,00.html">Effective
-C++</a> by Scott Meyers. There is an online version of the book (only some
-chapters though) <a
-href="http://www.awlonline.com/cseng/meyerscddemo/">available as well</a>. Also
+<li><a href="http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876">Effective
+C++</a> by Scott Meyers. Also
interesting and useful are "More Effective C++" and "Effective STL" by the same
author.</li>
-<li><a href="http://cseng.aw.com/book/0,3828,0201633620,00.html">Large-Scale C++
-Software Design</a> by John Lakos</li>
+<li>Large-Scale C++ Software Design by John Lakos</li>
</ol>