Nicollet.Net

One cannot provide a function pointer as a template argument. This means that cases in which polymorphism is desirable for compile-time reasons (such as using one set of operations when testing and another set of operations when running the code), or where the behavior of code depends on a compile-time element and should be able to evolve in an open-closed fashion, cannot be handled by passing the correct function pointer.

Of course, a common trick in template metaprogramming is to replace entities which cannot be used as parameters (such as non-integer values) with types that have the entities as static members.

template <typename T>
void Frobnicate(int value) { T::Process(value); } 

struct Print
{ static void Process(int value) { std::cout << value; } }; 

struct Ignore
{ static void Process(int) {} }; 

Frobnicate<Print>(10);
Frobnicate<Ignore>(10);

As long as the structure that contains the function has external linkage (that is, it’s not defined inside a function) this will work and inject the correct kind of behavior into the function template at compile-time, possibly also performing any required inlining.

A typical application of this approach is, as mentioned earlier, unit testing: when working with rendering-related or input-related objects, it’s useful to replace their primitives with mocks that can test if the calls performed were those expected. This replacement can be done with runtime polymorphism (using an interface for the primitives, with a real class and a mock class boh implementing it) but leads to unnecessary performance loss (the overhead of runtime polymorphism that is not really required outside of the unit testing scenario). Using compile-time polymorphism based on templates, unit testing works, but the runtime code is still as optimised as if no unit testing ever happened.

Flow is a lightweight C++ inter-thread flow library, built on top of the boost::thread library. It allows dispatch of parts of a complex computation process to one or more additional threads, in a transparent and idiomatic way. It has been written in early 2008 by me (Victor Nicollet), and it is available under the terms of the new BSD license.

The flow library implements thread-safe FIFO queues (flows), and provides facilities for manipulating them that are compatible with the Standard C++ Library.

Downloads

Using this library requires Boost.Threads and Boost.Optional to be installed and available to the program. To use the elements defined in the flow library, one only has to include the header file flow.hpp: since all code is templated, there is no need for separate compiling and linking.

• flow.hpp : include this file to use any entity in the library.
• prime.cpp : a naive prime number test using several cores.
• sort.cpp : a constant-time sort using an auxiliary thread.

Concepts

A flow is a FIFO queue where enqueueing and dequeueing are atomic. The type flows::flow<T> represents a flow of elements of type T.

Flows are manipulated through readers and writers, which are objects used to read from and write to the flow. Reading will remove the oldest element from the flow, while writing will append a new element to the flow, in a FIFO fashion. Attempting to read from an empty flow will block until another thread writes to the flow. Readers are represented by class flows::reader<T>, and writers are represented by class flows::writer<T>.

When all writers of a flow disappear, the flow is closed: all the readers are notified that no more data will be appended to the flow, triggering an end-of-flow state once all the remaining elements have been removed from the flow.

When all readers of a flow disappear, the flow is silent: all the writers are notified that nobody will ever read the data written to the flow, providing opportunities for optimization.

When all readers and writers of a flow disappear, that flow is automatically garbage-collected and is destroyed by the thread that destroyed the last reader or writer (along with all the elements it still contained).

Documentation

class flows::reader<T>

This class represents a reader, which may be associated to a flow (valid reader), or not be associated to any flow (invalid reader). The class itself can be summarized as:

template <typename T>
class reader
{
public:
  typedef T                  value_type;
  typedef boost::optional<T> option_type;
  typedef /* unspecified */  iterator; 

  iterator    begin();
  iterator    end();
              reader();
              reader(const reader&);
  reader&     operator =(const reader&);
  void        close();
  option_type get();
};

The default constructor creates an invalid reader. A valid reader can only be obtained from flows::flow<T>. Assigning to a reader dissociates that reader from its flow (if any), which may lead to that flow being silenced or even destroyed if this was the last reader for that flow. Note that flows::reader<T>::close() is equivalent to assigning a default-constructed reader: the reader becomes invalid and detached from its associated flow (if any).

The flows::reader<T>::get() function behaves as follows:

• If the reader is invalid, returns no value.
• If the reader is valid, but the associated flow is closed and empty, returns no value.
• If the reader is valid, but the associated flow is empty, blocks until a value becomes available or the flow is closed, and tries again.
• If the reader is valid and the associated flow is not empty, atomically removes the oldest value and returns it.

