New testcase for problem effecting mst

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

diff --git a/docs/CodingStandards.html b/docs/CodingStandards.html
index 176f796cf4edb4a5682f51ddf2823bef16c2ad11..8566e670f20b0f150cbb25d6dd1b149167f7cf5c 100644 (file)
--- a/docs/CodingStandards.html
+++ b/docs/CodingStandards.html
@@ -37,6 +37,7 @@
         <ol>
           <li><a href="#hl_assert">Assert Liberally</a>
           <li><a href="#hl_preincrement">Prefer Preincrement</a>
+          <li><a href="#hl_avoidendl">Avoid endl</a>
           <li><a href="#hl_exploitcpp">Exploit C++ to its Fullest</a>
         </ol>
       <li><a href="#iterators">Writing Iterators</a>
@@ -220,9 +221,9 @@ In practice, this means that you shouldn't assume much about the host compiler,
 
 C++ doesn't do too well in the modularity department.  There is no real encapsulation or data hiding (unless you use expensive protocol classes), but it is what we have to work with.  When you write a public header file (in the LLVM source tree, they live in the top level "include" directory), you are defining a module of functionality.<p>
 
-Modules should be completely independent of each other, except for their dependence.  A module is not just a class, a function, or a namespace: <a href="http://www.cuj.com/articles/2000/0002/0002c/0002c.htm">it's a collection of these</a> that defines an interface.  This interface may be several functions, classes or data structures, but the important issues is how they work together.<p>
+Modules should be completely independent of each other, except for their dependence.  A module is not just a class, a function, or a namespace: <a href="http://www.cuj.com/articles/2000/0002/0002c/0002c.htm">it's a collection of these</a> that defines an interface.  This interface may be several functions, classes or data structures, but the important issue is how they work together.<p>
 
-One example of this is the <tt>llvm/include/llvm/CFG.h</tt> file.  It defines a collection of global functions, template classes, and member functions that are syntactically unrelated to each other.  Semantically, however, they all provide useful functionality for operating on a CFG, and so they are bound together.<p>
+<!--One example of this is the <tt>llvm/include/llvm/CFG.h</tt> file.  It defines a collection of global functions, template classes, and member functions that are syntactically unrelated to each other.  Semantically, however, they all provide useful functionality for operating on a CFG, and so they are bound together.<p> -->
 
 In general, a module should be implemented with one or more <tt>.cpp</tt> files.  Each of these <tt>.cpp</tt> files should include the header that defines their interface first.  This ensure that all of the dependences of the module header have been properly added to the module header itself, and are not implicit.  System headers should be included after user headers for a translation unit.<p>
 
@@ -262,7 +263,7 @@ To further assist with debugging, make sure to put some kind of error message in
 
 <pre>
   inline Value *getOperand(unsigned i) { 
-    assert(i < Operands.size() && "getOperand() out of range!");
+    assert(i &lt; Operands.size() && "getOperand() out of range!");
     return Operands[i]; 
   }
 </pre>
@@ -270,15 +271,15 @@ To further assist with debugging, make sure to put some kind of error message in
 Here are some examples:
 
 <pre>
-  assert(Ty->isPointerType() && "Can't allocate a non pointer type!");
+  assert(Ty-&gt;isPointerType() && "Can't allocate a non pointer type!");
 
   assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!");
 
-  assert(idx < getNumSuccessors() && "Successor # out of range!");
+  assert(idx &lt; getNumSuccessors() && "Successor # out of range!");
 
   assert(V1.getType() == V2.getType() && "Constant types must be identical!");
 
-  assert(Succ->front()->isPHINode() && "Only works on PHId BBs!");
+  assert(isa&lt;PHINode&gt;(Succ-&gt;front()) && "Only works on PHId BBs!");
 </pre><p>
 
 You get the idea...<p>
@@ -292,6 +293,19 @@ Hard fast rule: Preincrement (++X) may be no slower than postincrement (X++) and
 The semantics of postincrement include making a copy of the value being incremented, returning it, and then preincrementing the "work value".  For primitive types, this isn't a big deal... but for iterators, it can be a huge issue (for example, some iterators contains stack and set objects in them... copying an iterator could invoke the copy ctor's of these as well).  In general, get in the habit of always using preincrement, and you won't have a problem.<p>
 
 
+<!-- _______________________________________________________________________ -->
+</ul><a name="hl_avoidendl"><h4><hr size=0>Avoid endl</h4><ul>
+
+The <tt>endl</tt> modifier, when used with iostreams outputs a newline to the output stream specified.  In addition to doing this, however, it also flushes the output stream.  In other words, these are equivalent:<p>
+
+<pre>
+  cout << endl;
+  cout << "\n" << flush;
+</pre>
+
+Most of the time, you probably have no reason to flush the output stream, so it's better to use a literal <tt>"\n"</tt>.<p>
+
+
 <!-- _______________________________________________________________________ -->
 </ul><a name="hl_exploitcpp"><h4><hr size=0>Exploit C++ to its Fullest</h4><ul>
 
@@ -646,7 +660,7 @@ If you get some free time, and you haven't read them: do so, you might learn som
 <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
 <!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
 <!-- hhmts start -->
-Last modified: Mon Jul 23 15:40:22 CDT 2001
+Last modified: Sun Jan 20 13:01:02 CST 2002
 <!-- hhmts end -->
 </font>
 </body></html>