Tales of C++

Episode Fifteen: What's In A Name?

2010-02-11T09:09:00.000-08:00

In C++'s world, a rose by any other name may not smell as sweet. Names in C and C++ do not only identify things, but they can convey properties of such things. Consider the following declaration:

void rose( color_type color = color_type::red );

Here the name rose is an identifier, but it also states that -by default- roses are red. Function names cannot be held in variables, but function pointers (or references) can. But if we were to take such pointer (or reference), we would have to drop the associated knowledge that roses are red by default.

void (*rose_ptr)() = &rose; // Error, rose takes one argument
void (*rose_ptr)( color_type ) = &rose; // Ok, but the default color is lost

But that's not it. Function names carry other information as well. A function name may identify a set of functions, as in an overloaded function (an expression as `&function_name` is the only way to create an overloaded function pointer). Additionally, in presence of argument dependent lookup, an unqualified function name may identify a set of functions in different namespaces.

What's in a function name? In C++ the answer would be default parameters, overload resolution and argument dependent lookup. All those get dropped when taking a function pointer (or reference). This duality of names can cause portability problems; consider the following fragment from the standard (n3000),

17.6.4.4.3:
An implementation shall not declare a global or non-member function signature with additional default arguments.
17.6.4.5.2:
An implementation may declare additional non-virtual member function signatures within a class:
—by adding arguments with default values to a member function signature;
—by replacing a member function signature with default values by two or more member function signatures with equivalent behavior;

The fact that an implementation may declare additional arguments with default values to member functions means that the exact signature type of such standard functions is not standardized. As a result, it is impossible to portably create a pointer to a standard library member function. C++0X's `auto` and `decltype` are of little help, since the exact function type must be known to cast the function pointer to it in case there are overloads. On the other hand, global or non-member function exact signatures are standardized.

If in need to take a function pointer to a function whose exact type is unspecified, the solution is to wrap it around another function with the expected signature and take the pointer of such function. A generic solution can only be created by means of the preprocessor, the preprocessor is the only C++ feature that can operate on identifiers; even in the shape of things to come with C++0X.

Finally, is worth noticing that templates too have default arguments, and so there is also more in their names than just identifiers.

Episode Fourteen: Proper Closure

2010-01-20T19:56:00.000-08:00

It's polite to include proper closing when writing letters or emails. C++ is actually stricter, and enforces proper file closing in standard compliant code. Unfortunately most -if not all- current compilers would humour nonstandard impolite code; some won't even issue a warning. As a result, portable yet nonstandard code gets away with it.

From the standard (n3000), 2.2.3:

A source file shall not end in a partial preprocessing token or in a partial comment.

A partial preprocessing token would arise for instance from an include directive that is missing the closing " or >. Those are obvious errors, and luckily compilers think so as well since they wouldn't know how to recover from it anyway. Unclosed /*multiline comments*/ would issue errors as well. However, single line comments are a different story. Single line comments span from a // token until the next (unescaped) new-line character. This means that code like the following is not legal C++:

#endif // SCOPE_GUARD_HPP [Note: no new-line here][EOF]

There is yet another reason why such code would be illegal, even without its comment. From the standard (n3000), 2.2.2:

If a source file that is not empty does not end in a new-line character, or ends in a new-line character immediately preceded by a backslash character, the behavior is undeﬁned.

In simple words, standard C++ source code files end in an unescaped new-line character; with the single exception of empty files. Anything else is nonstandard, even when its portable across (probably) any compiler known to man.

Episode Thirteen: The Ways Of sizeof

2009-12-25T19:00:00.000-08:00

C++ inherits from C the sizeof operator; it yields the number of bytes in the object representation of its operand. It comes in two flavours, `sizeof( type-name )` and `sizeof expression`. It's important to note that expressions in the form `sizeof( ptr )->member` refer to the second sizeof form, and are not a syntactic error.

While sizeof is just about getting the size of its operand, its power extends beyond that.
When operated on expressions, every regular rule applies yet the expression is not evaluated. Particularly, when applying sizeof to an overloaded function call, overload resolution rules apply. This means that, if the resulting types of the overloaded functions differ in size, sizeof can effectively be used to discover the would-be called function from an overloaded function set. The following example shows how:

typedef char (&int_overload_type)[1];
typedef char (&double_overload_type)[2];