As a consequence, if two or more readers are associated to the same flow, every element in the flow will be read by at most one reader (and all elements will be either read by a reader or destroyed along with the flow).

flows::reader<T>::begin() and flows::reader<T>::end() are the first and past-the-end iterators of the read sequence of elements. They are input iterators (in the sense defined by the Standard C++Library) which represent the sequence of elements read by a particular reader:

• Creating an iterator using begin() or incrementing an iterator reads the next value from the flow by calling the flows::reader<T>::get() function on the associated reader. This function call may block until the flow is written to. If it returns a value, then the iterator is bound to that value. Otherwise, the iterator becomes equal to the past-the-end iterator.
• Dereferencing an iterator returns the value bound to the iterator. This is guaranteed to occur in constant time.

Iterators are invalidated on every assignment to the reader.

An analogy for read iterators is the std::istream_iterator, but the data is read from a flow using flows::reader<T>::get(), instead of being read from a stream using operator>>().

class flows::writer<T>

This class represents a writer, which may be associated to a flow (valid writer), or not be associated to any flow (invalid writer). The class can be summarized as:

template <typename T>
class writer
{
  typedef T                 value_type;
  typedef /* unspecified */ iterator; 

  iterator begin();
           writer();
           writer(const writer&);
  writer&  operator =(const writer&);
  void     close();
  bool     silent();
  void     put(const T&);
};

The default constructor creates an invalid writer. The only way to create a valid writer is to use flows::flow<T>. Assigning to a writer dissociates that writer from its flow (if any), and then binds it to the flow of the writer that was assigned to it (if any). This may lead to the flow becoming closed or even garbage-collected. flows::writer<T>::close() is equivalent to (but more idiomatic than) assigning a default-constructed writer.

The flows::writer<T>::put() function atomically writes a copy of its argument to the flow associated to the writer. If there is no associated flow, the behavior of this function is undefined.

The flows::writer<T>::silent() function returns whether the associated flow is silent or not. If there is no associated flow, the behavior of this function is undefined. This is provided as optimization hints to avoid computing values only to place them in a silent flow. It can be used to notify search threads that the one of them has found what was searched. See the above example on prime numbers for an illustration.

The flows::writer<T>::begin() function returns the output iterator for this writer. This iterator behaves as an std::back_insert_iterator, but calls flows::writer<T>::put() on its associated writer instead of calling insert(). This iterator is invalidated by assignment to the writer.

class flows::flow<T>

This class represents an active flow, and allows creating fresh readers and writers associated to that flow. For that reason, for as long as this instance exists, the underlying flow can be neither closed nor silenced (because a new reader or writer could be obtained from it at any time). Therefore, this instance should be used to prepare a computation, and destroyed before the computation starts.

When the instance is destroyed, the flow itself remains in memory for as long as readers or writers are associated to it. Once all readers and writers are gone, the flow is destroyed immediately, destroying any unread data left.

Note that the library provides several functions that dispatch computations to other threads without requiring the explicit creation of a flow from user code. Ideally, flows::flow<T> should only be used in situations where these functions do not meet the needs of the program, and even then it should only be used with care.

The class can be summarized as:

template <typename T> 
class flow
{
  flow(); 

  const writer<T>& input() const;
  const reader<T>& output() const;
};

As expected, flows::flow<T>::input() returns a writer associated to the flow, and flows::flow<T>::output() returns a reader associated to the flow. Unlike the naming approach of the C++ Standard Library, where an input stream is a reader and an output stream is a writer, the input of a flow is the writer (where the flow gets its input) and the output of a flow is the reader (where the flow sends its input).

Generators

A generator is a separate thread that computes values and outputs them to a flow. The original thread keeps a reader associated to that flow, and may read values from the flow as they become available.

Two functions allow the creation of generators:

template <typename T, typename F>
reader<T> generate(F f); 

template <typename T, typename F, typename I>
reader<T> generate(F f, I b, I e);

The first function creates a new flow and a new thread. Then, in that new thread, it calls f(w) where f is the argument to the generate function, and w is a writer associated to that flow. Simultaneously, it returns a reader associated to the flow in the original thread. The created thread ends when the argument function returns.

The second function creates one new flow, and creates a thread for each iterator i between b and e. Each thread calls f(w,*i), and the function simultaneously returns a reader for the flow. Each created thread ends when its function call returns.

