Fixed license & copyright issues and converted to HTML 4.01

[SVN r36261]
This commit is contained in:
Andreas Huber
2006-12-04 12:15:09 +00:00
parent 0a13f8485e
commit 272d49f0f3
17 changed files with 2929 additions and 2479 deletions

View File

@@ -1,103 +1,111 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Portability Hints: Borland C++ 5.5.1</title>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<title>Portability Hints: Borland C++ 5.5.1</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
<table border="1" bgcolor="#007F7F" cellpadding="2" summary="">
<tr>
<td bgcolor="#FFFFFF"><img src="../boost.png" alt=
"boost.png (6897 bytes)" width="277" height="86"></td>
<table border="1" bgcolor="#007F7F" cellpadding="2">
<tr>
<td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
<td><a href="../index.htm"><font face="Arial,Helvetica" color="#FFFFFF"><big>Home</big></font></a></td>
<td><a href="../libs/libraries.htm"><font face="Arial,Helvetica" color="#FFFFFF"><big>Libraries</big></font></a></td>
<td><a href="../people/people.htm"><font face="Arial,Helvetica" color="#FFFFFF"><big>People</big></font></a></td>
<td><a href="faq.htm"><font face="Arial,Helvetica" color="#FFFFFF"><big>FAQ</big></font></a></td>
<td><a href="index.htm"><font face="Arial,Helvetica" color="#FFFFFF"><big>More</big></font></a></td>
</tr>
</table>
<td><a href="../index.htm"><font face="Arial,Helvetica" color=
"#FFFFFF"><big>Home</big></font></a></td>
<p>
<td><a href="../libs/libraries.htm"><font face="Arial,Helvetica" color=
"#FFFFFF"><big>Libraries</big></font></a></td>
<h1>Portability Hints: Borland C++ 5.5.1</h1>
<td><a href="../people/people.htm"><font face="Arial,Helvetica" color=
"#FFFFFF"><big>People</big></font></a></td>
It is a general aim for boost libraries to be
<a href="lib_guide.htm#Portability">portable</a>. The primary means
for achieving this goal is to adhere to ISO Standard C++. However,
ISO C++ is a broad and complex standard and most compilers are
not fully conformant to ISO C++ yet. In order to achieve portability
in the light of this restriction, it seems advisable to get acquainted
with those language features that some compilers do not fully
implement yet.
<p>
<td><a href="faq.htm"><font face="Arial,Helvetica" color=
"#FFFFFF"><big>FAQ</big></font></a></td>
This page gives portability hints on some language features of the
Borland C++ version 5.5.1 compiler. Furthermore, the appendix
presents additional problems with Borland C++ version 5.5. Borland
C++ 5.5.1 is a freely available command-line compiler for Win32
available at
<a href="http://www.borland.com/">http://www.borland.com/</a>.
<p>
<td><a href="index.htm"><font face="Arial,Helvetica" color=
"#FFFFFF"><big>More</big></font></a></td>
</tr>
</table>
Each entry in the following list describes a particular issue,
complete with sample source code to demonstrate the effect.
Most sample code herein has been verified to compile with gcc 2.95.2
and Comeau C++ 4.2.44.
<h1>Portability Hints: Borland C++ 5.5.1</h1>
<p>It is a general aim for boost libraries to be <a href=
"lib_guide.htm#Portability">portable</a>. The primary means for achieving
this goal is to adhere to ISO Standard C++. However, ISO C++ is a broad and
complex standard and most compilers are not fully conformant to ISO C++
yet. In order to achieve portability in the light of this restriction, it
seems advisable to get acquainted with those language features that some
compilers do not fully implement yet.</p>
<h2>Preprocessor symbol</h2>
<p>This page gives portability hints on some language features of the
Borland C++ version 5.5.1 compiler. Furthermore, the appendix presents
additional problems with Borland C++ version 5.5. Borland C++ 5.5.1 is a
freely available command-line compiler for Win32 available at <a href=
"http://www.borland.com/">http://www.borland.com/</a>.</p>
The preprocessor symbol <code>__BORLANDC__</code> is defined for all
Borland C++ compilers. Its value is the version number of the
compiler interpreted as a hexadecimal number. The following table
lists some known values.
<p>
<p>Each entry in the following list describes a particular issue, complete
with sample source code to demonstrate the effect. Most sample code herein
has been verified to compile with gcc 2.95.2 and Comeau C++ 4.2.44.</p>
<table border="1">
<tr>
<th>Compiler</th>
<th><code>__BORLANDC__</code> value</th>
</tr>
<h2>Preprocessor symbol</h2>
<tr>
<td>Borland C++ Builder 4</td>
<td>0x0540</td>
</tr>
<p>The preprocessor symbol <code>__BORLANDC__</code> is defined for all
Borland C++ compilers. Its value is the version number of the compiler
interpreted as a hexadecimal number. The following table lists some known
values.</p>
<tr>
<td>Borland C++ Builder 5</td>
<td>0x0550</td>
</tr>
<table border="1" summary="">
<tr>
<th>Compiler</th>
<tr>
<td>Borland C++ 5.5</td>
<td>0x0550</td>
</tr>
<th><code>__BORLANDC__</code> value</th>
</tr>
<tr>
<td>Borland C++ 5.5.1</td>
<td>0x0551</td>
</tr>
<tr>
<td>Borland C++ Builder 4</td>
<tr>
<td>Borland C++ Builder 6</td>
<td>0x0560</td>
</tr>
<td>0x0540</td>
</tr>
</table>
<tr>
<td>Borland C++ Builder 5</td>
<h2>Core Language</h2>
<td>0x0550</td>
</tr>
<h3>[using-directive] Mixing <code>using</code>-declarations and
<code>using</code>-directives</h3>
<tr>
<td>Borland C++ 5.5</td>
Mixing <code>using</code>-directives (which refer to whole namespaces)
and namespace-level <code>using</code>-declarations (which refer to
individual identifiers within foreign namespaces) causes ambiguities
where there are none. The following code fragment illustrates this:
<td>0x0550</td>
</tr>
<pre>
<tr>
<td>Borland C++ 5.5.1</td>
<td>0x0551</td>
</tr>
<tr>
<td>Borland C++ Builder 6</td>
<td>0x0560</td>
</tr>
</table>
<h2>Core Language</h2>
<h3>[using-directive] Mixing <code>using</code>-declarations and
<code>using</code>-directives</h3>
<p>Mixing <code>using</code>-directives (which refer to whole namespaces)
and namespace-level <code>using</code>-declarations (which refer to
individual identifiers within foreign namespaces) causes ambiguities where
there are none. The following code fragment illustrates this:</p>
<pre>
namespace N {
int x();
}
@@ -111,15 +119,13 @@ int main()
}
</pre>
<h3>[using template] <code>using</code>-declarations for class
templates</h3>
<h3>[using template] <code>using</code>-declarations for class
templates</h3>
Identifiers for class templates can be used as arguments to
<code>using</code>-declarations as any other identifier. However, the
following code fails to compile with Borland C++:
<pre>
<p>Identifiers for class templates can be used as arguments to
<code>using</code>-declarations as any other identifier. However, the
following code fails to compile with Borland C++:</p>
<pre>
template&lt;class T&gt;
class X { };
@@ -130,14 +136,12 @@ namespace N
};
</pre>
<h3>[template const arg] Deduction of constant arguments to function
templates</h3>
<h3>[template const arg] Deduction of constant arguments to function
templates</h3>
Template function type deduction should omit top-level constness.
However, this code fragment instantiates "f&lt;const int&gt;(int)":
<pre>
<p>Template function type deduction should omit top-level constness.
However, this code fragment instantiates "f&lt;const int&gt;(int)":</p>
<pre>
template&lt;class T&gt;
void f(T x)
{
@@ -155,13 +159,11 @@ int main()
}
</pre>
<h3>[function address] Resolving addresses of overloaded functions</h3>
<h3>[function address] Resolving addresses of overloaded
functions</h3>
Addresses of overloaded functions are not in all contexts properly
resolved (std:13.4 [over.over]); here is a small example:
<pre>
<p>Addresses of overloaded functions are not in all contexts properly
resolved (std:13.4 [over.over]); here is a small example:</p>
<pre>
template&lt;class Arg&gt;
void f( void(*g)(Arg) );
@@ -188,17 +190,16 @@ int main()
}
</pre>
<strong>Workaround:</strong> Always use C-style casts when determining
addresses of (potentially) overloaded functions.
<p><strong>Workaround:</strong> Always use C-style casts when determining
addresses of (potentially) overloaded functions.</p>
<h3>[string conversion] Converting <code>const char *</code> to
<code>std::string</code></h3>
<h3>[string conversion] Converting <code>const char *</code> to
<code>std::string</code></h3>
Implicitly converting <code>const char *</code> parameters to
<code>std::string</code> arguments fails if template functions are
explicitly instantiated (it works in the usual cases, though):
<pre>
<p>Implicitly converting <code>const char *</code> parameters to
<code>std::string</code> arguments fails if template functions are
explicitly instantiated (it works in the usual cases, though):</p>
<pre>
#include &lt;string&gt;
template&lt;class T&gt;
@@ -212,22 +213,19 @@ int main()
</pre>
<strong>Workaround:</strong> Avoid explicit template function
instantiations (they have significant problems with Microsoft Visual
C++) and pass default-constructed unused dummy arguments with the
appropriate type. Alternatively, if you wish to keep to the explicit
instantiation, you could use an explicit conversion to
<code>std::string</code> or declare the template function as taking a
<code>const char *</code> parameter.
<p><strong>Workaround:</strong> Avoid explicit template function
instantiations (they have significant problems with Microsoft Visual C++)
and pass default-constructed unused dummy arguments with the appropriate
type. Alternatively, if you wish to keep to the explicit instantiation, you
could use an explicit conversion to <code>std::string</code> or declare the
template function as taking a <code>const char *</code> parameter.</p>
<h3>[template value defaults] Dependent default arguments for template
value parameters</h3>
<h3>[template value defaults] Dependent default arguments for template
value parameters</h3>
Template value parameters which default to an expression dependent on
previous template parameters don't work:
<pre>
<p>Template value parameters which default to an expression dependent on
previous template parameters don't work:</p>
<pre>
template&lt;class T&gt;
struct A
{
@@ -245,33 +243,29 @@ int main()
</pre>
<p><strong>Workaround:</strong> If the relevant non-type template parameter
is an implementation detail, use inheritance and a fully qualified
identifier (for example, ::N::A&lt;T&gt;::value).</p>
<strong>Workaround:</strong> If the relevant non-type template
parameter is an implementation detail, use inheritance and a fully
qualified identifier (for example, ::N::A&lt;T&gt;::value).
<h3>[function partial ordering] Partial ordering of function templates</h3>
<h3>[function partial ordering] Partial ordering of function
templates</h3>
Partial ordering of function templates, as described in std:14.5.5.2
[temp.func.order], does not work:
<pre>
<p>Partial ordering of function templates, as described in std:14.5.5.2
[temp.func.order], does not work:</p>
<pre>
#include &lt;iostream&gt;
template&lt;class T&gt; struct A {};
template&lt;class T1&gt;
void f(const A&lt;T1&gt; &)
void f(const A&lt;T1&gt; &amp;)
{
std::cout << "f(const A&lt;T1&gt;&)\n";
std::cout &lt;&lt; "f(const A&lt;T1&gt;&amp;)\n";
}
template&lt;class T&gt;
void f(T)
{
std::cout << "f(T)\n";
std::cout &lt;&lt; "f(T)\n";
}
int main()
@@ -282,16 +276,16 @@ int main()
}
</pre>
<strong>Workaround:</strong> Declare all such functions uniformly as
either taking a value or a reference parameter.
<p><strong>Workaround:</strong> Declare all such functions uniformly as
either taking a value or a reference parameter.</p>
<h3>[instantiate memfun ptr] Instantiation with member function
pointer</h3>
<h3>[instantiate memfun ptr] Instantiation with member function pointer</h3>
When directly instantiating a template with some member function
pointer, which is itself dependent on some template parameter, the
compiler cannot cope:
<pre>
<p>When directly instantiating a template with some member function
pointer, which is itself dependent on some template parameter, the compiler
cannot cope:</p>
<pre>
template&lt;class U&gt; class C { };
template&lt;class T&gt;
class A
@@ -300,9 +294,9 @@ class A
};
</pre>
<strong>Workaround:</strong> Use an intermediate <code>typedef</code>:
<pre>
<p><strong>Workaround:</strong> Use an intermediate
<code>typedef</code>:</p>
<pre>
template&lt;class U&gt; class C { };
template&lt;class T&gt;
class A
@@ -312,20 +306,16 @@ class A
};
</pre>
(Extracted from e-mail exchange of David Abrahams, Fernando Cacciola,
and Peter Dimov; not actually tested.)
<p>(Extracted from e-mail exchange of David Abrahams, Fernando Cacciola,
and Peter Dimov; not actually tested.)</p>
<h2>Library</h2>
<h2>Library</h2>
<h3>[cmath.abs] Function <code>double std::abs(double)</code> missing</h3>
<h3>[cmath.abs] Function <code>double std::abs(double)</code>
missing</h3>
The function <code>double std::abs(double)</code> should be defined
(std:26.5-5 [lib.c.math]), but it is not:
<pre>
<p>The function <code>double std::abs(double)</code> should be defined
(std:26.5-5 [lib.c.math]), but it is not:</p>
<pre>
#include &lt;cmath&gt;
int main()
@@ -334,40 +324,39 @@ int main()
}
</pre>
Note that <code>int std::abs(int)</code> will be used without warning
if you write <code>std::abs(5.1)</code>.
<p>
Similar remarks apply to seemingly all of the other standard math
functions, where Borland C++ fails to provide <code>float</code> and
<code>long double</code> overloads.
<p>
<strong>Workaround:</strong> Use <code>std::fabs</code> instead if
type genericity is not required.
<p>Note that <code>int std::abs(int)</code> will be used without warning if
you write <code>std::abs(5.1)</code>.</p>
<h2>Appendix: Additional issues with Borland C++ version 5.5</h2>
<p>Similar remarks apply to seemingly all of the other standard math
functions, where Borland C++ fails to provide <code>float</code> and
<code>long double</code> overloads.</p>
These issues are documented mainly for historic reasons. If you are
still using Borland C++ version 5.5, you are strongly encouraged to
obtain an upgrade to version 5.5.1, which fixes the issues described
in this section.
<p><strong>Workaround:</strong> Use <code>std::fabs</code> instead if type
genericity is not required.</p>
<h3>[inline friend] Inline friend functions in template classes</h3>
<h2>Appendix: Additional issues with Borland C++ version 5.5</h2>
If a friend function of some class has not been declared before the
friend function declaration, the function is declared at the namespace
scope surrounding the class definition. Together with class templates
and inline definitions of friend functions, the code in the following
fragment should declare (and define) a non-template function "bool
N::f(int,int)", which is a friend of class N::A&lt;int&gt;. However,
Borland C++ v5.5 expects the function f to be declared beforehand:
<p>These issues are documented mainly for historic reasons. If you are
still using Borland C++ version 5.5, you are strongly encouraged to obtain
an upgrade to version 5.5.1, which fixes the issues described in this
section.</p>
<pre>
<h3>[inline friend] Inline friend functions in template classes</h3>
<p>If a friend function of some class has not been declared before the
friend function declaration, the function is declared at the namespace
scope surrounding the class definition. Together with class templates and
inline definitions of friend functions, the code in the following fragment
should declare (and define) a non-template function "bool N::f(int,int)",
which is a friend of class N::A&lt;int&gt;. However, Borland C++ v5.5
expects the function f to be declared beforehand:</p>
<pre>
namespace N {
template&lt;class T&gt;
class A
{
// "f is not a member of 'N' in function main()"
friend bool f(T x, T y) { return x < y; }
friend bool f(T x, T y) { return x &lt; y; }
};
}
@@ -377,19 +366,29 @@ int main()
}
</pre>
This technique is extensively used in boost/operators.hpp. Giving in
to the wish of the compiler doesn't work in this case, because then
the "instantiate one template, get lots of helper functions at
namespace scope" approach doesn't work anymore. Defining
BOOST_NO_OPERATORS_IN_NAMESPACE (a define
BOOST_NO_INLINE_FRIENDS_IN_CLASS_TEMPLATES would match this case
better) works around this problem and leads to another one, see
[using-template].
<p>This technique is extensively used in boost/operators.hpp. Giving in to
the wish of the compiler doesn't work in this case, because then the
"instantiate one template, get lots of helper functions at namespace scope"
approach doesn't work anymore. Defining BOOST_NO_OPERATORS_IN_NAMESPACE (a
define BOOST_NO_INLINE_FRIENDS_IN_CLASS_TEMPLATES would match this case
better) works around this problem and leads to another one, see
[using-template].</p>
<hr>
<p>
<p><a href="http://validator.w3.org/check?uri=referer"><img border="0" src=
"http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional"
height="31" width="88"></a></p>
<hr>
<p>Revised
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->03
December, 2006<!--webbot bot="Timestamp" endspan i-checksum="38512" --></p>
2000-09-30 <a href="../people/jens_maurer.htm">Jens Maurer</a>
<p><i>Copyright &copy; 2000-2002 <a href="../people/jens_maurer.htm">Jens
Maurer</a></i></p>
<p><i>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">http://www.boost.org/LICENSE_1_0.txt</a>)</i></p>
</body>
</html>