int_overload_type f( int );
double_overload_type f( double );

// All three expressions evaluate to true
sizeof( f( 1 ) ) == sizeof( int_overload_type );
sizeof( f( 1. ) ) == sizeof( double_overload_type );
sizeof( f( 1.f ) ) == sizeof( double_overload_type );

This technique is particularly useful to 'introspect' characteristics of a generic type when working with templates. The full power of overload resolution is available at compile time via the 'sizeof trick'; this includes ellipsis, template functions and even SFINAE [1]. Following is a possible implementation of the `is_convertible` trait:

template< typename T, typename U >
struct is_convertible
{
    typedef char (&yes_type)[1];
    typedef char (&no_type)[2];

    static T& make();

    static yes_type test( U const& );
    static no_type test( ... );

    static const bool value =
        sizeof( test( make() ) ) == sizeof( yes_type );
};

Since any standard or user defined conversion is preferred over the ellipsis, the size of the overloaded function call will result in that of yes_type when a conversion from T to U exists. (Note: Passing user defined types through ellipsis results in undefined behaviour, and some compilers will issue a warning even when the call is never invoked. Furthermore, access rules are applied after overloading resolution, so this technique will trigger a compile time error if the conversion is achieved via a protected/private user defined conversion operator).

In the same way, traits can be built to detect structural properties (dependant names, based on SFINAE), operator overloading (involving the 'comma operator trick'), etc.

Generally speaking whatever selection can be achieved by overload resolution, can be obtained at compile time by means of sizeof.

[1] http://en.wikipedia.org/wiki/SFINAE

Episode Twelve: When the Size does Matter

2009-11-29T12:48:00.000-08:00

In C++, zero-sized addressable objects are forbidden. Objects must have size, even if they are empty. This is required in order to have different addresses for different objects. From the standard, 1.8.5:

A most derived object shall have a non-zero size and shall occupy one or more bytes of storage. Base class subobjects may have zero size.

An empty class is one that contain no non-static data members, either directly or indirectly. Empty classes shall have non-zero size as well, and usually occupy the size of a single char. However, in face of alignment, padding bytes may be added increasing the unused space.

The standard requires that the size of a complete object shall not be zero, and that base data members precede data members of the derived class. However, base class subobjects aren't required that; making it possible to remove the base class subobject from the derived object and thus avoiding the unused space.

While is possible to avoid the overhead of an empty class when using it as a base, it is not possible to do so with an empty data member. When holding a potentially empty data member, it would have to be moved as a base class in order to take advantage of EBO. Boost provides a ready to use utility called Compressed Pair [1]. Its very similar to std::pair, but if either of the template arguments are empty classes, then the "empty base-class optimization" is applied to compress the size of the pair.

[1] http://www.boost.org/libs/utility/compressed_pair.htm

Episode Eleven: Exceptions for the Exceptional

2009-10-24T13:24:00.000-07:00

An exception breaks the normal flow of code under given conditions, and forces the caller to deal with them, as opposed to return codes. In C++, exceptions should be used for the exceptional situations only. An exceptional situation is something that should never happen (yet it might). This is not the situation with other languages; notably Python throws an exception to signal the end of an iteration.

Exceptions are objects, and as such, the implementation needs space to create them in order to throw them. The standard dictates that if an out of memory condition is reached while creating an exception to be thrown, an std::bad_alloc exception is thrown instead. A C++ implementation is required to have enough spare memory to be able to throw bad_alloc in case of memory exhaustion. This means that the only exception that is guaranteed to be thrown is std::bad_alloc, any other exception could be lost in the face of memory exhaustion.

When throwing an exception results in another exception being thrown --from the copy-constructor/destructor of the exception being thrown, or from the destructors called during stack unwinding--, std::terminate() is invoked which aborts execution. That's why throwing destructors are discouraged, as well as exception classes copy-constructors that allocate memory, among others.

When an exception is thrown and there is no matching handler std::terminate() is also invoked, however in this situation is implementation-defined whether stack unwinding occurs, which could lead to leaked resources.

When std::unexpected() is invoked and no user defined unexpected handler is set std::terminate() is invoked. std::unexpected() is called by the implementation when a function exits via an exception not allowed by its exception-specification. An exception-specification tends to have consequences that require very careful thought to understand. Particularly, exception-specifications are enforced at *run-time* (for those implementations that do honor them) instead of at compile-time (as in Java).