That is, the first function creates a generator, and the second function creates one generator for each iterator in the passed sequence.

Processing

A processor is a thread which reads from a flow, does some computations, and writes to another flow. The most generic way of doing this (by specifying the exact function that reads and writes) is with the flows::process<T>() function:

template<typename T, typename U, typename F>
reader<T> process(const reader<U> &source, F f);

This function creates a new flow and a new thread which runs f(source,dest), where dest is a writer associated to the new flow. It immediately returns a reader associated to the new flow.

A special case of processing is mapping an function to a flow: the processor reads a value, applies a function to it, and writes the result to another flow. Mapping is done using the flows::transform<T>() function:

template <typename T, typename U, typename F>
reader<T> transform(const reader<U> &source, F f, unsigned n = 1);

This function creates n new threads and a single flow, and returns a reader associated to that flow. Every thread reads a value x from the source reader, and writes f(x) to the new flow. Note that if n = 1, the order is preserved, but not if n > 1. The new flow is closed when all the data from the original flow has been processed.

Accumulating

An accumulator is a thread which reads from a flow and applies a binary operation to collapse all the values into a single one, using an initial value for the first application. Once all the data is processed, it writes the final value to an output flow.

Accumulation is performed using the function flows::accumulate<T>() function:

template <typename T, typename U, typename F>
reader<T> accumulate(const reader<U> &source, T initial, F f);

This function creates a flow and thread. The thread performs the operation f(initial,*it) for it between source.begin() and source.end(), then writes initial to the flow. The function returns the reader associated to the flow immediately.

Further work

The implementation could be improved. First, it could be adapted to work with lock-free structures. Second, it could also be adapted to use worker threads instead of spawning new threads for every operation.

The interface could also use some improvement. For instance, it’s still too easy to create deadlocks by forgetting to close a writer in the wrong place. And the code does not interact with the standard library as well as it should.

This entire text was originally part of a post I made on the GameDev.Net forums, which I’ve reformatted slightly. It exposes what is in my opinion a good explanation of what C++ pointers are and what they can be used for, starting with the elementary concepts required to introduce the hellish semantics that they provide. Of course, this article in itself is no match for starting programming with a language that uses reference semantics, but it’s still a good starting point.

Without any more discussion, here is the explanation:

Values

C++ programs manipulate values. Typical values include integers, such as 42, characters, such as ‘x’, objects of more complex types, such as std::string or std::fstream, and also instances of any class you define in your program.

Variables and References

Values need to be manipulated, which involves giving them a name. A reference is a name given to a value. Creating a reference is done like so:

Type & name = value;

Where value is usually the return value of a function or operator…

std::ostream &o = (std::cout << "Text.");

…but might also be another name given to the same value:

std::ostream &o = std::cout;

Another way to create a reference is as a function argument:

void foo(Type & name)

This will cause the value which was passed as argument to be available under that name in the entire function body. This can be quite useful if you wish to modify that value.

Of course, almost any program needs to create values. In C++, values are always created using operator new (except for literals such as 42 or “Hello”, which simply exist). operator new exists in several versions. The default version generates dynamic values, which exist until delete is called:

int & value = * new int;
value = 10;
std::cout << value;
delete (&value);

This causes performance problems if used too often, because dynamic memory allocation is slow in a non-garbage-collected language like C++. This is why another, faster version exists: placement new creates a new value using existing memory. Of course, the lifetime of the value is then limited by the lifetime of the memory which was used to create it, and it must of course be manually destroyed by calling its destructor:

std::string & str = * new (existing_memory) std::string("Hello");
str += " world!";
std::cout << str;
str.~string();
// existing_memory dies somewhere after this line

The existence of placement new allows the programmer to use memory areas which are faster than the free store used by the default operator new: it may use stack memory, a specially reserved portion of global memory, or a subset of the memory used by another value, by increasing speed of allocation. For instance, using stack memory:

 int & value = * new (alloca(sizeof(int))) int;

Since allocating objects on the stack, in global memory or as a subset of an object is a very repetitive task which involves obtaining the memory, computing the size to be allocated, and then calling the destructor of the object right before the memory is gone, the C++ language provides shortcuts to do this. Take for example stack allocation of a string:

void sayhello()
{
  std::string & str = * new (alloca(sizeof(std::string))) std::string("Hello");
  str += " world!";
  std::cout << str;
  str.~string();
}

