| Dan Gohman | f17a25c | 2007-07-18 16:29:46 +0000 | [diff] [blame^] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" |
| 2 | "http://www.w3.org/TR/html4/strict.dtd"> |
| 3 | <html> |
| 4 | <head> |
| 5 | <link rel="stylesheet" href="llvm.css" type="text/css"> |
| 6 | <title>A Few Coding Standards</title> |
| 7 | </head> |
| 8 | <body> |
| 9 | |
| 10 | <div class="doc_title"> |
| 11 | A Few Coding Standards |
| 12 | </div> |
| 13 | |
| 14 | <ol> |
| 15 | <li><a href="#introduction">Introduction</a></li> |
| 16 | <li><a href="#mechanicalissues">Mechanical Source Issues</a> |
| 17 | <ol> |
| 18 | <li><a href="#sourceformating">Source Code Formatting</a> |
| 19 | <ol> |
| 20 | <li><a href="#scf_commenting">Commenting</a></li> |
| 21 | <li><a href="#scf_commentformat">Comment Formatting</a></li> |
| 22 | <li><a href="#scf_includes"><tt>#include</tt> Style</a></li> |
| 23 | <li><a href="#scf_codewidth">Source Code Width</a></li> |
| 24 | <li><a href="#scf_spacestabs">Use Spaces Instead of Tabs</a></li> |
| 25 | <li><a href="#scf_indentation">Indent Code Consistently</a></li> |
| 26 | </ol></li> |
| 27 | <li><a href="#compilerissues">Compiler Issues</a> |
| 28 | <ol> |
| 29 | <li><a href="#ci_warningerrors">Treat Compiler Warnings Like |
| 30 | Errors</a></li> |
| 31 | <li><a href="#ci_portable_code">Write Portable Code</a></li> |
| 32 | <li><a href="#ci_class_struct">Use of class/struct Keywords</a></li> |
| 33 | </ol></li> |
| 34 | </ol></li> |
| 35 | <li><a href="#styleissues">Style Issues</a> |
| 36 | <ol> |
| 37 | <li><a href="#macro">The High Level Issues</a> |
| 38 | <ol> |
| 39 | <li><a href="#hl_module">A Public Header File <b>is</b> a |
| 40 | Module</a></li> |
| 41 | <li><a href="#hl_dontinclude">#include as Little as Possible</a></li> |
| 42 | <li><a href="#hl_privateheaders">Keep "internal" Headers |
| 43 | Private</a></li> |
| 44 | <li><a href="#ll_iostream"><tt>#include <iostream></tt> is |
| 45 | <em>forbidden</em></a></li> |
| 46 | </ol></li> |
| 47 | <li><a href="#micro">The Low Level Issues</a> |
| 48 | <ol> |
| 49 | <li><a href="#ll_assert">Assert Liberally</a></li> |
| 50 | <li><a href="#ll_ns_std">Do not use 'using namespace std'</a></li> |
| 51 | <li><a href="#ll_virtual_anch">Provide a virtual method anchor for |
| 52 | classes in headers</a></li> |
| 53 | <li><a href="#ll_preincrement">Prefer Preincrement</a></li> |
| 54 | <li><a href="#ll_avoidendl">Avoid <tt>std::endl</tt></a></li> |
| 55 | </ol></li> |
| 56 | </ol></li> |
| 57 | <li><a href="#seealso">See Also</a></li> |
| 58 | </ol> |
| 59 | |
| 60 | <div class="doc_author"> |
| 61 | <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> and |
| 62 | <a href="mailto:void@nondot.org">Bill Wendling</a></p> |
| 63 | </div> |
| 64 | |
| 65 | |
| 66 | <!-- *********************************************************************** --> |
| 67 | <div class="doc_section"> |
| 68 | <a name="introduction">Introduction</a> |
| 69 | </div> |
| 70 | <!-- *********************************************************************** --> |
| 71 | |
| 72 | <div class="doc_text"> |
| 73 | |
| 74 | <p>This document attempts to describe a few coding standards that are being used |
| 75 | in the LLVM source tree. Although no coding standards should be regarded as |
| 76 | absolute requirements to be followed in all instances, coding standards can be |
| 77 | useful.</p> |
| 78 | |
| 79 | <p>This document intentionally does not prescribe fixed standards for religious |
| 80 | issues such as brace placement and space usage. For issues like this, follow |
| 81 | the golden rule:</p> |
| 82 | |
| 83 | <blockquote> |
| 84 | |
| 85 | <p><b><a name="goldenrule">If you are adding a significant body of source to a |
| 86 | project, feel free to use whatever style you are most comfortable with. If you |
| 87 | are extending, enhancing, or bug fixing already implemented code, use the style |
| 88 | that is already being used so that the source is uniform and easy to |
| 89 | follow.</a></b></p> |
| 90 | |
| 91 | </blockquote> |
| 92 | |
| 93 | <p>The ultimate goal of these guidelines is the increase readability and |
| 94 | maintainability of our common source base. If you have suggestions for topics to |
| 95 | be included, please mail them to <a |
| 96 | href="mailto:sabre@nondot.org">Chris</a>.</p> |
| 97 | |
| 98 | </div> |
| 99 | |
| 100 | <!-- *********************************************************************** --> |
| 101 | <div class="doc_section"> |
| 102 | <a name="mechanicalissues">Mechanical Source Issues</a> |
| 103 | </div> |
| 104 | <!-- *********************************************************************** --> |
| 105 | |
| 106 | <!-- ======================================================================= --> |
| 107 | <div class="doc_subsection"> |
| 108 | <a name="sourceformating">Source Code Formatting</a> |
| 109 | </div> |
| 110 | |
| 111 | <!-- _______________________________________________________________________ --> |
| 112 | <div class="doc_subsubsection"> |
| 113 | <a name="scf_commenting">Commenting</a> |
| 114 | </div> |
| 115 | |
| 116 | <div class="doc_text"> |
| 117 | |
| 118 | <p>Comments are one critical part of readability and maintainability. Everyone |
| 119 | knows they should comment, so should you. Although we all should probably |
| 120 | comment our code more than we do, there are a few very critical places that |
| 121 | documentation is very useful:</p> |
| 122 | |
| 123 | <b>File Headers</b> |
| 124 | |
| 125 | <p>Every source file should have a header on it that describes the basic |
| 126 | purpose of the file. If a file does not have a header, it should not be |
| 127 | checked into Subversion. Most source trees will probably have a standard |
| 128 | file header format. The standard format for the LLVM source tree looks like |
| 129 | this:</p> |
| 130 | |
| 131 | <div class="doc_code"> |
| 132 | <pre> |
| 133 | //===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===// |
| 134 | // |
| 135 | // The LLVM Compiler Infrastructure |
| 136 | // |
| 137 | // This file was developed by <whoever started the file> and is distributed under |
| 138 | // the University of Illinois Open Source License. See LICENSE.TXT for details. |
| 139 | // |
| 140 | //===----------------------------------------------------------------------===// |
| 141 | // |
| 142 | // This file contains the declaration of the Instruction class, which is the |
| 143 | // base class for all of the VM instructions. |
| 144 | // |
| 145 | //===----------------------------------------------------------------------===// |
| 146 | </pre> |
| 147 | </div> |
| 148 | |
| 149 | <p>A few things to note about this particular format: The 'developed by' line |
| 150 | should be the name of the person or organization who initially contributed the |
| 151 | file. The "<tt>-*- C++ |
| 152 | -*-</tt>" string on the first line is there to tell Emacs that the source file |
| 153 | is a C++ file, not a C file (Emacs assumes .h files are C files by default). |
| 154 | Note that this tag is not necessary in .cpp files. The name of the file is also |
| 155 | on the first line, along with a very short description of the purpose of the |
| 156 | file. This is important when printing out code and flipping though lots of |
| 157 | pages.</p> |
| 158 | |
| 159 | <p>The next section in the file is a concise note that defines the license that |
| 160 | the file is released under. This makes it perfectly clear what terms the source |
| 161 | code can be distributed under.</p> |
| 162 | |
| 163 | <p>The main body of the description does not have to be very long in most cases. |
| 164 | Here it's only two lines. If an algorithm is being implemented or something |
| 165 | tricky is going on, a reference to the paper where it is published should be |
| 166 | included, as well as any notes or "gotchas" in the code to watch out for.</p> |
| 167 | |
| 168 | <b>Class overviews</b> |
| 169 | |
| 170 | <p>Classes are one fundamental part of a good object oriented design. As such, |
| 171 | a class definition should have a comment block that explains what the class is |
| 172 | used for... if it's not obvious. If it's so completely obvious your grandma |
| 173 | could figure it out, it's probably safe to leave it out. Naming classes |
| 174 | something sane goes a long ways towards avoiding writing documentation.</p> |
| 175 | |
| 176 | |
| 177 | <b>Method information</b> |
| 178 | |
| 179 | <p>Methods defined in a class (as well as any global functions) should also be |
| 180 | documented properly. A quick note about what it does any a description of the |
| 181 | borderline behaviour is all that is necessary here (unless something |
| 182 | particularly tricky or insideous is going on). The hope is that people can |
| 183 | figure out how to use your interfaces without reading the code itself... that is |
| 184 | the goal metric.</p> |
| 185 | |
| 186 | <p>Good things to talk about here are what happens when something unexpected |
| 187 | happens: does the method return null? Abort? Format your hard disk?</p> |
| 188 | |
| 189 | </div> |
| 190 | |
| 191 | <!-- _______________________________________________________________________ --> |
| 192 | <div class="doc_subsubsection"> |
| 193 | <a name="scf_commentformat">Comment Formatting</a> |
| 194 | </div> |
| 195 | |
| 196 | <div class="doc_text"> |
| 197 | |
| 198 | <p>In general, prefer C++ style (<tt>//</tt>) comments. They take less space, |
| 199 | require less typing, don't have nesting problems, etc. There are a few cases |
| 200 | when it is useful to use C style (<tt>/* */</tt>) comments however:</p> |
| 201 | |
| 202 | <ol> |
| 203 | <li>When writing a C code: Obviously if you are writing C code, use C style |
| 204 | comments.</li> |
| 205 | <li>When writing a header file that may be <tt>#include</tt>d by a C source |
| 206 | file.</li> |
| 207 | <li>When writing a source file that is used by a tool that only accepts C |
| 208 | style comments.</li> |
| 209 | </ol> |
| 210 | |
| 211 | <p>To comment out a large block of code, use <tt>#if 0</tt> and <tt>#endif</tt>. |
| 212 | These nest properly and are better behaved in general than C style comments.</p> |
| 213 | |
| 214 | </div> |
| 215 | |
| 216 | <!-- _______________________________________________________________________ --> |
| 217 | <div class="doc_subsubsection"> |
| 218 | <a name="scf_includes"><tt>#include</tt> Style</a> |
| 219 | </div> |
| 220 | |
| 221 | <div class="doc_text"> |
| 222 | |
| 223 | <p>Immediately after the <a href="#scf_commenting">header file comment</a> (and |
| 224 | include guards if working on a header file), the <a |
| 225 | href="#hl_dontinclude">minimal</a> list of <tt>#include</tt>s required by the |
| 226 | file should be listed. We prefer these <tt>#include</tt>s to be listed in this |
| 227 | order:</p> |
| 228 | |
| 229 | <ol> |
| 230 | <li><a href="#mmheader">Main Module header</a></li> |
| 231 | <li><a href="#hl_privateheaders">Local/Private Headers</a></li> |
| 232 | <li><tt>llvm/*</tt></li> |
| 233 | <li><tt>llvm/Analysis/*</tt></li> |
| 234 | <li><tt>llvm/Assembly/*</tt></li> |
| 235 | <li><tt>llvm/Bytecode/*</tt></li> |
| 236 | <li><tt>llvm/CodeGen/*</tt></li> |
| 237 | <li>...</li> |
| 238 | <li><tt>Support/*</tt></li> |
| 239 | <li><tt>Config/*</tt></li> |
| 240 | <li>System <tt>#includes</tt></li> |
| 241 | </ol> |
| 242 | |
| 243 | <p>... and each catagory should be sorted by name.</p> |
| 244 | |
| 245 | <p><a name="mmheader">The "Main Module Header"</a> file applies to .cpp file |
| 246 | which implement an interface defined by a .h file. This <tt>#include</tt> |
| 247 | should always be included <b>first</b> regardless of where it lives on the file |
| 248 | system. By including a header file first in the .cpp files that implement the |
| 249 | interfaces, we ensure that the header does not have any hidden dependencies |
| 250 | which are not explicitly #included in the header, but should be. It is also a |
| 251 | form of documentation in the .cpp file to indicate where the interfaces it |
| 252 | implements are defined.</p> |
| 253 | |
| 254 | </div> |
| 255 | |
| 256 | <!-- _______________________________________________________________________ --> |
| 257 | <div class="doc_subsubsection"> |
| 258 | <a name="scf_codewidth">Source Code Width</a> |
| 259 | </div> |
| 260 | |
| 261 | <div class="doc_text"> |
| 262 | |
| 263 | <p>Write your code to fit within 80 columns of text. This helps those of us who |
| 264 | like to print out code and look at your code in an xterm without resizing |
| 265 | it.</p> |
| 266 | |
| 267 | </div> |
| 268 | |
| 269 | <!-- _______________________________________________________________________ --> |
| 270 | <div class="doc_subsubsection"> |
| 271 | <a name="scf_spacestabs">Use Spaces Instead of Tabs</a> |
| 272 | </div> |
| 273 | |
| 274 | <div class="doc_text"> |
| 275 | |
| 276 | <p>In all cases, prefer spaces to tabs in source files. People have different |
| 277 | prefered indentation levels, and different styles of indentation that they |
| 278 | like... this is fine. What isn't is that different editors/viewers expand tabs |
| 279 | out to different tab stops. This can cause your code to look completely |
| 280 | unreadable, and it is not worth dealing with.</p> |
| 281 | |
| 282 | <p>As always, follow the <a href="#goldenrule">Golden Rule</a> above: follow the |
| 283 | style of existing code if your are modifying and extending it. If you like four |
| 284 | spaces of indentation, <b>DO NOT</b> do that in the middle of a chunk of code |
| 285 | with two spaces of indentation. Also, do not reindent a whole source file: it |
| 286 | makes for incredible diffs that are absolutely worthless.</p> |
| 287 | |
| 288 | </div> |
| 289 | |
| 290 | <!-- _______________________________________________________________________ --> |
| 291 | <div class="doc_subsubsection"> |
| 292 | <a name="scf_indentation">Indent Code Consistently</a> |
| 293 | </div> |
| 294 | |
| 295 | <div class="doc_text"> |
| 296 | |
| 297 | <p>Okay, your first year of programming you were told that indentation is |
| 298 | important. If you didn't believe and internalize this then, now is the time. |
| 299 | Just do it.</p> |
| 300 | |
| 301 | </div> |
| 302 | |
| 303 | |
| 304 | <!-- ======================================================================= --> |
| 305 | <div class="doc_subsection"> |
| 306 | <a name="compilerissues">Compiler Issues</a> |
| 307 | </div> |
| 308 | |
| 309 | |
| 310 | <!-- _______________________________________________________________________ --> |
| 311 | <div class="doc_subsubsection"> |
| 312 | <a name="ci_warningerrors">Treat Compiler Warnings Like Errors</a> |
| 313 | </div> |
| 314 | |
| 315 | <div class="doc_text"> |
| 316 | |
| 317 | <p>If your code has compiler warnings in it, something is wrong: you aren't |
| 318 | casting values correctly, your have "questionable" constructs in your code, or |
| 319 | you are doing something legitimately wrong. Compiler warnings can cover up |
| 320 | legitimate errors in output and make dealing with a translation unit |
| 321 | difficult.</p> |
| 322 | |
| 323 | <p>It is not possible to prevent all warnings from all compilers, nor is it |
| 324 | desirable. Instead, pick a standard compiler (like <tt>gcc</tt>) that provides |
| 325 | a good thorough set of warnings, and stick to them. At least in the case of |
| 326 | <tt>gcc</tt>, it is possible to work around any spurious errors by changing the |
| 327 | syntax of the code slightly. For example, an warning that annoys me occurs when |
| 328 | I write code like this:</p> |
| 329 | |
| 330 | <div class="doc_code"> |
| 331 | <pre> |
| 332 | if (V = getValue()) { |
| 333 | ... |
| 334 | } |
| 335 | </pre> |
| 336 | </div> |
| 337 | |
| 338 | <p><tt>gcc</tt> will warn me that I probably want to use the <tt>==</tt> |
| 339 | operator, and that I probably mistyped it. In most cases, I haven't, and I |
| 340 | really don't want the spurious errors. To fix this particular problem, I |
| 341 | rewrite the code like this:</p> |
| 342 | |
| 343 | <div class="doc_code"> |
| 344 | <pre> |
| 345 | if ((V = getValue())) { |
| 346 | ... |
| 347 | } |
| 348 | </pre> |
| 349 | </div> |
| 350 | |
| 351 | <p>...which shuts <tt>gcc</tt> up. Any <tt>gcc</tt> warning that annoys you can |
| 352 | be fixed by massaging the code appropriately.</p> |
| 353 | |
| 354 | <p>These are the <tt>gcc</tt> warnings that I prefer to enable: <tt>-Wall |
| 355 | -Winline -W -Wwrite-strings -Wno-unused</tt></p> |
| 356 | |
| 357 | </div> |
| 358 | |
| 359 | <!-- _______________________________________________________________________ --> |
| 360 | <div class="doc_subsubsection"> |
| 361 | <a name="ci_portable_code">Write Portable Code</a> |
| 362 | </div> |
| 363 | |
| 364 | <div class="doc_text"> |
| 365 | |
| 366 | <p>In almost all cases, it is possible and within reason to write completely |
| 367 | portable code. If there are cases where it isn't possible to write portable |
| 368 | code, isolate it behind a well defined (and well documented) interface.</p> |
| 369 | |
| 370 | <p>In practice, this means that you shouldn't assume much about the host |
| 371 | compiler, including its support for "high tech" features like partial |
| 372 | specialization of templates. In fact, Visual C++ 6 could be an important target |
| 373 | for our work in the future, and we don't want to have to rewrite all of our code |
| 374 | to support it.</p> |
| 375 | |
| 376 | </div> |
| 377 | |
| 378 | <!-- _______________________________________________________________________ --> |
| 379 | <div class="doc_subsubsection"> |
| 380 | <a name="ci_class_struct">Use of <tt>class</tt> and <tt>struct</tt> Keywords</a> |
| 381 | </div> |
| 382 | <div class="doc_text"> |
| 383 | |
| 384 | <p>In C++, the <tt>class</tt> and <tt>struct</tt> keywords can be used almost |
| 385 | interchangeably. The only difference is when they are used to declare a class: |
| 386 | <tt>class</tt> makes all members private by default while <tt>struct</tt> makes |
| 387 | all members public by default.</p> |
| 388 | |
| 389 | <p>Unfortunately, not all compilers follow the rules and some will generate |
| 390 | different symbols based on whether <tt>class</tt> or <tt>struct</tt> was used to |
| 391 | declare the symbol. This can lead to problems at link time.</p> |
| 392 | |
| 393 | <p>So, the rule for LLVM is to always use the <tt>class</tt> keyword, unless |
| 394 | <b>all</b> members are public, in which case <tt>struct</tt> is allowed.</p> |
| 395 | |
| 396 | </div> |
| 397 | |
| 398 | <!-- *********************************************************************** --> |
| 399 | <div class="doc_section"> |
| 400 | <a name="styleissues">Style Issues</a> |
| 401 | </div> |
| 402 | <!-- *********************************************************************** --> |
| 403 | |
| 404 | |
| 405 | <!-- ======================================================================= --> |
| 406 | <div class="doc_subsection"> |
| 407 | <a name="macro">The High Level Issues</a> |
| 408 | </div> |
| 409 | |
| 410 | |
| 411 | <!-- _______________________________________________________________________ --> |
| 412 | <div class="doc_subsubsection"> |
| 413 | <a name="hl_module">A Public Header File <b>is</b> a Module</a> |
| 414 | </div> |
| 415 | |
| 416 | <div class="doc_text"> |
| 417 | |
| 418 | <p>C++ doesn't do too well in the modularity department. There is no real |
| 419 | encapsulation or data hiding (unless you use expensive protocol classes), but it |
| 420 | is what we have to work with. When you write a public header file (in the LLVM |
| 421 | source tree, they live in the top level "include" directory), you are defining a |
| 422 | module of functionality.</p> |
| 423 | |
| 424 | <p>Ideally, modules should be completely independent of each other, and their |
| 425 | header files should only include the absolute minimum number of headers |
| 426 | possible. A module is not just a class, a function, or a namespace: <a |
| 427 | href="http://www.cuj.com/articles/2000/0002/0002c/0002c.htm">it's a collection |
| 428 | of these</a> that defines an interface. This interface may be several |
| 429 | functions, classes or data structures, but the important issue is how they work |
| 430 | together.</p> |
| 431 | |
| 432 | <p>In general, a module should be implemented with one or more <tt>.cpp</tt> |
| 433 | files. Each of these <tt>.cpp</tt> files should include the header that defines |
| 434 | their interface first. This ensure that all of the dependences of the module |
| 435 | header have been properly added to the module header itself, and are not |
| 436 | implicit. System headers should be included after user headers for a |
| 437 | translation unit.</p> |
| 438 | |
| 439 | </div> |
| 440 | |
| 441 | <!-- _______________________________________________________________________ --> |
| 442 | <div class="doc_subsubsection"> |
| 443 | <a name="hl_dontinclude"><tt>#include</tt> as Little as Possible</a> |
| 444 | </div> |
| 445 | |
| 446 | <div class="doc_text"> |
| 447 | |
| 448 | <p><tt>#include</tt> hurts compile time performance. Don't do it unless you |
| 449 | have to, especially in header files.</p> |
| 450 | |
| 451 | <p>But wait, sometimes you need to have the definition of a class to use it, or |
| 452 | to inherit from it. In these cases go ahead and <tt>#include</tt> that header |
| 453 | file. Be aware however that there are many cases where you don't need to have |
| 454 | the full definition of a class. If you are using a pointer or reference to a |
| 455 | class, you don't need the header file. If you are simply returning a class |
| 456 | instance from a prototyped function or method, you don't need it. In fact, for |
| 457 | most cases, you simply don't need the definition of a class... and not |
| 458 | <tt>#include</tt>'ing speeds up compilation.</p> |
| 459 | |
| 460 | <p>It is easy to try to go too overboard on this recommendation, however. You |
| 461 | <b>must</b> include all of the header files that you are using -- you can |
| 462 | include them either directly |
| 463 | or indirectly (through another header file). To make sure that you don't |
| 464 | accidently forget to include a header file in your module header, make sure to |
| 465 | include your module header <b>first</b> in the implementation file (as mentioned |
| 466 | above). This way there won't be any hidden dependencies that you'll find out |
| 467 | about later...</p> |
| 468 | |
| 469 | </div> |
| 470 | |
| 471 | <!-- _______________________________________________________________________ --> |
| 472 | <div class="doc_subsubsection"> |
| 473 | <a name="hl_privateheaders">Keep "internal" Headers Private</a> |
| 474 | </div> |
| 475 | |
| 476 | <div class="doc_text"> |
| 477 | |
| 478 | <p>Many modules have a complex implementation that causes them to use more than |
| 479 | one implementation (<tt>.cpp</tt>) file. It is often tempting to put the |
| 480 | internal communication interface (helper classes, extra functions, etc) in the |
| 481 | public module header file. Don't do this.</p> |
| 482 | |
| 483 | <p>If you really need to do something like this, put a private header file in |
| 484 | the same directory as the source files, and include it locally. This ensures |
| 485 | that your private interface remains private and undisturbed by outsiders.</p> |
| 486 | |
| 487 | <p>Note however, that it's okay to put extra implementation methods a public |
| 488 | class itself... just make them private (or protected), and all is well.</p> |
| 489 | |
| 490 | </div> |
| 491 | |
| 492 | <!-- _______________________________________________________________________ --> |
| 493 | <div class="doc_subsubsection"> |
| 494 | <a name="ll_iostream"><tt>#include <iostream></tt> is forbidden</a> |
| 495 | </div> |
| 496 | |
| 497 | <div class="doc_text"> |
| 498 | |
| 499 | <p>The use of <tt>#include <iostream></tt> in library files is |
| 500 | hereby <b><em>forbidden</em></b>. The primary reason for doing this is to |
| 501 | support clients using LLVM libraries as part of larger systems. In particular, |
| 502 | we statically link LLVM into some dynamic libraries. Even if LLVM isn't used, |
| 503 | the static c'tors are run whenever an application start up that uses the dynamic |
| 504 | library. There are two problems with this:</p> |
| 505 | |
| 506 | <ol> |
| 507 | <li>The time to run the static c'tors impacts startup time of |
| 508 | applications—a critical time for gui apps.</li> |
| 509 | <li>The static c'tors cause the app to pull many extra pages of memory off the |
| 510 | disk: both the code for the static c'tors in each .o file and the small |
| 511 | amount of data that gets touched. In addition, touched/dirty pages put |
| 512 | more pressure on the VM system on low-memory machines.</li> |
| 513 | </ol> |
| 514 | |
| 515 | <table align="center"> |
| 516 | <tbody> |
| 517 | <tr> |
| 518 | <th>Old Way</th> |
| 519 | <th>New Way</th> |
| 520 | </tr> |
| 521 | <tr> |
| 522 | <td align="left"><pre>#include <iostream></pre></td> |
| 523 | <td align="left"><pre>#include "llvm/Support/Streams.h"</pre></td> |
| 524 | </tr> |
| 525 | <tr> |
| 526 | <td align="left"><pre>DEBUG(std::cerr << ...); |
| 527 | DEBUG(dump(std::cerr));</pre></td> |
| 528 | <td align="left"><pre>DOUT << ...; |
| 529 | dump(DOUT);</pre></td> |
| 530 | </tr> |
| 531 | <tr> |
| 532 | <td align="left"><pre>std::cerr << "Hello world\n";</pre></td> |
| 533 | <td align="left"><pre>llvm::cerr << "Hello world\n";</pre></td> |
| 534 | </tr> |
| 535 | <tr> |
| 536 | <td align="left"><pre>std::cout << "Hello world\n";</pre></td> |
| 537 | <td align="left"><pre>llvm::cout << "Hello world\n";</pre></td> |
| 538 | </tr> |
| 539 | <tr> |
| 540 | <td align="left"><pre>std::cin >> Var;</pre></td> |
| 541 | <td align="left"><pre>llvm::cin >> Var;</pre></td> |
| 542 | </tr> |
| 543 | <tr> |
| 544 | <td align="left"><pre>std::ostream</pre></td> |
| 545 | <td align="left"><pre>llvm::OStream</pre></td> |
| 546 | </tr> |
| 547 | <tr> |
| 548 | <td align="left"><pre>std::istream</pre></td> |
| 549 | <td align="left"><pre>llvm::IStream</pre></td> |
| 550 | </tr> |
| 551 | <tr> |
| 552 | <td align="left"><pre>std::stringstream</pre></td> |
| 553 | <td align="left"><pre>llvm::StringStream</pre></td> |
| 554 | </tr> |
| 555 | <tr> |
| 556 | <td align="left"><pre>void print(std::ostream &Out); |
| 557 | // ... |
| 558 | print(std::cerr);</pre></td> |
| 559 | <td align="left"><pre>void print(std::ostream &Out); |
| 560 | void print(std::ostream *Out) { if (Out) print(*Out) } |
| 561 | // ... |
| 562 | print(llvm::cerr);</pre> |
| 563 | |
| 564 | <ul><i>N.B.</i> The second <tt>print</tt> method is called by the <tt>print</tt> |
| 565 | expression. It prevents the execution of the first <tt>print</tt> method if the |
| 566 | stream is <tt>cnull</tt>.</ul></td> |
| 567 | </tbody> |
| 568 | </table> |
| 569 | |
| 570 | </div> |
| 571 | |
| 572 | |
| 573 | <!-- ======================================================================= --> |
| 574 | <div class="doc_subsection"> |
| 575 | <a name="micro">The Low Level Issues</a> |
| 576 | </div> |
| 577 | |
| 578 | |
| 579 | <!-- _______________________________________________________________________ --> |
| 580 | <div class="doc_subsubsection"> |
| 581 | <a name="ll_assert">Assert Liberally</a> |
| 582 | </div> |
| 583 | |
| 584 | <div class="doc_text"> |
| 585 | |
| 586 | <p>Use the "<tt>assert</tt>" function to its fullest. Check all of your |
| 587 | preconditions and assumptions, you never know when a bug (not neccesarily even |
| 588 | yours) might be caught early by an assertion, which reduces debugging time |
| 589 | dramatically. The "<tt><cassert></tt>" header file is probably already |
| 590 | included by the header files you are using, so it doesn't cost anything to use |
| 591 | it.</p> |
| 592 | |
| 593 | <p>To further assist with debugging, make sure to put some kind of error message |
| 594 | in the assertion statement (which is printed if the assertion is tripped). This |
| 595 | helps the poor debugging make sense of why an assertion is being made and |
| 596 | enforced, and hopefully what to do about it. Here is one complete example:</p> |
| 597 | |
| 598 | <div class="doc_code"> |
| 599 | <pre> |
| 600 | inline Value *getOperand(unsigned i) { |
| 601 | assert(i < Operands.size() && "getOperand() out of range!"); |
| 602 | return Operands[i]; |
| 603 | } |
| 604 | </pre> |
| 605 | </div> |
| 606 | |
| 607 | <p>Here are some examples:</p> |
| 608 | |
| 609 | <div class="doc_code"> |
| 610 | <pre> |
| 611 | assert(Ty->isPointerType() && "Can't allocate a non pointer type!"); |
| 612 | |
| 613 | assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!"); |
| 614 | |
| 615 | assert(idx < getNumSuccessors() && "Successor # out of range!"); |
| 616 | |
| 617 | assert(V1.getType() == V2.getType() && "Constant types must be identical!"); |
| 618 | |
| 619 | assert(isa<PHINode>(Succ->front()) && "Only works on PHId BBs!"); |
| 620 | </pre> |
| 621 | </div> |
| 622 | |
| 623 | <p>You get the idea...</p> |
| 624 | |
| 625 | </div> |
| 626 | |
| 627 | <!-- _______________________________________________________________________ --> |
| 628 | <div class="doc_subsubsection"> |
| 629 | <a name="ll_ns_std">Do not use '<tt>using namespace std</tt>'</a> |
| 630 | </div> |
| 631 | |
| 632 | <div class="doc_text"> |
| 633 | <p>In LLVM, we prefer to explicitly prefix all identifiers from the standard |
| 634 | namespace with an "<tt>std::</tt>" prefix, rather than rely on |
| 635 | "<tt>using namespace std;</tt>".</p> |
| 636 | |
| 637 | <p> In header files, adding a '<tt>using namespace XXX</tt>' directive pollutes |
| 638 | the namespace of any source file that includes the header. This is clearly a |
| 639 | bad thing.</p> |
| 640 | |
| 641 | <p>In implementation files (e.g. .cpp files), the rule is more of a stylistic |
| 642 | rule, but is still important. Basically, using explicit namespace prefixes |
| 643 | makes the code <b>clearer</b>, because it is immediately obvious what facilities |
| 644 | are being used and where they are coming from, and <b>more portable</b>, because |
| 645 | namespace clashes cannot occur between LLVM code and other namespaces. The |
| 646 | portability rule is important because different standard library implementations |
| 647 | expose different symbols (potentially ones they shouldn't), and future revisions |
| 648 | to the C++ standard will add more symbols to the <tt>std</tt> namespace. As |
| 649 | such, we never use '<tt>using namespace std;</tt>' in LLVM.</p> |
| 650 | |
| 651 | <p>The exception to the general rule (i.e. it's not an exception for |
| 652 | the <tt>std</tt> namespace) is for implementation files. For example, all of |
| 653 | the code in the LLVM project implements code that lives in the 'llvm' namespace. |
| 654 | As such, it is ok, and actually clearer, for the .cpp files to have a '<tt>using |
| 655 | namespace llvm</tt>' directive at their top, after the <tt>#include</tt>s. The |
| 656 | general form of this rule is that any .cpp file that implements code in any |
| 657 | namespace may use that namespace (and its parents'), but should not use any |
| 658 | others.</p> |
| 659 | |
| 660 | </div> |
| 661 | |
| 662 | <!-- _______________________________________________________________________ --> |
| 663 | <div class="doc_subsubsection"> |
| 664 | <a name="ll_virtual_anch">Provide a virtual method anchor for classes |
| 665 | in headers</a> |
| 666 | </div> |
| 667 | |
| 668 | <div class="doc_text"> |
| 669 | |
| 670 | <p>If a class is defined in a header file and has a v-table (either it has |
| 671 | virtual methods or it derives from classes with virtual methods), it must |
| 672 | always have at least one out-of-line virtual method in the class. Without |
| 673 | this, the compiler will copy the vtable and RTTI into every .o file that |
| 674 | #includes the header, bloating .o file sizes and increasing link times. |
| 675 | </p> |
| 676 | |
| 677 | </div> |
| 678 | |
| 679 | |
| 680 | <!-- _______________________________________________________________________ --> |
| 681 | <div class="doc_subsubsection"> |
| 682 | <a name="ll_preincrement">Prefer Preincrement</a> |
| 683 | </div> |
| 684 | |
| 685 | <div class="doc_text"> |
| 686 | |
| 687 | <p>Hard fast rule: Preincrement (<tt>++X</tt>) may be no slower than |
| 688 | postincrement (<tt>X++</tt>) and could very well be a lot faster than it. Use |
| 689 | preincrementation whenever possible.</p> |
| 690 | |
| 691 | <p>The semantics of postincrement include making a copy of the value being |
| 692 | incremented, returning it, and then preincrementing the "work value". For |
| 693 | primitive types, this isn't a big deal... but for iterators, it can be a huge |
| 694 | issue (for example, some iterators contains stack and set objects in them... |
| 695 | copying an iterator could invoke the copy ctor's of these as well). In general, |
| 696 | get in the habit of always using preincrement, and you won't have a problem.</p> |
| 697 | |
| 698 | </div> |
| 699 | |
| 700 | <!-- _______________________________________________________________________ --> |
| 701 | <div class="doc_subsubsection"> |
| 702 | <a name="ll_avoidendl">Avoid <tt>std::endl</tt></a> |
| 703 | </div> |
| 704 | |
| 705 | <div class="doc_text"> |
| 706 | |
| 707 | <p>The <tt>std::endl</tt> modifier, when used with iostreams outputs a newline |
| 708 | to the output stream specified. In addition to doing this, however, it also |
| 709 | flushes the output stream. In other words, these are equivalent:</p> |
| 710 | |
| 711 | <div class="doc_code"> |
| 712 | <pre> |
| 713 | std::cout << std::endl; |
| 714 | std::cout << '\n' << std::flush; |
| 715 | </pre> |
| 716 | </div> |
| 717 | |
| 718 | <p>Most of the time, you probably have no reason to flush the output stream, so |
| 719 | it's better to use a literal <tt>'\n'</tt>.</p> |
| 720 | |
| 721 | </div> |
| 722 | |
| 723 | |
| 724 | <!-- *********************************************************************** --> |
| 725 | <div class="doc_section"> |
| 726 | <a name="seealso">See Also</a> |
| 727 | </div> |
| 728 | <!-- *********************************************************************** --> |
| 729 | |
| 730 | <div class="doc_text"> |
| 731 | |
| 732 | <p>A lot of these comments and recommendations have been culled for other |
| 733 | sources. Two particularly important books for our work are:</p> |
| 734 | |
| 735 | <ol> |
| 736 | |
| 737 | <li><a href="http://www.aw-bc.com/catalog/academic/product/0,1144,0201310155,00.html">Effective |
| 738 | C++</a> by Scott Meyers. There is an online version of the book (only some |
| 739 | chapters though) <a |
| 740 | href="http://www.awlonline.com/cseng/meyerscddemo/">available as well</a>. Also |
| 741 | interesting and useful are "More Effective C++" and "Effective STL" by the same |
| 742 | author.</li> |
| 743 | |
| 744 | <li><a href="http://cseng.aw.com/book/0,3828,0201633620,00.html">Large-Scale C++ |
| 745 | Software Design</a> by John Lakos</li> |
| 746 | |
| 747 | </ol> |
| 748 | |
| 749 | <p>If you get some free time, and you haven't read them: do so, you might learn |
| 750 | something.</p> |
| 751 | |
| 752 | </div> |
| 753 | |
| 754 | <!-- *********************************************************************** --> |
| 755 | |
| 756 | <hr> |
| 757 | <address> |
| 758 | <a href="http://jigsaw.w3.org/css-validator/check/referer"><img |
| 759 | src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a> |
| 760 | <a href="http://validator.w3.org/check/referer"><img |
| 761 | src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a> |
| 762 | |
| 763 | <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> |
| 764 | <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br> |
| 765 | Last modified: $Date$ |
| 766 | </address> |
| 767 | |
| 768 | </body> |
| 769 | </html> |