What does all this means? If we were to end iteration the Python way, a simple for loop could result in program abortion and leaked resources. Clearly not what is intended for such a situation that's not only possible, but expected.

Episode Ten: The Natural Order of Things

2009-10-17T14:28:00.000-07:00

While each statement is evaluated after the previous one, the evaluation of individual sub-expressions is left unspecified in C++. This is supposed to allow producing optimal code for the target platform, as opposed to intuitive left-to-right evaluation everywhere. Code relying on the implementation defined evaluation order is thus non-portable. This means that `v[i] = i++`, `v[i] + i++` and even `f(v[i], i++)` are all examples of non-portable code. Generally speaking, when a variable is read twice and also written in the same expression the result is undefined.

The standard defines a few exceptions where evaluation order is specified:

· Operands of the binary logical operators (&& and ||) are evaluated left-to-right, and short-circuited.

· Operands of the comma operator (,) are evaluated left-to-right.

· The first operand of the conditional operator (?:) is completely evaluated before continuing. Only one of the second and third expressions is evaluated.

· Initialization of class bases and members is evaluated in a strict order, so to guarantee destruction in the reverse order. Direct base classes are initialized first, in the order they appear in the base-specifier-list. Then, non-static members are initialized in the order they were declared in the class definition.

When operators are overloaded, the semantics became those of function-call expressions. So the evaluation order for overloaded binary logical operators and the overloaded comma operator is again unspecified. This means special care must be taken when working with templates, where the concrete type is unknown. The evaluation order for expressions including those operators is dependant on whether the provided type overloads such operators; and for binary logical operators it also means that short-circuited evaluation is not guaranteed. This is why overloading them is sometimes considered rude.

Assuming a type overloads operators with their usual meaning, some protection can be achieved by wrapping them in a type for which they are not:

template< typename T >
struct protected_
{
    protected_( T value ) : _value( value ) {}
    T value() const { return _value; }
    operator unspecified-bool-type() const { return _value; }

    T _value;
};

template< typename T >
protected_< T& > protect( T& v ){ return v; }

Considering an evil_int type that behaves like an integer and overloads every operator with their usual meaning,

evil_int value1 = 0, value2 = 0;
std::cout
<< ( ++value1, value1++ ) << ", "
<< ( value2 && ++value2 ) << std::endl;

results in "0, true" (for a particular C++ implementation); while

evil_int value1 = 0, value2 = 0;
std::cout
    << ( protect( ++value1 ), protect( value1++ ) ).value()
    << ", "
    << ( protect( value2 ) && protect( ++value2 ) )
    << std::endl;

results in "1, false" as expected for an integral-like type.

Episode Nine: Erasing the Concrete

2009-09-23T22:46:00.000-07:00

Type erasure is a technique that allows to store and operate objects of different types that fulfill a given concept. It can be seen as non-intrusively introducing an abstract base class to every type that provides a common interface. It turns a wide variety of types into one type.

Two big exponents of type erasure are Boost.Any [1] and Boost.Function [2]. Boost.Any is like C# and Java's Object base class, except it has value semantics. Boost.Function implements a generalized callback type that can be used to store arbitrary function pointers and function objects.

Its implementation defines a placeholder, which provides the abstract interface; and a holder template class that stores the concrete object, in terms of which implements the placeholder's interface (the type is not really erased, but pushed further away).

An example of type erasure that creates a single type to operate on every object that can be incremented follows.

· Placeholder:

class placeholder
{
public:
virtual ~placeholder() {}
virtual placeholder* clone() const = 0;
virtual void increment() = 0;
};

· Holder:

template< typename T > class holder : public placeholder
{
public:
explicit holder( T const& value ) : _held( value ) {}
holder* clone() const { return new holder( _held ); }
void increment(){ ++_held; }

private:
T _held;
};

· Incrementable:

class incrementable
{
public:
template< typename T > incrementable( T const& value )
: _content( new holder< T >( value ) ){}

incrementable( incrementable const& that )
: _content( that._content->clone() ){}

~incrementable() { delete _content; }

void swap( incrementable& rhs )
{
std::swap( _content, right._content );
return (*this);
}

template< typename T > incrementable& operator=( T const& rhs )
{
incrementable( rhs ).swap( *this );
return (*this);
}
incrementable& operator=( incrementable rhs )
{
rhs.swap( *this );
return (*this);
}

void increment(){ _content->increment(); }

private:
placeholder* _content;
};

