Channels ▼

Community Voices

Dr. Dobb's Bloggers

Literate Programming and Code Reuse

July 05, 2009

Back in 1997, Norwegian programmer Sverre Henseth wrote this interesting article for Dr. Dobb's Journal on the concept of "Literate Programming" -- mixing code and documentation in the layout of a program. The concept was originally introduced by Donald Knuth, and  Sverre implemented the Singleton and State patterns to combine a macro processor with literate programming techniques.



Literate Programming and Code Reuse

by Sverre Hendseth
Combinig literate programming with a macro processor yields a powerful reuse mechanism



The term "Literate Programming" describes the concept of mixing code and documentation introduced by Donald Knuth. The original system, "WEB system of structured documentation," was developed to provide the basis for the documentation/implementation of the TeX and MetaFont programs (see Knuth's "Literate Programming," Center for the Study of Language and Information (CSLI) Lecture notes number 27, 1992). WEB consists of two filters working on WEB source code; Tangle extracts compilable Pascal code, while Weave extracts the TeX-based documentation of the program.


In this article, I'll look at ways in which literate programming helps you reorganize the layout of a program. When given the freedom to structure program layout as you wish, you tend to group parts of the code differently than as dictated by the language or compiler. Rather than grouping all public-function declarations of a C++ class together in the public section of the class, for instance, you might group each function declaration with the corresponding function implementation. I'll also examine how some of these new groups of code can be parameterized into reusable macros with the help of a simple macro processor. Specifically, I'll show how the application of design patterns such as Singleton and State from Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma et al. (Addison-Wesley, 1995), can be supported by such macros.


This article is a literate program in itself. The first part (available electronically; see documents and implements a set of reusable macros, while the last part is an example of how these macros are used. Extracted C++ code from the example section of this article is presented in Listings One and Two (listings appear at the end of the article). The tools and techniques described in this article have been used daily at TTS Automation (where I work) for the past year and a half for the development of our offline robot programming systems.


The CLiP System for Literate Programming


The CLiP program (which was developed by E.W. van Ammers and M.R. Kramer and is available at for DOS, VMS, and UNIX) reads any number of ASCII files that have been extracted from documents that contain the program code and documentation (written with a word processor). From these, CLiP (short for "Code from Literate Programming") generates corresponding "source" files. Since CLiP is language independent, source files, make files, scripts/batch files, test data and the like can be generated from the same document(s).


Two terms are central to understanding CLiP:


1. A "stub" is a piece of text (code) copied to the output file. It is enclosed in the document with lines like:



/***  ***/
/*** End of  ***/
2. A "slot" is a special line that can occur inside of any stub. It looks like the opening line of a stub and serves as a placeholder for the stub with the same name. The slot line will be replaced by the contents of this stub in the output file. Both stubs and slots can have option specifiers prefixed with "#". The most important stub option is #file. The file stub has no stub name, but its contents are copied to the specified file:
/*** #file "extract.bat" #comment off ***/<br />rem Run the macro processor <br />clipprep c:\litprog\litprog.txt >tmp.txt<br />rem Run CLiP<br />clp_env . . clp tmp.txt/*** End of File ***/
The #comment option turns on or off comments generated by CLiP. The stub option #quick indicates that the stub is ended by the next blank line rather than the "End of" line. The most frequently used slot option is #multiple (#mult), which allows more than one stub to be substituted for the slot. The #optional (#opt) slot option suppresses the warning if there is no stub to fit in a slot. Stubs can come in any order in the CLiP source file. In a C++ class definition, for example, the member function declaration and its definition can be written in the same section. Alternatively, a data member declaration, its initialization in the constructor, the corresponding statements in the copy constructor and assignment operator, its access functions, and its destruction in the class's destructor can be placed in the same section of the source file. Listing Three is a CLiP source file with the corresponding generated code. When given the freedom to reorganize the layout of a program like this, it becomes apparent that structures -- other than those traditionally thought of as reusable -- repeat themselves. These range from trivialities like source file and class layout via member-variable handling, to complex design patterns like those described in Design Patterns or Jim Coplien's Advanced C++: Programming Styles and Idioms (Addison-Wesley, 1994).

The Macro Preprocessor

To enable reuse of these structures, you need a macro processor. The one I use, CLiPPrep (which is also available electronically), is a filter, expanding macros of the forms:
  • Parameterless macro
  • Macro call with parameters
The macro call will be substituted by the macro's body. A macro parameter in this form may contain any characters except "," and ")". If these characters are needed in the parameter, you must enclose the parameter with named brackets of the form %x{ and %x}, where x can be any letter or digit, or can be omitted. These brackets must be matched and may not contain any closing brackets with the same name. This is a legal macro call:
%OneParameterMacro(%a{<br />This parameter may contain ',' and ')'<br />It also contains three EndOfLines.<br />%a})
One of the predefined macros is DefMacro, which registers a new macro. It takes at least two parameters, the first being the macro name, and the last the macro body. The optional middle parameters are the parameter names of the new macro. These are referenced from the macro body like parameterless macros. Below is a macro that defines the layout of a C++ class declaration. A class has a name and may inherit another class. I assume only public and nonmultiple inheritance to keep the examples simple.
%DefMacro(<strong>Class</strong>,class,baseClass,%{<br />class %class %If(%baseClass,: public %baseClass,){<br />public:<br /> /*** %class public props #mult #opt ***/<br />protected:<br /> /*** %class protected props #mult #opt ***/<br />private:<br /> /*** %class private props #mult #opt ***/<br />};<br />%})
If is a predefined macro that evaluates to one out of two bodies depending on whether or not its first parameter is the empty string. The call %Class(CMyClass,CObject) expands to:
class CMyClass : public CObject {<br />public:<br /> /*** CMyClass public props #mult #opt ***/<br />protected:<br /> /*** CMyClass protected props #mult #opt ***/<br />private:<br /> /*** CMyClass private props #mult #opt ***/<br />};
The class's properties will be filled in by stubs elsewhere in the document.

Reusing the Repeating Structures

Before describing how design patterns are supported, I need to define two more macros. DefineClass defines corresponding header and implementation files for a class, using the previous Class macro for the class declaration itself. It takes the filename base, class name, and base class name as parameters. The header file contains one slot for includes, one for declarations, and the class declaration itself -- everything surrounded by an #ifndef statement. The implementation file includes the corresponding header file and has a slot for its own includes, and a slot for the implementation itself:
%DefMacro(<strong>DefineClass</strong>,file,class,baseClass,%a{<br />%%% <em>Make the header file<br /></em>/*** #file "%file.hpp" #comment off ***/<br />#ifndef INCLUDE_%file<br />#define INCLUDE_%file<br />/*** %class header includes #mult #opt ***/<br />/*** %class declarations #mult #opt ***/<br />%Class(%class,%baseClass)<br />#endif<br />/*** End Of File ***/<br />
%%% <em>Now for the implementation file</em><br />/*** #file "%file.cpp" #comment off ***/<br />#include "%file.hpp"<br />/*** %class implementation includes #mult #opt ***/<br />/*** %class implementation #mult #opt ***/<br />/*** End Of File ***/<br />%a})<br />
The second basic macro is the member function. A member function is contained in a class and has a name, access (public, protected, private), parameters, return value, possibly a type modifier (virtual or static), and body. Again, to keep the example simple, I ignore pure virtual functions, overloading, default values of parameters, const functions, and the like. The macro puts the function declaration into the correct slot in the class declaration, and the function implementation into the implementation file, opening a " actions" slot for the function body:
<blockquote><br /><br />%DefMacro(<strong>Method</strong>,class,scope,typeMod,type,name,pars,<br />%a{<br />%%% <em>Make the prototype <br /></em>/*** %class %scope props ***/<br />%typeMod %type %name (%pars);<br />/*** End of %class %scope props ***/<br />%%% <em>Make the definition</em><br />/*** %class implementation ***/<br />%type<br />%class::%name (%pars){<br /> /*** %class::%name actions #mult #opt ***/<br />}<br />/*** End of %class implementation ***/<br />%a})<br /></blockquote>

The Singleton Pattern

By protecting the constructor and letting all access to the object go through a static member function, the Singleton pattern ensures that there is only one instance of a class created. The following macro adds a private constructor to the class, a private static object pointer to the single instance of the class, and a static public member function Instance() that returns the instance pointer, if necessary, after creating the object.
%DefMacro(<em>MakeSingleton</em>,class,<br />%a{<br />%%% <em>The private constructor</em><br />%Method(%class,private,,,%class,)<br />%%% <em>The static instance pointer</em><br />/*** %class private props ***/<br />static %class * m_instance;<br />/*** End of %class private props ***/<br />%%% <em>...and its definition</em><br />/*** %class implementation ***/<br />%class * %class::m_instance = NULL;<br />/*** End of %class implementation ***/<br />%%% <em>The Instance() function</em><br />%Method(%class,public,static,%class *,Instance,)<br />%%% <em>and its body</em><br />/*** %class::Instance actions ***/<br />if(m_instance == NULL){<br /> m_instance = new %class;<br />}<br />return m_instance;<br />/*** End of %class::Instance actions ***/<br />%a})<br />
This is a simple macro to build; it adds a set of features to an already existing class. Listing Four is the result of the two macro calls, partly evaluated by CLiP:
%DefineClass(mysing,CMySingleton,)<br />%MakeSingleton(CMySingleton) <br />

The Abstract Base Class

When you have several classes that should implement the same interface, or if you want to achieve a proper division between interface and implementation for one class in C++, you define the interface as an abstract base class (ABC) which the implementation classes inherit. I will describe a variant of this structure where the subclasses are declared in the implementation file of the base class; that is, they are completely invisible from the client side. Instances of these classes might, for example, be created through static functions in the abstract base class. This is more a feature of the C++ language than an idiom or design pattern, but it occurs frequently and contains features coded in its layout (the concrete classes are invisible because they are declared in the implementation file). Macros can also help ensure consistency between the base class and concrete classes. Therefore, this structure is a good candidate to implement as a reusable macro. Listing Five presents the layout of the header and implementation file. Four macros describe this structure: 1. ABC(class) prepares the given class as an abstract base class, giving it a virtual destructor and partitioning the implementation file:
%DefMacro(<em>ABC</em>,class,%{<br />%%% <em>The virtual destructor</em><br />%Method(%class,public,virtual,,~%class,)<br />
%%% <em>The slot for the sub-class declarations</em><br />/*** %class implementation ***/<br />/*** %class derived classes #mult #opt ***/<br />/*** %class child implementations #mult #opt ***/<br />/*** End of %class implementation ***/<br />%})<br />
2. ABCMethod(class,returnType,name,parameters) adds the specified method to the interface as a pure virtual function and remembers (defines as macros) the return value and parameters:
%DefMacro(<em>ABCMethod</em>,class,type,name,pars,%{<br />%%% <em>Define the method</em><br />/*** %class public props ***/<br />virtual %type %name (%pars) = 0;<br />/*** End of %class public props ***/<br />%%% <em>Remember the return type and parameters.</em><br />%DefMacro(%name ReturnType,%type)<br />%DefMacro(%name Parameters,%pars)<br />%})<br />
3. ABCDerivedClass(baseClass,class) defines an implementation class inheriting the ABC and defines the slot for its implementation:
%DefMacro(<em>ABCDerivedClass</em>,baseClass,class,%a{<br />%%% <em>The subClass</em><br />/*** %baseClass derived classes ***/<br />%Class(%class,%baseClass)<br />/*** End of %baseClass derived classes ***/<br />
%%% <em>Make the slot for the sub-class implementation</em><br />/*** %baseClass child implementations ***/<br />/*** %class implementation #mult #opt ***/<br />/*** End of %baseClass child implementations ***/<br />%a})<br />
4. ABCDerivedClassMethod(class,name) looks up the stored return value and the parameters of the method and defines them in the class:
%DefMacro(<strong>ABCDerivedClassMethod</strong>,class,name,<br />%x{<br />%Method(%class,public,virtual,<br /> %{%Eval(%% %name ReturnType)%},%name,<br /> %{%Eval(%% %name Parameters)%})<br />%x})<br />
The Eval macro takes one parameter and evaluates it one extra time, and the "%%" constellation evaluates to a single "%". Remember that function bodies, member variables, helper functions, and the like are added to the classes in the normal manner, using the Method macro or writing stubs that fit in the appropriate slots.

The State Pattern

You can organize the state-dependent behavior of a class, (the "context") by forwarding requests for this behavior to a contained instance of a State class. This State class is an abstract base class and the instance variable is changed to point to different implementations for different states. Here, I'll describe a variant of this pattern, where the state objects do not have data members. The context's "this" pointer can, however, be passed with every function call to the state objects so that they can access the context's data if necessary. The concrete state classes are thereby modeled as Singletons. This pattern is divided into two macros: 1. AddState(contextClass,stateId) adds a state variable to the context class and defines the state ABC. It remembers the context class corresponding to the stateId (sId). The state class name is chosen to be the stateId prefixed by "C":
%DefMacro(<strong>AddState</strong>,context,sId,<br />%{<br />%%% <em>Define the State Base Class in the </em><br />%%% <em>implementation file of the context.</em><br />/*** %context implementation ***/<br />%Class(C%sId,)<br />/*** C%sId implementation #mult #opt ***/<br />/*** End of %context implementation ***/<br />%%% <em>Make it an ABC</em><br />%ABC(C%sId)<br />%%% <em>We have to declare it.</em><br />/*** %context Declarations ***/<br />class C%sId;<br />/*** End of %context Declarations ***/<br />
%%% <em>Making the variable</em><br />/*** %context private props ***/<br />C%sId * m_%sId;<br />/*** End of %context private props ***/<br />
%%% <em>Remember the context corresponding to the sId</em><br />%DefMacro(%sId Context,%context)<br />%})<br />
2. DefineState(sId,stateName) defines a class that inherits the state base class. It calls ABCDerivedClass and makes it a Singleton. It is also a friend of the context.
%DefMacro(<strong>DefineState</strong>,sId,name,%a{<br />%ABCDerivedClass(C%sId,%name)<br />%MakeSingleton(%name)<br />/*** %Eval(%% %sId Context) public props ***/<br />friend class %name;<br />/*** End of %Eval(%% %sId Context) public props ***/<br />%a})<br />
The macros ABCMethod and ABCDerivedClassMethod are used to add methods to the interface and to the concrete states.

Using the Macros

Assume that, up to this point, this article is in a separate file and is maintained as a reusable module. The text is included in this section by the macro processor's Include(fileName) macro. The code generated from this part of the article is presented in Listings One and Two. Assume an application comprised of a number of geometric entity classes that know how to draw themselves as wireframes, in terms of functions offered by the CGl class. The entity instances may be ordered hierarchically in that more-primitive or lower-level entities may be a part of a higher-level entity. The CGl class makes the interface to the OpenGL graphics library and implements the functions relating to color control. Consequently, you want the following functionality:
  • If an entity does not set the color before issuing drawing commands, it should be drawn in the current color (that is, the color set by its parent entity).
  • A parent entity should be able to override the color commands of its subobjects.
  • When highlighting an entity, all subentities should also be drawn in the highlight color, overriding their color commands.
  • When doing dummy draws not shown on the screen (picking or collecting statistics, for instance), color commands should be ignored.
The functions PushColor, PopColor, LockColor, and UnlockColor perform these tasks. Each works differently, depending on whether the color is in the state "Locked" or "Normal". I'll start by defining the CGl class, states, and interface functions:
%DefineClass(glclass,CGl,CObject)<br />%%% <em>Add Some Includes</em><br />/*** CGl header includes ***/<br />#include <br />#include <br />#include "ccolor.hpp"<br />/*** End of CGl header includes ***/<br />%%% <em>Add the state variable and the states</em><br />%AddState(CGl,ColorMode)<br />%DefineState(ColorMode,CLocked)<br />%DefineState(ColorMode,CNormal)<br />%%% <em>Then the four methods</em><br />%ABCMethod(CColorMode,void,<strong>PushColor</strong>,%{<br /> CGl * pC,<br /> const CColor & color<br />%})<br />%ABCMethod(CColorMode,void,<strong>PopColor</strong>,CGl * pC)<br />%ABCMethod(CColorMode,void,<strong>LockColor</strong>,CGl * pC)<br />%ABCMethod(CColorMode,void,<strong>UnlockColor</strong>,CGl * pC)<br />
The start state must be set. Since the constructor of CGl is not already defined, you must do that too:
%Method(CGl,public,,<strong>,CGl</strong>,)<br />
/*** CGl::CGl actions #quick ***/<br />m_ColorMode = CNormal::Instance();<br />
Use the following code to keep track of a stack of colors, and the number of times LockColor is called:
/*** CGl private props #quick ***/<br />int lockLevel;<br />CObList colorList; // Used for implementing a stack<br />
PushColor and PopColor do nothing in Locked mode, but must maintain the stack of colors and set the current color in Normal mode:
%ABCDerivedClassMethod(CLocked,PushColor)<br />%ABCDerivedClassMethod(CLocked,PopColor)<br /><br /><br /><br />%ABCDerivedClassMethod(CNormal,PushColor)<br />/*** <strong>CNormal::PushColor</strong> actions #quick ***/<br />pC->colorList.AddHead(new CColor(color));<br />glColor3d(color.R(),color.G(),color.B());<br /><br /><br /><br />%ABCDerivedClassMethod(CNormal,PopColor)<br />/*** <strong>CNormal::PopColor</strong> actions #quick ***/<br />delete pC->colorList.RemoveHead();<br />CColor * pColor = (CColor *) pC->colorList.GetHead();<br />glColor3d(pColor->R(),pColor->G(),pColor->B());<br />
LockColor switches modes and initiates the lockLevel to 1 (if in Normal mode) and increments the lockLevel (if in Locked mode):
%ABCDerivedClassMethod(CNormal,LockColor)<br />/*** CNormal::LockColor actions #quick ***/<br />pC->lockLevel = 1;<br />pC->m_ColorMode = CLocked::Instance();<br />
%ABCDerivedClassMethod(CLocked,LockColor)<br />/*** CLocked::LockColor actions #quick ***/<br />pC->lockLevel++;<br />
UnlockColor should decrement the lockLevel and change mode if it reaches zero while in Locked mode, and assert if in Normal mode:
%ABCDerivedClassMethod(CNormal,UnlockColor)<br />/*** CNormal::UnlockColor actions #quick ***/<br />ASSERT(0);<br /><br /><blockquote><br /><br />%ABCDerivedClassMethod(CLocked,UnlockColor)<br />/*** CLocked::UnlockColor actions #quick ***/<br />pC->lockLevel--;<br />if(pC->lockLevel == 0){<br /> pC->m_ColorMode = CNormal::Instance();<br />}<br /></blockquote>
Now you need to to reflect these functions out to the CGl class:
%Method(CGl,public,,void,<strong>PushColor</strong>,const CColor & c)<br />/*** CGl::PushColor actions #quick ***/<br />m_ColorMode->PushColor(this,c);<br /><br /><br /><br />%Method(CGl,public,,void,<strong>PopColor</strong>,)<br />/*** CGl::PopColor actions #quick ***/<br />m_ColorMode->PopColor(this);<br /><br /><br /><br />%Method(CGl,public,,void,<strong>LockColor</strong>,)<br />/*** CGl::LockColor actions #quick ***/<br />m_ColorMode->LockColor(this);<br /><br /><br /><br />%Method(CGl,public,,void,<strong>UnlockColor</strong>,)<br />/*** CGl::UnlockColor actions #quick ***/<br />m_ColorMode->UnlockColor(this);<br />


Traditional drawbacks to literate programming include:
  • Increased "distance" between the file you are creating and the results of compilation/testing. This is an inconvenience if your programming style includes frequent compilation.
  • Less powerful version control if you save source as a binary file (as with most modern word processors).
  • Loss of IDE features.
Still, you get a system that encourages and enables good source-code documentation and intuitive layout. The concept of combining a macro processor with literate programming is very expressive. For C++, it surpasses the expressiveness of templates. It is also applicable to most other programming languages. Weaknesses are mainly related to the correctness of the extraction. For example, even if you incorrectly name a stub, you may not get a warning, and the resulting modules may still compile. For more information on literate programming, see the comp.programming.literate FAQ at pub/programming/literate-programming and the author's home page at 

Listing One

<a name="l1" title="l1"></a>#ifndef INCLUDE_glclass#define INCLUDE_glclass<br />#include <br />#include <br />#include "ccolor.hpp"<br />class CColorMode;<br /><br /><br /><br /><a name="l1" title="l1"></a>class CGl: public CObject{<br />public:<br />  friend class CLocked;<br />  friend class CNormal;<br />    CGl();<br />   void PushColor(const CColor & c);<br />   void PopColor();<br />   void LockColor();<br />   void UnlockColor();<br />protected:<br />private:<br />  CColorMode * m_ColorMode;<br />  int lockLevel;<br />  CObList colorList; // Used for implementing a stack<br />};<br />#endif<br />

Listing Two

<a name="l2" title="l2"></a>#include "glclass.hpp"<br /><br /><br /><a name="l2" title="l2"></a>class CColorMode{<br />public:<br />  virtual  ~CColorMode();<br />  virtual void PushColor(<br />    CGl * pC,<br />    const CColor & color<br />  ) = 0;<br />  virtual void PopColor(CGl * pC) = 0;<br />  virtual void LockColor(CGl * pC) = 0;<br />  virtual void UnlockColor(CGl * pC) = 0;<br />protected:<br />private:<br />};<br />CColorMode::~CColorMode(){<br />}<br />class CLocked: public CColorMode{<br />public:<br />  static CLocked* Instance();<br />  virtual void PushColor(<br />    CGl * pC,<br />    const CColor & color<br />  );<br />  virtual void PopColor(CGl * pC);<br />  virtual void LockColor(CGl * pC);<br />  virtual void UnlockColor(CGl * pC);<br />protected:<br />private:<br />    CLocked();<br />  static CLocked* m_instance;<br />};<br />class CNormal: public CColorMode{<br />public:<br />  static CNormal* Instance();<br />  virtual void PushColor(<br />    CGl * pC,<br />    const CColor & color<br />  );<br />  virtual void PopColor(CGl * pC);<br />  virtual void LockColor(CGl * pC);<br />  virtual void UnlockColor(CGl * pC);<br />protected:<br />private:<br />    CNormal();<br />  static CNormal* m_instance;<br />};<br />CLocked::CLocked(){<br />}<br />CLocked* CLocked::m_instance = NULL;<br />CLocked*<br />CLocked::Instance(){<br />  if(m_instance == NULL){<br />    m_instance = new CLocked;<br />  }<br />  return m_instance;<br />}<br />void<br />CLocked::PushColor(<br />  CGl * pC,<br />  const CColor & color<br />){<br />}<br />void<br />CLocked::PopColor(CGl * pC){<br />}<br />void<br />CLocked::LockColor(CGl * pC){<br />  pC->lockLevel++;<br />}<br />void<br />CLocked::UnlockColor(CGl * pC){<br />  pC->lockLevel--;<br />  if(pC->lockLevel == 0){<br />    pC->m_ColorMode = CNormal::Instance();<br />  }<br />}<br />CNormal::CNormal(){<br />}<br />CNormal* CNormal::m_instance = NULL;<br />CNormal*<br />CNormal::Instance(){<br />  if(m_instance == NULL){<br />    m_instance = new CNormal;<br />  }<br />  return m_instance;<br />}<br />void<br />CNormal::PushColor(<br />  CGl * pC,<br />  const CColor & color<br />){<br />  pC->colorList.AddHead(new CColor(color));<br />  glColor3d(color.R(),color.G(),color.B());<br />}<br />void<br />CNormal::PopColor(CGl * pC){<br />  delete pC->colorList.RemoveHead();<br />  CColor * pColor = (CColor *) pC->colorList.GetHead();<br />  glColor3d(pColor->R(),pColor->G(),pColor->B());<br />}<br />void<br />CNormal::LockColor(CGl * pC){<br />  pC->lockLevel = 1;<br />  pC->m_ColorMode = CLocked::Instance();<br />}<br />void<br />CNormal::UnlockColor(CGl * pC){<br />  ASSERT(0);<br />}<br />CGl::CGl(){<br />  m_ColorMode = CNormal::Instance();<br />}<br />void<br />CGl::PushColor(const CColor & c){<br />  m_ColorMode->PushColor(this,c);<br />}<br />void<br />CGl::PopColor(){<br />  m_ColorMode->PopColor(this);<br />}<br />void<br />CGl::LockColor(){<br />  m_ColorMode->LockColor(this);<br />}<br />void<br />CGl::UnlockColor(){<br />  m_ColorMode->UnlockColor(this);<br />}<br />

Listing Three


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.