RubyGems - script_core - Versions diffs - 0.3.0 → 0.3.2 - Mend

script_core 0.3.0 → 0.3.2

Files changed (1057) hide show

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

@@ -0,0 +1,140 @@
+<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 ADDED Viewed

@@ -0,0 +1,156 @@
+<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 ADDED Viewed

@@ -0,0 +1,119 @@
+<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 ADDED Viewed

@@ -0,0 +1,135 @@
+<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>