I have underlined the repetitive tasks that are related to stack allocation. The shortcut provided by C++ in this situation is as follows:

void sayhello()
{
  auto std::string str("Hello");
  str += " world!";
  std::cout << str;
}

The main differences here are the presence of the auto keyword, the absence of the & in the definition of the reference, and the absence of the str.~string() destructor call at the end of the function. The first two differences cause C++ to allocate a new block of memory on the stack (auto) which will be released when the function returns and initialize it with a new value from the string literal “Hello”. The auto keyword also causes the compiler to generate destructor calls: the object will be automatically destroyed right before the function exits (since that is when the stack allocation is released). In this situation auto is aptly named a storage specifier.

The other storage specifier is static, which uses global memory: defining a local variable as static causes the compiler to allocate some memory for it as part of the global data span (at compile-time) and then initialize the value at that spot in memory the first time the variable’s definition is encountered. Since auto is the default storage specifier, it is generally omitted from the definition, which leads to the typical variable definition that most C and C++ programmers are used to:

std::string str("Hello");
str += " world!";
std::cout << str;

Variables at global scope automatically use global storage.

Member variables of structures or classes use the third type of allocation: they use a bit of reserved memory that was part of the value of which they are a member, and they are initialized there as part of that value’s constructor. Their destructor is automatically called as part of the value’s destructor. Before:

struct super
{
  std::string & str;
  some_memory_buffer;
  super() : str(* new (some_memory_buffer) std::string) {}
  ~super() { str.~string(); }
};

After:

struct super
{
  std::string str;
  // No explicit memory buffer
  // Automatic construction
  // Automatic destruction
};

To summarize: references are names given to values. C++ provides special shortcuts to create a value and bind it to a reference at the same time, with special rules about when the created value is to be destroyed.

Iterators and Sequences

A sequence is, as its name hints at, a sequence of values. It could be, for instance, the sequence 1, 2, 3, 4. Or, it could be the set of opponents in a video game, in an arbitrary order. Or, it could be the sequence of characters being read from std::cin. In short, sequences are the fundamental concept used to represent groups of objects that are to be manipulated together.

A typical representation of sequences is through iterators, which are means of iterating over a sequence (accessing its elements in order). The basic operations required to iterate are the ability to read the “current value”, the ability to move on to the “next value”, and the ability to determine if the end of the sequence was reached and there are no values left. For instance, pseudocode to add together values of a sequence through iteration:

a = 0
while not end-of-sequence(iter)
  a += value(iter)
  iter = next(iter)

Various languages provide various forms of iterators, but the three operations outlined above are always present. For instance, Objective Caml uses (it = []), List.hd it and List.tl it as the end-of-sequence, value and next operations. C++ uses it == end, *it and ++it as the end-of-sequence, value and next operations. So, C++ code to add together the values of a sequence (represented by two iterators of type Iter representing the first iterator of the sequence and the first iterator past the sequence) would be:

template<typename Iter>
int sum(Iter begin, Iter end)
{
  int a = 0;
  while (begin != end)
  {
    a += *begin;
    ++begin;
  }
  return a;
}

The begin-end representation of sequences is standard. The end iterator is the first iterator after the sequence: as such, it has no associated value, and trying to obtain the iterator after end is invalid. So, you cannot *end or ++end. You can, however, compare end with another iterator to see if that other iterator has reached the end of the sequence.

The point of using a past-the-end iterator (one that isn’t in the sequence, but is actually right after it) instead of a last-element iterator (one that corresponds to the last element in the sequence) is twofold. First, it makes code less complex, because the condition “I have reached the past-the-end iterator on this iteration” is easier to evaluate than “I was working on the last iterator on the previous iteration”. Second, it allows representation of empty sequences (since the empty sequence has no last element and as such could not be represented using a last-iterator approach).

An iterator which supports only *it and ++it is called a forward iterator. Some iterators also support –it (which moves to the previous element), making it a bidirectional iterator. Some iterators also support it + n and it – n, allowing the iterator to move an arbitrary number of steps backward or forward in a single jump, which is called a random access iterator. Iterators may in turn be read-only (input iterator), write-only (output iterator) or support both read and write.

Iterators are a very powerful concept: most of the things in C++ which look like sequences can be turned into iterators.

