RubyGems - script_core - Versions diffs - 0.1.1 → 0.2.4 - Mend

script_core 0.1.1 → 0.2.4

Files changed (1479) hide show

data/ext/enterprise_script_service/msgpack/external/boost/preprocessor/doc/topics/incompatible.html DELETED

@@ -1,140 +0,0 @@
-<html>
-<head>
-	<title>incompatible.html</title>
-	<link rel="stylesheet" type="text/css" href="../styles.css">
-</head>
-<body>
-	<h4>Incompatibilities</h4>
-	<div>
-		There are several incompatibilities with the previous Boost release (1.28).&nbsp;
-		These fall into roughly three categories:&nbsp;
-	</div>
-	<ul>
-		<li>the horizontal repetition primitives based on <b>BOOST_PP_REPEAT</b></li>
-		<li>the reentrancy syntax</li>
-		<li><i>list</i> folding</li>
-	</ul>
-	<h4>Repetition Targets</h4>
-	<div>
-		First, and probably the most commonly used, is the target macros passed into <b>BOOST_PP_REPEAT</b> and the horizontal repetition contructs that use <b>BOOST_PP_REPEAT</b>.&nbsp;
-		This includes all of the <b>BOOST_PP_REPEAT_</b>* primitives and all of the <b>BOOST_PP_ENUM_</b>* primitives that require a target macro.
-	</div>
-	<div>
-		The incompatiblity is trivial, but it will require that the source be updated.&nbsp;
-	</div>
-	<div>
-		These target macros must now except a <i>third</i> parameter.&nbsp;
-		This extra parameter becomes the <i>first</i> parameter in every target macro.&nbsp;
-		It represents the next repetition dimension and brings <b>BOOST_PP_REPEAT</b> inline with rest of the library.&nbsp;
-	</div>
-	<div>
-		So, what once was:
-	</div>
-	<div class="code">
-		#define <i>macro</i>(<i>n</i>, <i>data</i>) ...<br>
-		<b>BOOST_PP_REPEAT</b>(<i>5</i>, <i>macro</i>, <i>data</i>)
-	</div>
-	<div>
-		...is now:
-	</div>
-	<div class="code">
-		#define <i>macro</i>(<i>z</i>, <i>n</i>, <i>data</i>) ...<br>
-		<b>BOOST_PP_REPEAT</b>(<i>5</i>, <i>macro</i>, <i>data</i>)
-	</div>
-	<div>
-		This parameter can be used for highly efficient reentrance into the <b>BOOST_PP_REPEAT</b> mechanism.&nbsp;
-		However, it is not necessary to use it as the library can automatically detect the next available repetition dimension.
-	</div>
-	<h4>Dimensional Ordering</h4>
-	<div>
-		Because of this detection, however, it is unsafe to use <b>BOOST_PP_REPEAT_1ST</b>, <b>BOOST_PP_REPEAT_2ND</b>, and <b>BOOST_PP_REPEAT_3RD</b> out of order.&nbsp;
-		These macros bypass the <i>automatic-recursion</i> mechanism, and the <i>automatic-recursion</i> mechanism relies on macros being used in the proper order.&nbsp;
-		To clarify, if you use these bypass macros, the outer-most repetition <i>must</i> be <b>BOOST_PP_REPEAT_1ST</b>, then <b>BOOST_PP_REPEAT_2ND</b>, and finally <b>BOOST_PP_REPEAT_3RD</b>.&nbsp;
-		Any other usage is not supported by the library.&nbsp;
-		Sometimes it may work, and other times it won't.
-	</div>
-	<h4>Reentrancy Syntax</h4>
-	<div>
-		<i>Automatic-recursion</i> brings with it another issue as well.&nbsp;Previously, the reentrancy syntax for <b>BOOST_PP_WHILE</b> (and similarly for <b>BOOST_PP_FOR</b>) was:
-	</div>
-	<div class="code">
-		<b>BOOST_PP_WHILE</b> ## <i>d</i>(<i>pred</i>, <i>op</i>, <i>state</i>)
-	</div>
-	<div>
-		...or:
-	</div>
-	<div class="code">
-		<b>BOOST_PP_CAT</b>(<b>BOOST_PP_WHILE</b>, <i>d</i>)(<i>pred</i>, <i>op</i>, <i>state</i>)
-	</div>
-	<div>
-		Under the <i>automatic-recursion</i> model, the <b>BOOST_PP_CAT</b> version breaks.&nbsp;
-		This is because <b>BOOST_PP_CAT</b> allows its arguments to expand prior to concatenation,
-		and <b>BOOST_PP_WHILE</b> is a macro that expands without arguments.&nbsp;
-		The library makes it appear that it takes three parameters, but that is the trick of <i>automatic-recursion</i>.&nbsp;
-		It works similarly to the following:
-	</div>
-	<div class="code">
-		#define A(x, y) ...<br>
-		#define B A<br>
-		// ...<br>
-		B(2, 3)
-	</div>
-	<div>
-		The syntax makes it look like the <i>B</i> macro above takes two arguments, but it doesn't.&nbsp;
-		The <i>automatic-recursion</i> mechanism works in this fashion, except that the "<i>B</i>" macro deduces the next available "<i>A</i>" macro.
-	</div>
-	<div>
-		Because some preprocessors are still slow, direct reentrancy (sans <i>automatic-recursion</i>) is still necessary in non-trivial cases.&nbsp;
-		Consequently, the library uses a new syntax to handle reentrancy:
-	</div>
-	<div class="code">
-		<b>BOOST_PP_FOR_</b> ## <i>r</i>(<i>state</i>, <i>pred</i>, <i>op</i>, <i>macro</i>)<br>
-		<b>BOOST_PP_REPEAT_</b> ## <i>z</i>(<i>count</i>, <i>macro</i>, <i>data</i>)<br>
-		<b>BOOST_PP_WHILE_</b> ## <i>d</i>(<i>pred</i>, <i>op</i>, <i>state</i>)
-	</div>
-	<h4>Folding</h4>
-	<div>
-		Previously, the <b>BOOST_PP_LIST_FOLD_RIGHT</b> macros' arguments were the reverse of <b>BOOST_PP_LIST_FOLD_LEFT</b>.&nbsp;
-		Also, the accumulation macro passed into <b>BOOST_PP_LIST_FOLD_RIGHT</b> was called with reversed parameters as well.&nbsp;
-		This discrepancy has been eliminated.
-	</div>
-	<div>
-		To illustrate, <b>BOOST_PP_LIST_FOLD_RIGHT</b> used to be used like this:
-	</div>
-	<div class="code">
-		#define <i>macro</i>(<i>d</i>, <u><i>elem</i></u>, <u><i>state</i></u>)<br>
-		<b>BOOST_PP_LIST_FOLD_RIGHT</b>(<i>macro</i>, <u><i>list</i></u>, <u><i>state</i></u>)
-	</div>
-	<div>
-		This signature has been replaced by...
-	</div>
-	<div class="code">
-		#define <i>macro</i>(<i>d</i>, <u><i>state</i></u>, <u><i>elem</i></u>)<br>
-		<b>BOOST_PP_LIST_FOLD_RIGHT</b>(<i>macro</i>, <u><i>state</i></u>, <u><i>list</i></u>)
-	</div>
-	<h4>Summary</h4>
-	<div>
-		The library has many new features not present in the 1.28 release, and this list does not attempt to enumerate them.&nbsp;
-		This is simply a list of things that <i>must</i> change for code to be compatible with this new release.
-	</div>
-	<h4>See Also</h4>
-	<ul>
-		<li><a href="../ref/for.html">BOOST_PP_FOR</a></li>
-		<li><a href="../ref/list_fold_right.html">BOOST_PP_LIST_FOLD_RIGHT</a></li>
-		<li><a href="../ref/repeat.html">BOOST_PP_REPEAT</a></li>
-		<li><a href="../ref/while.html">BOOST_PP_WHILE</a></li>
-	</ul>
-	<div class="sig">- Paul Mensonides</div>
-	<hr size="1">
-	<div style="margin-left: 0px;">
-		<i>� Copyright <a href="http://www.housemarque.com" target="_top">Housemarque Oy</a> 2002</i>
-		</br><i>� Copyright Paul Mensonides 2002</i>
-	</div>
-	<div style="margin-left: 0px;">
-		<p><small>Distributed under the Boost Software License, Version 1.0. (See
-		accompanying file <a href="../../../../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or
-		copy at <a href=
-		"http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)</small></p>
-	</div>
-</body>
-</html>

data/ext/enterprise_script_service/msgpack/external/boost/preprocessor/doc/topics/local_iteration.html DELETED

@@ -1,156 +0,0 @@
-<html>
-<head>
-	<title>local_iteration.html</title>
-	<link rel="stylesheet" type="text/css" href="../styles.css">
-</head>
-<body>
-<h4>Local Iteration</h4>
-<div>
-	Local iteration is a simple vertical repetition construct.&nbsp;
-	It expands a macro with each number in a user-specified range.&nbsp;
-	Each expansion is on a separate line.
-</div>
-<h4>Tutorial</h4>
-<div>
-	This mechanism requires two pieces of information to operate:&nbsp;
-	a range to iterate over and a macro to expand on each iteration.&nbsp;
-	This information is obtained by the mechanism through two <i>named external arguments</i>.&nbsp;
-	These arguments are specified as user-defined macros named <b>BOOST_PP_LOCAL_LIMITS</b> and <b>BOOST_PP_LOCAL_MACRO</b>.
-</div>
-<div>
-	<b>BOOST_PP_LOCAL_LIMITS</b> specifies a range of values to iterate over.&nbsp;
-	It <i>must</i> expand to a <i>tuple</i> containing two elements--a lower and upper bound.&nbsp;
-	Both the upper and lower bounds must be numeric values in the range of <i>0</i> to <b>BOOST_PP_LIMIT_ITERATION</b>.&nbsp;
-	For example, if the user wishes a macro to be expanded with numbers ranging from <i>0</i> to <i>10</i>,
-	<b>BOOST_PP_LOCAL_LIMITS</b> would be defined like this:
-</div>
-<div class="code"><pre>
-#define BOOST_PP_LOCAL_LIMITS (0, 10)
-</pre></div>
-<div>
-	Note that there is whitespace after the name of the macro.&nbsp;
-	The macro <i>does not</i> take <i>two</i> arguments.&nbsp;
-	In the case above, if there was no whitespace, a preprocessing error would occur because <i>0</i> and <i>10</i> are invalid identifiers.
-</div>
-<div>
-	Both the upper and lower bounds specified in the <b>BOOST_PP_LOCAL_LIMITS</b> macro are <i>evaluated parameters</i>.&nbsp;
-	This implies that they can include simple arithmetic or logical expressions.&nbsp;
-	For instance, the above definition could easily have been written like this:
-</div>
-<div class="code"><pre>
-#define N() 5
-#define BOOST_PP_LOCAL_LIMITS (0, N() + 5)
-</pre></div>
-<div>
-	Because of this, if the whitespace after the macro name is elided, it is possible for the definition to be syntactically valid:
-</div>
-<div class="code"><pre>
-#define A 0
-#define B 10
-#define BOOST_PP_LOCAL_LIMITS(A, B)
-   // note:  no whitespace   ^
-</pre></div>
-<div>
-	If this happens, an error will occur inside the mechanism when it attempts to use this macro.&nbsp;
-	The error messages that result may be obscure, so always remember to include the whitespace.&nbsp;
-	A <i>correct</i> version of the above looks like this:
-</div>
-<div class="code"><pre>
-#define A 0
-#define B 10
-#define BOOST_PP_LOCAL_LIMITS (A, B)
-   // note:  has whitespace  ^
-</pre></div>
-<div>
-	<b>BOOST_PP_LOCAL_MACRO</b> is the macro that is expanded by the mechanism.&nbsp;
-	This macro is expanded on each iteration with the current number of the iteration.&nbsp;
-	It must defined as a unary macro <i>or</i> result in a macro that can be called with one argument:
-</div>
-<div class="code"><pre>
-#define BOOST_PP_LOCAL_MACRO(n) \
-   template&lt;&gt; struct sample&lt;n&gt; { }; \
-   /**/
-</pre></div>
-<div>
-	...or...
-</div>
-<div class="code"><pre>
-#define SAMPLE(n) \
-   template&lt;&gt; struct sample&lt;n&gt; { }; \
-   /**/
-#define BOOST_PP_LOCAL_MACRO SAMPLE
-</pre></div>
-<div>
-	Once these two macros are defined, the local iteration is initiated by <i>including</i> <b>BOOST_PP_LOCAL_ITERATE</b>().
-</div>
-<div class="code"><pre>
-??=include BOOST_PP_LOCAL_ITERATE()
-</pre></div>
-<div>
-	(The <code>??=</code> token is a trigraph for <code>#</code>.&nbsp;
-	I use the trigraph to make it clear that I am <i>including</i> a file rather than defining or expanding a macro, but it is not necessary.&nbsp;
-	Even the digraph version, <code>%:</code>, could be used.&nbsp;
-	Some compilers do not readily accept trigraphs and digraphs, so keep that in mind.&nbsp;
-	Other than that, use whichever one you prefer.)
-</div>
-<div>
-	In order to repeat the <code>sample</code> specialization, the pieces must be put together....
-</div>
-<div class="code"><pre>
-#define BOOST_PP_LOCAL_MACRO(n) \
-   template&lt;&gt; struct sample&lt;n&gt; { }; \
-   /**/
-#define BOOST_PP_LOCAL_LIMITS (0, 10)
-??=include BOOST_PP_LOCAL_ITERATE()
-</pre></div>
-<div>
-	This will result in a specialization of <code>sample</code> for each number in the range of <i>0</i> to <i>10</i>.&nbsp;
-	The output will look something like this:
-</div>
-<div class="code"><pre>
-template&lt;&gt; struct sample&lt;0&gt; { };
-template&lt;&gt; struct sample&lt;1&gt; { };
-template&lt;&gt; struct sample&lt;2&gt; { };
-// ...
-template&lt;&gt; struct sample&lt;10&gt; { };
-</pre></div>
-<div>
-	After the local-iteration is complete, both <b>BOOST_PP_LOCAL_LIMITS</b> and <b>BOOST_PP_LOCAL_MACRO</b> are automatically undefined.&nbsp;
-	If the values need to be retained for a future local-iteration, they must be defined indirectly:
-</div>
-<div class="code"><pre>
-#define LIMITS (0, 10)
-#define SAMPLE(n) \
-   template&lt;&gt; struct sample&lt;n&gt; { }; \
-   /**/
-#define BOOST_PP_LOCAL_LIMITS LIMITS
-#define BOOST_PP_LOCAL_MACRO(n) SAMPLE(n)
-??=include BOOST_PP_LOCAL_ITERATE()
-</pre></div>
-<h4>See Also</h4>
-<ul>
-	<li><a href="../ref/local_iterate.html">BOOST_PP_LOCAL_ITERATE</a></li>
-	<li><a href="../ref/local_limits.html">BOOST_PP_LOCAL_LIMITS</a></li>
-	<li><a href="../ref/local_macro.html">BOOST_PP_LOCAL_MACRO</a></li>
-</ul>
-<div class="sig">- Paul Mensonides</div>
-	<hr size="1">
-	<div style="margin-left: 0px;">
-		<i>� Copyright <a href="http://www.housemarque.com" target="_top">Housemarque Oy</a> 2002</i>
-		</br><i>� Copyright Paul Mensonides 2002</i>
-	</div>
-	<div style="margin-left: 0px;">
-		<p><small>Distributed under the Boost Software License, Version 1.0. (See
-		accompanying file <a href="../../../../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or
-		copy at <a href=
-		"http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)</small></p>
-	</div>
-</body>
-</html>

data/ext/enterprise_script_service/msgpack/external/boost/preprocessor/doc/topics/motivation.html DELETED

@@ -1,119 +0,0 @@
-<html>
-<head>
-	<title>motivation.html</title>
-	<link rel="stylesheet" type="text/css" href="../styles.css">
-</head>
-<body>
-<h4>Motivation</h4>
-<div>
-	The C++ function and template parameter lists are special syntactic constructs, and it is impossible to directly
-	manipulate or generate them using C++ constructs.&nbsp;
-	This leads to unnecessary code repetition.
-</div>
-<div>
-	Consider the implementation of the <code>is_function&lt;&gt;</code> metafunction is Boost.&nbsp;
-	The implementation uses an overloaded <code>is_function_tester()</code> function that is used for testing if a type is convertible
-	to a pointer to a function.&nbsp;
-	Because of the special treatment of parameter lists, it is not possible to directly match a function with an arbitrary parameter list.&nbsp;
-	Instead, the <code>is_function_tester()</code> must be overloaded for every distinct number of parameters that is to be supported.&nbsp;
-	For example:
-</div>
-<div class="code"><pre>
-template&lt;class R&gt;
-yes_type is_function_tester(R (*)());
-template&lt;class R, class A0&gt;
-yes_type is_function_tester(R (*)(A0));
-template&lt;class R, class A0, class A1&gt;
-yes_type is_function_tester(R (*)(A0, A1));
-template&lt;class R, class A0, class A1, class A2&gt;
-yes_type is_function_tester(R (*)(A0, A1, A2));
-// ...
-</pre></div>
-<div>
-	The need for this kind of repetition occurs particularly frequently while implementing generic components or metaprogramming facilities,
-	but the need also manifests itself in many far simpler situations.
-</div>
-<h4>Typical Solutions</h4>
-<div>
-	Typically the repetition is done manually.&nbsp;
-	Manual code repetition is highly unproductive, but sometimes more readable to the untrained eye.
-</div>
-<div>
-	Another solution is to write an external program for generating the repeated code or use some other extra linguistic means such as a smart editor.&nbsp;
-	Unfortunately, using external code generators has many disadvantages:
-	<ul>
-		<li>Writing the generator takes time.&nbsp; (This could be helped by using a standard generator.)</li>
-		<li>It is no longer productive to manipulate C++ code directly.</li>
-		<li>Invoking the generator may be difficult.</li>
-		<li>Automating the invocation of the generator can be difficult in certain environments.&nbsp; (Automatic invocation is desirable for active libraries.)</li>
-		<li>Porting and distributing the generator may be difficult or simply takes precious time.</li>
-	</ul>
-</div>
-<h4>What about the preprocessor?</h4>
-<div>
-	Because C++ comes with a preprocessor, one would assume that it would support these kinds of needs directly.&nbsp;
-	Using the preprocessor in this case is highly desirable because:
-	<ul>
-		<li>The preprocessor is highly portable.</li>
-		<li>The preprocessor is automatically invoked as part of the compilation process.</li>
-		<li>Preprocessor metacode can be directly embedded into the C++ source code.</li>
-		<li>Compilers generally allow viewing or outputting the preprocessed code, which can be used for debugging or to copy and paste the generated code.</li>
-	</ul>
-</div>
-<div>
-	Most unfortunately, the preprocessor is a very low level preprocessor that specifically does not support repetition or recursive macros.&nbsp;
-	Library support is needed!
-</div>
-<div>
-	<i>For detailed information on the capabilities and limitations of the preprocessor, please refer to the C++ standard <a href="../bibliography.html#std">[Std]</a>.</i>
-</div>
-<h4>The Motivation Example Revisited</h4>
-<div>
-	Using the primitives of the preprocessor library, the <code>is_function_tester()</code>'s could be implemented like this:
-</div>
-<div class="code"><pre>
-#include &lt;boost/preprocessor/arithmetic/inc.hpp&gt;
-#include &lt;boost/preprocessor/punctuation/comma_if.hpp&gt;
-#include &lt;boost/preprocessor/repetition.hpp&gt;
-#ifndef MAX_IS_FUNCTION_TESTER_PARAMS
-#define MAX_IS_FUNCTION_TESTER_PARAMS 15
-#endif
-#define IS_FUNCTION_TESTER(Z, N, _) \
-   template&lt;class R BOOST_PP_COMMA_IF(N) BOOST_PP_ENUM_PARAMS(N, class A)&gt; \
-   yes_type is_function_tester(R (*)(BOOST_PP_ENUM_PARAMS(N, A))); \
-   /**/
-BOOST_PP_REPEAT(BOOST_PP_INC(MAX_IS_FUNCTION_TESTER_PARAMS), IS_FUNCTION_TESTER, _)
-#undef IS_FUNCTION_TESTER
-</pre></div>
-<div>
-	In order to change the maximum number of function parameters supported, you now simply change the <code>MAX_IS_FUNCTION_TESTER_PARAMS</code> definition and recompile.
-</div>
-<hr size="1">
-<div style="margin-left: 0px;">
-	<i>� Copyright <a href="http://www.housemarque.com" target="_top">Housemarque Oy</a> 2002</i>
-</div>
-<div style="margin-left: 0px;">
-Permission to copy, use, modify, sell and distribute this document is granted provided this copyright notice appears in all copies.&nbsp;
-This document is provided "as is" without express or implied warranty and with no claim as to its suitability for any purpose.
-</div>
-	<hr size="1">
-	<div style="margin-left: 0px;">
-		<i>� Copyright <a href="http://www.housemarque.com" target="_top">Housemarque Oy</a> 2002</i>
-		</br><i>� Copyright Paul Mensonides 2002</i>
-	</div>
-	<div style="margin-left: 0px;">
-		<p><small>Distributed under the Boost Software License, Version 1.0. (See
-		accompanying file <a href="../../../../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or
-		copy at <a href=
-		"http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)</small></p>
-	</div>
-</body>
-</html>

data/ext/enterprise_script_service/msgpack/external/boost/preprocessor/doc/topics/problems.html DELETED

@@ -1,135 +0,0 @@
-<html>
-<head>
-	<title>problems.html</title>
-	<link rel="stylesheet" type="text/css" href="../styles.css">
-</head>
-<body>
-<h4>Known Problems of the C/C++ Preprocessor</h4>
-<div>
-	Preprocessor metaprogramming is subject to heated discussions.&nbsp;
-	Part of this is caused by bad experiences with dangerous techniques,
-	such as defining inline functions using macros.&nbsp;
-	As a rule of thumb, if you can find a clean and manageable way to do something
-	without the preprocessor, then you should do it that way.
-</div>
-<div>
-	Let's survey some of the widely known problems of the preprocessor in a problem/solution format.
-</div>
-<h4>Problem #1</h4>
-<div>
-	The preprocessor does not respect scope, therefore macros can accidentally and sometimes silently replace code.
-</div>
-<div>
-	<b>Solution A</b>
-	<div>
-		Use all caps identifiers for macros and only macros.&nbsp;
-		This practically eliminates the possibility that a macro might replace other kinds of code accidentally.
-	</div>
-</div>
-<div>
-	<b>Solution B</b>
-	<div>
-		Use the local macro idiom:
-	</div>
-<div class="code"><pre>
-#define MACRO ...
-// use MACRO
-#undef MACRO
-</pre></div>
-	<div>
-		This makes sure that a macro cannot accidentally replace code outside of the scope of the local macro.
-	</div>
-	<div>
-		A problem with this solution is that the #undef cannot be automated and may be forgotten.&nbsp;
-		Experienced programmers generally write the #undef either immediately before (in time)
-		or immediately after writing the macro definition.
-	</div>
-</div>
-<div>
-	<b>Solution C</b>
-	<div>
-		Use the unique macro prefix idiom.
-	</div>
-<div class="code"><pre>
-#define UMP_MACRO
-// use UMP_MACRO
-</pre></div>
-	<div>
-		This makes accidental substitution and collisions highly unlikely.&nbsp;
-		Problems with this solution include:
-	</div>
-	<ul>
-		<li>There can still be naming collisions inside a large project.</li>
-		<li>Macros still pollute the global namespace.</li>
-	</ul>
-	<i>By combining all solutions, whenever possible, the scope problem can be largely avoided.</i>
-</div>
-<h4>Problem #2</h4>
-<div>
-	Preprocessor code is difficult to read.&nbsp;
-	It requires an understanding of the basic process of how the preprocessor recursively expands macros,
-	finding macro definitions, and mentally substituting the parameters of the macro.
-</div>
-<div>
-	<b>Solution</b>
-	<div>
-		Any kind of programming requires a basic understanding of how the code is executed.&nbsp;
-		Any parameterization technique, including simple functions and templates requires finding
-		the definition and mentally substituting parameters.
-	</div>
-	<div>
-		However, it is good to know a few techniques:
-	</div>
-	<ul>
-		<li>By using as many local macros as reasonable, the bulk of the searching process can be eliminated.</li>
-		<li>Code browsers and text search tools make it easier to find the definitions.</li>
-		<li>The compiler can be used for generating the preprocessed source code in order to look for bugs.</li>
-		<li>
-			Before turning something into a preprocessor metaprogram, first implement a small scale version
-			of it without the preprocessor.&nbsp;
-			The work bottom-up, replacing hand-written constructs by using the preprocessor.&nbsp;
-			This way you can test the code incrementally.&nbsp;
-			Experienced programmers often skip many stages, but if something proves too complex to write
-			directly, it is always possible to fall back to incremental methods.
-		</li>
-		<li>
-			If you insert a special symbol into the preprocessor code in places where there should be a line break,
-			you can make code readable after preprocessing simply by using a search and replace tool.
-		</li>
-	</ul>
-	<i>An especially important thing to remember is to limit the use of the preprocessor to
-	structured, well-understood, and safe methods.&nbsp;
-	Structure helps to understand complex systems <a href="../bibliography.html#mcconnell">[McConnell]</a>.</i>
-</div>
-<h4>Problem #3</h4>
-<div>
-	"I'd like to see Cpp abolished." - <i>Bjarne Stroustrup</i> in <a href="../bibliography.html#stroustrup">[Stroustrup]</a>.
-</div>
-<div>
-	<b>Solution</b>
-	<div>
-		The C/C++ preprocessor will be here for a long time.
-	</div>
-	<i>In practice, preprocessor metaprogramming is far simpler and more portable than template metaprogramming <a href="../bibliography.html#czarnecki">[Czarnecki]</a>.</i>
-</div>
-<hr size="1">
-<div style="margin-left: 0px;">
-	<i>� Copyright <a href="http://www.housemarque.com" target="_top">Housemarque Oy</a> 2002</i>
-</div>
-<div style="margin-left: 0px;">
-Permission to copy, use, modify, sell and distribute this document is granted provided this copyright notice appears in all copies.&nbsp;
-This document is provided "as is" without express or implied warranty and with no claim as to its suitability for any purpose.
-</div>
-	<hr size="1">
-	<div style="margin-left: 0px;">
-		<i>� Copyright <a href="http://www.housemarque.com" target="_top">Housemarque Oy</a> 2002</i>
-		</br><i>� Copyright Paul Mensonides 2002</i>
-	</div>
-	<div style="margin-left: 0px;">
-		<p><small>Distributed under the Boost Software License, Version 1.0. (See
-		accompanying file <a href="../../../../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or
-		copy at <a href=
-		"http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)</small></p>
-	</div>
-</body>
-</html>