With the given definition, an object of type incrementable can be used to hold and increment any arithmetical types, pointers, iterators, and every other type that implements the pre-increment operator.

[1] http://www.boost.org/doc/html/any.html
[2] http://www.boost.org/doc/html/function.html

Episode Eight: The Curious Case of Recurring Template Pattern

2009-09-11T20:31:00.000-07:00

The curiously recurring template pattern (CRTP) is an idiom in which a class X derives from a class template instantiation using X itself as template argument. It splits generic and concrete functionality by delegating to its derived class. This works because X is an incomplete type at the point of template instantiation, and it only works when the declaration of the base template does not use X as a complete type. Member function definitions, on the other side, are instantiated long after their declarations, allowing use of members of the derived class via the use of a static_cast.

One of its notable uses is to achieve static polymorphism, which is a compile time polymorphism and thus does not have to pay the overhead associated with virtual functions (namely, the overhead of a virtual function call and the generation of typeids). Consider the following example, adapted from Wikipedia's example on C++ (dynamic) polymorphism [1]:

template< Derived >
class Animal
{
string talk(){ return static_cast< Derived* >( this )->talk(); }
};

class Cat : public Animal< Cat >
{
string talk() { return "Meow!"; }
};

class Dog : public Animal< Dog >
{
string talk() { return "Arf! Arf!"; }
};

Note that Animal< Cat > and Animal< Dog > are two unrelated classes, this means there is no common base class between a Cat and a Dog. Dynamic polymorphism can be reintroduced by making Animal inherit from an AnyAnimal class which defines `virtual string talk() = 0;`, or non-intrusively by means of type erasure.

[1] Wikipedia - Polymorphism in object-oriented programming

Episode Seven: One char to Rule Them All

2009-08-28T22:13:00.000-07:00

There are three char types in C++: one is signed, one is unsigned, and the other one is neither of those. From the standard, 3.9.1.1:

Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.11); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation.

Knowing this is important when overloading functions, as well as template specialization. A function call with a narrow character literal f( 'x' ) will match a signature of type R( char ). However, if both R( signed char ) and R( unsigned char ) overloads are provided, but not a plain char one, the expression turns into an ambiguous call to an overloaded function.

The distinction between plain and signed char is also important when working with pointers:

char const *plain_char = "some narrow string literal";
signed char const *signed_char = plain_char; // error: char and signed char are different types

int const *plain_int = 0;
signed int const *signed_int = d; // OK: int and signed int are the same type

The three types of char are inherited from C, where this incompatibility between char and signed char pointers also exists.

Plain char is the type of narrow character and string literals. Whether a plain char is signed or unsigned is implementation-defined. Certain operations depend on whether the object's type is signed or unsigned (e.g. bit-wise shifts), so they can't be used with plain char when writing portable code. Plain char should be used only when working with characters, while signed and unsigned char should be used as small integral types.

Episode Six: Boolsh*t

2009-08-19T19:30:00.000-07:00

The built-in type bool is an integral type that can have one of the two values `true` or `false`. Despite being an integral type there are no signed, unsigned, short, or long bool types or values. There are some special situations where extra care is needed when working with bools:

Conversion to bool: A class with an unambiguous meaning of validity could benefit from a conversion to bool. Such conversion allows definition and subsequent testing for validity, something widely used in conditional statements. A conversion operator to bool seems to be the obvious approach, but it comes with harmful side effects due to the lack of an `explicit` specifier for conversions operators. Since bool is an integral type, it can be arithmetically operated, which means that an object convertible to bool will also be arithmetically operable! To overcome these and other side effects, a technique usually known as the 'safe bool idiom' was developed [1]. Such technique makes use of pointer to member objects, which are convertible to bool but differ from regular pointers in that there is no pointer-to-member arithmetic.