• The sequence of elements in a vector is represented by vect.begin() and vect.end(), which are random access read-write iterators (or read-only, if the vector is constant).
• The sequence of elements in a list is represented by list.begin() and list.end(), which are bidirectional read-write iterators (or read-only, if the list is constant).
• The sequence of objects of type T read from an std::istream such as std::cin is represented by std::istream_iterator<T>(std::cin) and std::istream_iterator<T>() (past-the-end iterator) which are forward input iterators.
• Adding a sequence of elements at the end of any non-associative standard library container c is represented by std::back_inserter(c), with no end iterator (this could be an infinite sequence) and is a forward output iterator.

The list goes on and on. This system is then combined with iterator-based algorithms, such as std::copy(src_begin, src_end, dest_begin), where src_begin and src_end are at least forward input iterators representing the input sequence to be copied, and dest_begin is at least a forward output iterator representing where the input sequence should be copied to. As such, reading as many integers as possible from standard input and placing them in a vector is as simple as:

std::vector<int> integers;
std::copy( std::istream_iterator<int>(std::cin),
           std::istream_iterator<int>(),
           std::back_inserter(integers) );

Or, we could add together the values read on the standard input using our function above:

std::cout << sum( std::istream_iterator<int>(std::cin),
                  std::istream_iterator<int>() );

Just like we could add together the elements of a vector:

std::cout << sum( integers.begin(), integers.end() );

Pointers

Pointers are a concept originally introduced in C. From a semantic point of view, pointers are random access read-write iterators. As iterators, they represent sequences of contiguous elements of the same type—such sequences are created either using a vector, or using a block allocation approach such as new[] or arrays.

Given a block of N objects of type T, a pointer representing that sequence is of type T*.

Depending on the nature of the block, obtaining the first pointer begin in the sequence varies.

• T *begin = new T[N]; will directly return the first pointer in the sequence.
• If a is an array of N objects of type T then T *begin = a; will create the first pointer in the sequence of elements of a.

• Otherwise, if t (of type T) is the first element of a sequence (as opposed to the first iterator of a sequence), then T *begin = &t; is the first iterator of the sequence.

The past-the-end iterator of a sequence is simply defined as T *end = begin + N;

