Remove unused files: This is the old induction varaible cannonicalization

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

diff --git a/docs/CodingStandards.html b/docs/CodingStandards.html
index eb8235235d5ebe59c85514b44695b20c9ff8106d..8566e670f20b0f150cbb25d6dd1b149167f7cf5c 100644 (file)
--- a/docs/CodingStandards.html
+++ b/docs/CodingStandards.html
@@ -8,7 +8,7 @@
 
 <ol>
   <li><a href="#introduction">Introduction</a>
-  <li><a href="#mechanicalissues">Mechanical Source Issues
+  <li><a href="#mechanicalissues">Mechanical Source Issues</a>
     <ol>
       <li><a href="#sourceformating">Source Code Formatting</a>
        <ol>
@@ -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: Sun Jul  8 19:25:56 CDT 2001
+Last modified: Sun Jan 20 13:01:02 CST 2002
 <!-- hhmts end -->
 </font>
 </body></html>