From: daniel_james_at_[hidden]
Date: 2007-11-04 15:54:38
Author: danieljames
Date: 2007-11-04 15:54:37 EST (Sun, 04 Nov 2007)
New Revision: 40756
URL: http://svn.boost.org/trac/boost/changeset/40756
Log:
Edit the html tags. I cleaned up the tags on this page a little before but this
has some more significant changes. The main change is that instead of using
<p><b><i> for the guidelines I used <h3> as they act as headings for their
sections. But I think this could be better - maybe an <ul>, <dl> or
<blockquote>. Refs #1356.
Text files modified:
website/public_html/beta/development/int_const_guidelines.html | 73 ++++++++++++++++++++-------------------
1 files changed, 37 insertions(+), 36 deletions(-)
Modified: website/public_html/beta/development/int_const_guidelines.html
==============================================================================
--- website/public_html/beta/development/int_const_guidelines.html (original)
+++ website/public_html/beta/development/int_const_guidelines.html 2007-11-04 15:54:37 EST (Sun, 04 Nov 2007)
@@ -114,8 +114,8 @@
also be incomplete, more guidelines may be added as compilers
change and/or more problems are encountered.</p>
- <p><b><i>When declaring constants that are class members always
- use the macro <code>BOOST_STATIC_CONSTANT.</code></i></b></p>
+ <h3>When declaring constants that are class members always use
+ the macro <code>BOOST_STATIC_CONSTANT.</code></h3>
<pre>
template <class T>
struct myclass
@@ -130,27 +130,28 @@
expressions). The BOOST_STATIC_CONSTANT macro uses the most
appropriate method for the compiler in question.</p>
- <p><b><i>Don't declare integral constant expressions whose type
- is wider than int.</i></b></p>
+ <h3>Don't declare integral constant expressions whose type is
+ wider than int.</h3>
<p>Rationale: while in theory all integral types are usable in
integral constant expressions, in practice many compilers limit
integral constant expressions to types no wider than
- <b>int</b>.</p>
+ <code>int</code>.</p>
- <p><b><i>Don't use logical operators in integral constant
- expressions; use template meta-programming instead.</i></b></p>
+ <h3>Don't use logical operators in integral constant
+ expressions; use template meta-programming instead.</h3>
- <p>The header <boost/type_traits/ice.hpp> contains a
- number of workaround templates, that fulfil the role of logical
- operators, for example instead of:</p>
-
- <p><code>INTEGRAL_CONSTANT1 || INTEGRAL_CONSTANT2</code></p>
+ <p>The header <code><boost/type_traits/ice.hpp></code>
+ contains a number of workaround templates, that fulfil the role
+ of logical operators, for example instead of:</p>
+ <pre>
+INTEGRAL_CONSTANT1 || INTEGRAL_CONSTANT2
+</pre>
<p>Use:</p>
-
- <p>
- <code>::boost::type_traits::ice_or<INTEGRAL_CONSTANT1,INTEGRAL_CONSTANT2>::value</code></p>
+ <pre>
+::boost::type_traits::ice_or<INTEGRAL_CONSTANT1,INTEGRAL_CONSTANT2>::value
+</pre>
<p>Rationale: A number of compilers (particularly the Borland
and Microsoft compilers), tend to not to recognise integral
@@ -159,18 +160,20 @@
up when the integral constant expression is nested deep inside
template code, and is hard to reproduce and diagnose.</p>
- <p><b><i>Don't use any operators in an integral constant
- expression used as a non-type template parameter</i></b></p>
+ <h3>Don't use any operators in an integral constant expression
+ used as a non-type template parameter</h3>
<p>Rather than:</p>
-
- <p><code>typedef myclass<INTEGRAL_CONSTANT1 ==
- INTEGRAL_CONSTANT2> mytypedef;</code></p>
+ <pre>
+typedef myclass<INTEGRAL_CONSTANT1 ==
+ INTEGRAL_CONSTANT2> mytypedef;
+</pre>
<p>Use:</p>
-
- <p><code>typedef myclass< some_symbol>
- mytypedef;</code></p>
+ <pre>
+typedef myclass< some_symbol>
+ mytypedef;
+</pre>
<p>Where <code>some_symbol</code> is the symbolic name of a an
integral constant expression whose value is
@@ -182,8 +185,8 @@
template parameters, even though such expressions can be used
as integral constant expressions elsewhere.</p>
- <p><b><i>Always use a fully qualified name to refer to an
- integral constant expression.</i></b></p>
+ <h3>Always use a fully qualified name to refer to an integral
+ constant expression.</h3>
<p>For example:</p>
<pre>
@@ -195,12 +198,12 @@
expression unless the name is fully qualified (which is to say
it starts with <code>::</code>).</p>
- <p><b><i>Always leave a space after a '<code><</code>' and
- before '<code>::</code>'</i></b></p>
+ <h3>Always leave a space after a '<code><</code>' and before
+ '<code>::</code>'</h3>
<p>For example:</p>
<pre>
-<code>typedef</code> myclass< ::boost::is_integral<some_type>::value> mytypedef;
+typedef myclass< ::boost::is_integral<some_type>::value> mytypedef;
^
ensure there is space here!
</pre>
@@ -209,8 +212,7 @@
right, so <code><::</code> is interpreted as the same as
<code>[:</code>.</p>
- <p><b><i>Don't use local names as integral constant
- expressions</i></b></p>
+ <h3>Don't use local names as integral constant expressions</h3>
<p>Example:</p>
<pre>
@@ -253,8 +255,8 @@
};
</pre>
- <p><b><i>Don't use dependent default parameters for non-type
- template parameters.</i></b></p>
+ <h3>Don't use dependent default parameters for non-type
+ template parameters.</h3>
<p>For example:</p>
<pre>
@@ -277,7 +279,7 @@
that are compiler specific, and/or break one or more of the
coding guidelines.</p>
- <p><b><i>Be careful of numeric_limits</i></b></p>
+ <h3>Be careful of numeric_limits</h3>
<p>There are three issues here:</p>
@@ -343,7 +345,7 @@
};
</pre>
- <p><b><i>Be careful how you use the sizeof operator</i></b></p>
+ <h3>Be careful how you use the sizeof operator</h3>
<p>As far as I can tell, all compilers treat sizeof expressions
correctly when the argument is the name of a type (or a
@@ -361,8 +363,7 @@
value with Metroworks C++).</li>
</ol>
- <p><b><i>Don't use boost::is_convertible unless you have
- to</i></b></p>
+ <h3>Don't use boost::is_convertible unless you have to</h3>
<p>Since is_convertible is implemented in terms of the sizeof
operator, it consistently gives the wrong value when used with