int values[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
std::cout << sum(values, values + 10);

As with any other iterator, going beyond the bounds of a sequence (before begin or after end) results in undefined behavior, which will usually lead to random misbehavior of your program.

All of the above also holds when N = 1 (which means that a single object is also a one-object sequence, which can as such be manipulated using a pointer).

The main problem with pointers is that this is not everything. If pointers were merely iterators, then people would have no more trouble with them than they would have with the other iterators in the standard library. However, pointers were introduced in the C language as a means to represent several other concepts.

The first of these concepts is reference semantics. You see, in C, there are no references per se: every time you create a variable, it also creates a value. This makes it difficult to handle dynamic memory (because every variable you create already has its own value, so how do you give your dynamic memory a name in order to use it?) and allow functions to modify a variable in another function (because all the arguments to your function are, by default, brand new values that will disappear when the function returns, and you have no access to the values in the calling function). The solution adopted was to decide that, since pointers are read-write iterators, and every value is a one-element sequence by definition, then pointers can be used to give indirect names to values.

For instance:

 /* Solve aX² + bX + c */
int find_solutions(float a, float b, float c, float *x1, float *x2)
{
  float delta = b * b - 4f * a * c;
  float sq;  

  if (delta < 0f)
    return 0;

  sq = sqrt(delta);
  *x1 = (- b - sq) / (2 * a);
  *x2 = (- b + sq) / (2 * a);
  return 2;
}

Important note: the above is a C function which uses idioms not found or advised in C++ code. The C++ equivalent would use references instead of pointers, and would probably return a boost::optional<std::pair<float,float>> anyway.

This function needs to return the number of solutions (zero or two), but it also needs to send back the values of those solutions. In order to do so, it uses a trick which consists in being given two iterators to one-value sequences and modifying the unique value in each sequence. Since a copy of an iterator of a sequence is a new iterator of that same sequence, the iterator allows the function to modify the original sequence—and the values inside that sequence are the values from within the calling function.

int main()
{
  float x1, x2;
  float *px1 = &x1; // An iterator to the one-element sequence 'x1'
  float *px2 = &x2; // An iterator to the one-element sequence 'x2'  

  find_solutions(1f, 0f, -1f, px1, px2);   

  // The function call changed the contents of the sequences
  // iterated by px1 and px2, namely x1 and x2. As such, the
  // values of x1 and x2 have been changed.
}

Of course, C++ provides references, which is why pointers are not used for pass-by-reference in C++ at all (as references provide a far more simple representation of one-element sequences).

Another use of pointers, which remained in C++, is the representation of reseatable references. In C++, a reference is a name given to a value, and the value is bound to the name forever. It is not possible to bind the name to another value (though it is possible, of course, to bind several names to the same value). Reseating a reference means binding it to another value, and is possible in languages such as C# or Java, but not in C++.

However, pointers are merely iterators, and it’s possible to assign an iterator to another (thereby changing the sequence that the iterator is traversing, or the point in the sequence where the iterator is)—after all, this is the entire point of traversing a sequence with a single iterator!

Therefore, when it becomes useful to have a reference to a value, but the ability to change that value is also useful, people sometimes use a pointer (though, in modern C++, there are other types, such as boost::shared_ptr or boost::weak_ptr, which do a far better job). For instance, if you wish to reference a fighter’s target (and fighters can change targets at will):

struct fighter
{
  object *target;
}

As such, a fighter’s target can be changed by changing the pointer so that it corresponds to another value instead of the original one.

A third use of pointers, introduced in C, was optional semantics. An option type allows the possibility for a value to be absent. For instance, one could decide that sqrt returns a float option: either its argument is positive and it returns a float, or it is negative and then it returns nothing.This is quite similary to the option types found in ML languages, for instance Objective Caml’s ‘a option.

Instead of defining an option type distinct from an iterator type (as C++ does for all its iterators), C merged the two together, and this carried over to C++. A pointer can be constructed from the integer constant zero, and thus becomes the null pointer. This is a compile-time effect: the compiler notices that you’re assigning zero to a pointer, and transforms that integer into the actual value of the null pointer (which may be something entirely different from zero).

The null pointer may not be used in any way (increment, decrement, arithmetic, dereferencing), except to be compared for equality with another pointer, to be assigned a new pointer, or to be tested as a boolean condition (a null pointer always evaluates to false, while other pointers evaluate to true).

To summarize: pointers are bidirectional read-write iterators used in C for reference semantics and reseatable reference semantics, as well as a clunky option type.

What warts are

Warts, in programming jargon, refer to any information appended to a symbol’s name in addition to the core semantic name of that symbol, usually in a highly abbreviated and standardized fashion. Examples of wart-bearing names (with the warts in red) would be lpszName, CUserSocket, g_project_config, author_t, and next_. In themselves, warts are just a way of conveying additional information about a symbol, usually a property such as its kind (class, template, interface), type (long pointer to a string), scope (global or member) or some more specific information (encoding, being a row or column index, and so on).

Warts fall into three major categories:

• Useful, these convey a relevant information that would not be easily conveyed otherwise.
• Useless, these convey some information that can be readily gathered from the name or the usage.
• Useless and dangerous, these convey some information with some negative side-effects on code quality.

Those that are Useful

To be useful, a wart must be small enough to avoid cluttering the name (most people consider the clutter limit to be at most one character long), summarize a piece of information that is not obvious from the context of use (and cannot be made obvious by using the language), and provide a large enough level of understanding that it can severely influence the plans of the programmer.

The canonical example of an useful wart is the “interface” wart, which consists in prepending an uppercase i (for interface) to the name of an interface (or, in C++, an abstract class which serves as an interface). The message conveyed is that the symbol represents a type which provides no functionality, and merely defines a list of methods that must be provided by any subtype. There is a big difference between a function with a signature such as:

void Print(const Formatter &fmt)

And a function with a signature like:

void Print(const IFormatter &fmt)

The first function brings up the idea that an instance of the codebase-provided Formatter class must be created, customized either through constructor arguments or through member functions, and then passed to the function. The second function brings up the idea that one must instead use an existing implementation of the formatter, or perhaps create a new one. Of course, the wart somewhat loses its usefulness when inside code, because an intellisense-like tool can easily convey the same information. However, in documentation summaries or samples, or when working on the white board, these are useful.

Those that are useless, but benign

The leading contenders here would be the C prefix (indicating that a type is a class), the T prefix (indicating that a symbol is a template), the _t suffix (indicating that a symbol is a type), the g_ and m_ prefixes (indicating respectively that a symbol is a global or member variable). The latter is sometimes found as a trailing underscore.

All of this information can either be clearly inferred from the context in any reasonably well-written program (not only should all programs be well-written, but programs which use warts generally use them in order to write the program well), or provide no actual relevant information.

The starting point would be the C prefix. Indicating that a symbol is a class type can serve two purposes: differentiating it from non-class types, and differentiating it from non-types. The first distinction is pointless: the only situation when a class behaves differently from another type in a way that actually matters is when looking at PODs (and even then, classes can be PODs as well) and code that relies on that distinction is extremely rare.

As for labeling types to differentiate them from variables, this is a good idea in C, where no C++ namespaces exist and thus collisions must be avoided between type names and variable names. In C++, however, most serious projects place their types into namespaces, and the global namespace can be used as a last resort if necessary. Furthermore, even though it can be easily solved, ambiguity between type names and other symbols arises only with a high rarity anyway.

The T prefix to templates may appear as a good idea in the same way as the I prefix. However, a template is nothing more than an ad hoc meta-function which uses ‘<>’ instead of ‘()’ for its parameter list. As such, there is no more need to differentiate templates from non-templates than it is to differentiate functions from non-functions: the template parameter list is almost always present on a template (removing any ambiguity), and the only case where it is not present is when passing the template as an argument to another template, a situationboth too rare and too complex to be resolved without knowing what the other template is doing.

The g_ prefix for global variables does provide information that is relevant and important. However, it can be easily gathered from the context in a well-written program, simply by namespacing it: a namespaced variable is always obviously distinct from a local or member variable. The advantage of adding the namespace prefix is that the ownership of the global variable is more clear (since the namespace will reflect which part of the program the global belongs to, if any), and the prefix can be ignored easily in a context where it is obvious that a global variable is being manipulated. Also, using global variables in C++ is a typical recipe for disaster (in particular because of order-of-initialization problems) and is usually replaced by a global function returning a reference to an internally managed global object instead, making this point more of a historical anecdote.

The m_ prefix (or underscore suffix) for member variables is also useless: the vast majority of uses of a member variable happens in a context where the nature is a syntactical fact (such as object.member, object -> member or constructor() : member(data)) where a wart is entirely useless. The situation where ambiguity can arise is when accessing a member variable in a member function. Two possibilities exist here: either the function is small enough that the variable, being neither a local variable nor a function parameter, is necessarily a member, or the function is large enough to warrant an effort. This can be done by prepending a this -> to the variable name, which serves the same purpose as a wart, but has the advantage of being removable when unnecessary.

Those that are useless and dangerous

Worse that being useless, is being dangerous. Most useless warts carry redundant (and thus useless) information by using up only one or two characters. Some warts, however, can carry incorrect information, use up too much space, or even prevent code from being portable.

Correct information appears mostly with warts that carry type information. During the lifetime of a program, it’s possible for the type of variables to change to accomodate program extensions or bug corrections. Expecting the programmer doing the modification to also propagate the name change is a good idea in theory, but hopeless in practice. Inevitably, out of laziness, honest mistake or looming deadlines, the type wart will become obsolete, and will lead a maintenance programmer into thinking that iLength is an integer when in fact it is a floating-point number.

Using too much space becomes a real difficulty with type warts: either class instances get useless warts such as ‘o’ or ‘obj’ to indicate that they are objects (which is a quite pointless fact in object-oriented software), or they get more detailed ones. This is to say nothing of the typical long-pointer warts so widespread in the Win32 C API (meet the lplptstrUsername internationalization-friendly pointer to an username). While in itself just a readability issue of making variable names longer, these warts often lead the programmers to shorten the non-wart part of the name to keep line lengths manageable, leading to lplptstrUsrnm or worse.

Last but not least, there is the case of the prefix underscore: when an identifier begins with an underscore followed by a capital letter, that identifier is reserved by the implementation. This means that code can break when changing compilers or compiler versions.

Conclusion

While warts are not always necessarily bad, many are completely useless, requiring additional uniformization effort for no real gain besides, perhaps a very subjective aesthetic pleasure and a warm and fuzzy feeling for the instigator, and some are actually dangerous to use despite their initial appeal, because information redundancy, when maintained by humans, is seldom redundant in the face of changes.