Overloading logical operators: When designing a class which behaves like a bool, overloading logical operators (&&, ||, etc) may be tempting. For instance, when writing a tri-state boolean (See Boost.Tribool [2]) its possible to introducing logical operator overloads to keep the logical semantics of the 3rd state. However, to keep one's semantics another one's have to go. Logical operators are short circuited; they do not perform element accesses beyond what is required to determine the result. Once a logical operator has been overloaded, there is no way it can continue to be short circuited. The syntactic sugar hardly ever justifies such surprise factor.

std::vector< bool >: A vector of bools is explicitly specialized to hold bits rather than bools. It can be seen as a dynamic counterpart to std::bitset, and it should have been defined as such. While it drastically reduces space allocation, `std::vector< bool >` does not provide the same features/guarantees than any other vector, and its not even a container according to the general container requirements! This means generic code using std::vector may not be valid for vectors of bools.

[1] http://www.artima.com/cppsource/safebool.html
[2] http://www.boost.org/doc/html/tribool.html

Episode Five: Explicit is Better than Implicit

2009-08-08T12:21:00.000-07:00

Type conversion allows one type to convert to another. In C++, they came in two flavours:

Conversion by construction: Constructors that can be called with a single argument are called converting constructors. This includes constructors with a single formal argument, as well as constructors with more than one argument that specifies default values. Implements conversion-from-type, intrusive on the destination type.

Conversion functions: Also called conversion operators, are member functions defined as `operator Type() [const]` (Note no result type defined). Implements conversion-to-type, intrusive on the source type.

Automatic conversion is believed to be too error prone. If an operator does not apply to a class but does apply unambiguously to one of its implicitly convertible types such operator will be called. When designing a phone number class it might make sense for its objects to automatically became integers, but what does adding them means? Such paths must be carefully forbidden by means of access rules.

Code which relies upon implicit type conversions may become broken when new classes or functions are added, when used in conjunction with overloaded functions. If a function f takes an object of type T1 which is convertible from char const*, it can be called as `f( "some text" )` since automatic conversion will create the appropiate T1 object from "some text" under the hood. However, if an overload for function f is later added with an argument of type T2, which is also convertible from char const*, suddenly the call becames ambiguous and will no longer compile.

When declarating constructors, the `explicit` specifier can be used to indicate that the constructor is merely a constructor and shall not be considered for implicit type conversions. For a practical example of why this is needed, consider std::vector's `explicit vector( size_type n )` constructor, which constructs a vector with n default constructed elements. Shall not this constructor specified as explicit, `std::vector<> v = 10;` will result in a vector of 10 elements. Even more, a function having `std::vector<> const&` as an argument would be callable with an integer! There is no `explicit` specifier for conversion operators (yet, but it will be part of C++0x).

Automatic type conversion should be used carefully. It’s excellent when it significantly reduces a coding task, but it’s usually not worth using gratuitously.

Episode Four: Not Enough Keys in the Keyboard

2009-07-22T08:26:00.000-07:00

The basic character set of the C programming language is a subset of the ASCII character set that includes nine characters which lie outside the ISO 646 invariant character set. Trigraphs were invented as a way of entering source code using keyboards that support any version of the ISO 646 character set.

Trigraph
Replacement
??=
#
??/
\
??'
^
??(
[
??)
]
??!
|
??<
{
??>
}
??-
~

Trigraph	Replacement
??=	#
??/	\
??'	^
??(	[
??)	]
??!	\|
??<	{
??>	}
??-	~

Handling of trigraphs is done at the preprocessing stage. This means they are replaced everywhere, which can became the cause of subtle bugs.

· Within a string literal:

"He said 'Hello???'." becames "He said 'Hello?^.".

· Within a line comment:

// Whats wrong with this??/
void i = 0; // This line is also inside the line comment.

Digraphs were supplied as more readable alternatives to six of the trigraphs.

Digraph
Replacement
<:
[
:>
]
<%
{
%>
}
%:
#
%:%:
##

Digraph	Replacement
<:	[
:>	]
<%	{
%>	}
%:	#
%:%:	##

Unlike trigraphs, digraphs are handled during tokenization, so they pose no harm.

Breaking News: Concepts are out

2009-07-20T11:59:00.000-07:00

Beman Dawes posted earlier today at the Boost Developers Mailing List:

The C++ standards committee met in Frankfurt, Germany, last week. Key actions:

* Concepts have been removed from C++0x.

