Add a const qualifier.

[oota-llvm.git] / docs / CodingStandards.html

diff --git a/docs/CodingStandards.html b/docs/CodingStandards.html
index 2fe3bdc9e2bbb1073b9dcf254d1b861a7179a5da..7815e19739f30854872e8501f3aacb22628937e1 100644 (file)
--- a/docs/CodingStandards.html
+++ b/docs/CodingStandards.html
@@ -194,9 +194,9 @@ something sane goes a long ways towards avoiding writing documentation.</p>
 <b>Method information</b>
 
 <p>Methods defined in a class (as well as any global functions) should also be
-documented properly.  A quick note about what it does any a description of the
+documented properly.  A quick note about what it does and a description of the
 borderline behaviour is all that is necessary here (unless something
-particularly tricky or insideous is going on).  The hope is that people can
+particularly tricky or insidious is going on).  The hope is that people can
 figure out how to use your interfaces without reading the code itself... that is
 the goal metric.</p>
 
@@ -303,7 +303,7 @@ for debate.</p>
 <div class="doc_text">
 
 <p>In all cases, prefer spaces to tabs in source files.  People have different
-prefered indentation levels, and different styles of indentation that they
+preferred indentation levels, and different styles of indentation that they
 like... this is fine.  What isn't is that different editors/viewers expand tabs
 out to different tab stops.  This can cause your code to look completely
 unreadable, and it is not worth dealing with.</p>
@@ -419,7 +419,8 @@ different symbols based on whether <tt>class</tt> or <tt>struct</tt> was used to
 declare the symbol.  This can lead to problems at link time.</p> 
 
 <p>So, the rule for LLVM is to always use the <tt>class</tt> keyword, unless
-<b>all</b> members are public, in which case <tt>struct</tt> is allowed.</p>
+<b>all</b> members are public and the type is a C++ "POD" type, in which case 
+<tt>struct</tt> is allowed.</p>
 
 </div>
 
@@ -490,7 +491,7 @@ most cases, you simply don't need the definition of a class... and not
 <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
+accidentally 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
 above).  This way there won't be any hidden dependencies that you'll find out
 about later...</p>
@@ -789,7 +790,7 @@ locality.</p>
 <div class="doc_text">
 
 <p>Use the "<tt>assert</tt>" function to its fullest.  Check all of your
-preconditions and assumptions, you never know when a bug (not neccesarily even
+preconditions and assumptions, you never know when a bug (not necessarily even
 yours) might be caught early by an assertion, which reduces debugging time
 dramatically.  The "<tt>&lt;cassert&gt;</tt>" header file is probably already
 included by the header files you are using, so it doesn't cost anything to use
@@ -989,12 +990,14 @@ library. There are two problems with this:</p>
 </ol>
 
 <p>Note that using the other stream headers (<tt>&lt;sstream&gt;</tt> for
-example) is allowed normally, it is just <tt>&lt;iostream&gt;</tt> that is
-causing problems.</p>
-
-<p>In addition, new code should always
-use <a href="#ll_raw_ostream"><tt>raw_ostream</tt></a> or
-the <tt>llvm::MemoryBuffer</tt> API (for reading in files).</p>
+example) is not problematic in this regard (just <tt>&lt;iostream&gt;</tt>).
+However, raw_ostream provides various APIs that are better performing for almost
+every use than std::ostream style APIs, so you should just use it for new
+code.</p>
+
+<p><b>New code should always
+use <a href="#ll_raw_ostream"><tt>raw_ostream</tt></a> for writing, or
+the <tt>llvm::MemoryBuffer</tt> API for reading files.</b></p>
 
 </div>