The committee is very much in favor of Concepts. But Concepts are seen as so important that they have to be right. And the strong consensus was that getting Concepts right, for any reasonable definition of "right", would add several years to the schedule. There was also a consensus that an implementation of a compiler that could compile the entire standard library is part of the definition of "right". While ConceptGCC has been a great help, it isn't there as far as validating "right". Personally, I think Clang may end up being the compiler that eventually validates Concepts.

(...)

We'll have to keep waiting...

Episode Three: Friends with Benefits

2009-07-18T12:21:00.000-07:00

Friendship is a special relation among classes in C++. A friend of a class is a function or class that is given access to its private (and protected) parts.

· Friendship is reflexive: An instance of a class has access to private and protected members of every other instance of the same class.

· Friendship is not symmetric: Being a friend is different from having a friend. One-way friendship is the most common situation.

· Friendship is not transitive: Friends of a class friend are not friends of the class itself.

· Friendship is not inheritable: Descendants of a class don't inherit the parent friends.

Friends break encapsulation, so it should be used wisely. Some languages offer a form of restricted friendship, in which access is granted only to certain members. Such behaviour can be emulated in C++.

One way of doing this is to declare a proxy class that implements a private interface. Such proxy class will have full access to the original class (granted either by declaring it as a nested class, or by the friend specifier), and will grant access only to the target classes of the interface.

Another alternative is by means of access keys. Access keys can be declared as:

template< typename T >
class access_key
{
friend T;

access_key() {} // default constructor is private
};

Adding an access key as an argument to a public function will prevent that function from being called in a context other than those in which an access key can be obtained. Only objects of type T can construct an access_key<T>, which grants them access to the function, but since access keys can be copied or passed by reference an object of type T can also effectively "pass friendship around".

Episode Two: Those Whose Names must not be Spoken

2009-07-17T20:35:00.000-07:00

The C++ standard reserves a set of names for use by C++ implementation and standard libraries [C++ standard 17.6.3.3 - Reserved names]. Those include but are not limited to:

- Names containing a double underscore.
- Names that begin with an underscore followed by an uppercase letter.
- Names that begin with an underscore at the global namespace.

The standard itself makes use of such reserved names in macros like __FILE__ and __LINE__ as well as the new (C++0x) local variable __func__.

The C standard has even stricter rules for reserved function and macro names for future implementation. C functions live at the global namespace; staying out of it is a good practice to avoid name clashing. Macro names must be selected with special care, since they do not respect scopes.

Is not uncommon to see source code that makes use of these reserved names. This is specially seen at scope guards in the form _FILENAME_H_. Such usage can only be attributed to unawareness of the standard, but nonetheless results in undefined behavior.

Most of the time, those names can be used and still get away with it. For instance, MSVC8 does not seem to have a problem to handle a member object named `__vfptr` in a class with virtual functions, even though `__vfptr` is the name for the implicitly defined virtual function table. However, the compiler is allowed to reject the code, or even worse do whatever it wants with it.

Fortunately, staying in the safe zone is just as easy as avoiding reserved names.

Episode One: To be or not to be const

2009-07-15T00:45:00.000-07:00

Const-correctness is the form of program correctness that deals with the proper declaration of objects as mutable or inmutable. It dictates that all objects should be declared as const unless they need to be modified. It results in clearer, easier to follow code.

In C++, const does not imply that an object's bits cannot be changed (bitwise const), but rather than its logical state does not change (logical const). It's not about optimizations as some may think, but about declaration of intention [1]. By declaring an object as const you let the compiler known that its value is not meant to be changed, and the compiler will enforce such declaration. It's also a form of embedded documentation for future readers.

Sometimes an object logical state does not change, but its bits do (think of an object that provides reference count, cache, ...). Such thing is accomplished by the use of the `mutable` keyword. A member object that is declared as mutable can always be changed, even inside a const member function or by a pointer/reference to const. Another alternative is to "cast the constness away" by means of const_cast. By using it, its possible to turn a pointer/reference to an inmutable object into one to a mutable object. This is legal only if the pointed/referred object was not declared inmutable.

Sometimes following const-correctness may impose an additional burden on the developer, but its benefits outweights the cost. If something is meant to be inmutable, Don't Lie To Your Compiler.

[1] http://www.revergestudios.com/reblog/index.php?n=ReCode.Const