|
|
@@ -0,0 +1,362 @@
|
|
|
+<html>
|
|
|
+<head>
|
|
|
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
|
+<title>Portability Hints: Borland C++ 5.5.1</title>
|
|
|
+</head>
|
|
|
+
|
|
|
+<body bgcolor="#FFFFFF" text="#000000">
|
|
|
+
|
|
|
+<table border="1" bgcolor="#007F7F" cellpadding="2">
|
|
|
+ <tr>
|
|
|
+ <td bgcolor="#FFFFFF"><img src="../c++boost.gif" alt="c++boost.gif (8819 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="../libraries.htm"><font face="Arial,Helvetica" color="#FFFFFF"><big>Libraries</big></font></a></td>
|
|
|
+ <td><a href="../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>
|
|
|
+
|
|
|
+<p>
|
|
|
+
|
|
|
+<h1>Portability Hints: Borland C++ 5.5.1</h1>
|
|
|
+
|
|
|
+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>
|
|
|
+
|
|
|
+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>
|
|
|
+
|
|
|
+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.
|
|
|
+
|
|
|
+
|
|
|
+<h2>Preprocessor symbol</h2>
|
|
|
+
|
|
|
+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>
|
|
|
+
|
|
|
+<table border="1">
|
|
|
+<tr>
|
|
|
+<th>Compiler</th>
|
|
|
+<th><code>__BORLANDC__</code> value</th>
|
|
|
+</tr>
|
|
|
+
|
|
|
+<tr>
|
|
|
+<td>Borland C++ Builder 4</td>
|
|
|
+<td>0x0540</td>
|
|
|
+</tr>
|
|
|
+
|
|
|
+<tr>
|
|
|
+<td>Borland C++ Builder 5</td>
|
|
|
+<td>0x0550</td>
|
|
|
+</tr>
|
|
|
+
|
|
|
+<tr>
|
|
|
+<td>Borland C++ 5.5</td>
|
|
|
+<td>0x0550</td>
|
|
|
+</tr>
|
|
|
+
|
|
|
+<tr>
|
|
|
+<td>Borland C++ 5.5.1</td>
|
|
|
+<td>0x0551</td>
|
|
|
+</tr>
|
|
|
+
|
|
|
+</table>
|
|
|
+
|
|
|
+<h2>Core Language</h2>
|
|
|
+
|
|
|
+<h3>[using-directive] Mixing <code>using</code>-declarations and
|
|
|
+<code>using</code>-directives</h3>
|
|
|
+
|
|
|
+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:
|
|
|
+
|
|
|
+<pre>
|
|
|
+namespace N {
|
|
|
+ int x();
|
|
|
+}
|
|
|
+
|
|
|
+using N::x;
|
|
|
+using namespace N;
|
|
|
+
|
|
|
+int main()
|
|
|
+{
|
|
|
+ &x; // Ambiguous overload
|
|
|
+}
|
|
|
+</pre>
|
|
|
+
|
|
|
+
|
|
|
+<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>
|
|
|
+template<class T>
|
|
|
+class X { };
|
|
|
+
|
|
|
+namespace N
|
|
|
+{
|
|
|
+ // "cannot use template 'X<T>' without specifying specialization parameters"
|
|
|
+ using ::X;
|
|
|
+};
|
|
|
+</pre>
|
|
|
+
|
|
|
+
|
|
|
+<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<const int>(int)":
|
|
|
+
|
|
|
+<pre>
|
|
|
+template<class T>
|
|
|
+void f(T x)
|
|
|
+{
|
|
|
+ x = 1; // works
|
|
|
+ (void) &x;
|
|
|
+ T y = 17;
|
|
|
+ y = 20; // "Cannot modify a const object in function f<const int>(int)"
|
|
|
+ (void) &y;
|
|
|
+}
|
|
|
+
|
|
|
+int main()
|
|
|
+{
|
|
|
+ const int i = 17;
|
|
|
+ f(i);
|
|
|
+}
|
|
|
+</pre>
|
|
|
+
|
|
|
+The boost/rational.hpp header exhibits this problem in connection with
|
|
|
+the gcd() function.
|
|
|
+
|
|
|
+
|
|
|
+<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>
|
|
|
+template<class Arg>
|
|
|
+void f( void(*g)(Arg) );
|
|
|
+
|
|
|
+void h(int);
|
|
|
+void h(double);
|
|
|
+
|
|
|
+template<class T>
|
|
|
+void h2(T);
|
|
|
+
|
|
|
+int main()
|
|
|
+{
|
|
|
+ void (*p)(int) = h; // this works (std:13.4-1.1)
|
|
|
+ void (*p2)(unsigned char) = h2; // this works as well (std:13.4-1.1)
|
|
|
+ f<int>(h2); // this also works (std:13.4-1.3)
|
|
|
+
|
|
|
+ // "Cannot generate template specialization from h(int)",
|
|
|
+ // "Could not find a match for f<Arg>(void (*)(int))"
|
|
|
+ f<double>(h); // should work (std:13.4-1.3)
|
|
|
+
|
|
|
+ f( (void(*)(double))h); // C-style cast works (std:13.4-1.6 with 5.4)
|
|
|
+
|
|
|
+ // "Overloaded 'h' ambiguous in this context"
|
|
|
+ f(static_cast<void(*)(double)>(h)); // should work (std:13.4-1.6 with 5.2.9)
|
|
|
+}
|
|
|
+</pre>
|
|
|
+
|
|
|
+<strong>Workaround:</strong> Always use C-style casts when determining
|
|
|
+addresses of (potentially) overloaded functions.
|
|
|
+
|
|
|
+<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>
|
|
|
+#include <string>
|
|
|
+
|
|
|
+template<class T>
|
|
|
+void f(const std::string & s)
|
|
|
+{}
|
|
|
+
|
|
|
+int main()
|
|
|
+{
|
|
|
+ f<double>("hello"); // "Could not find a match for f<T>(char *)"
|
|
|
+}
|
|
|
+
|
|
|
+</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.
|
|
|
+
|
|
|
+
|
|
|
+<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>
|
|
|
+template<class T>
|
|
|
+struct A
|
|
|
+{
|
|
|
+ static const bool value = true;
|
|
|
+};
|
|
|
+
|
|
|
+// "Templates must be classes or functions", "Declaration syntax error"
|
|
|
+template<class T, bool v = A<T>::value>
|
|
|
+struct B {};
|
|
|
+
|
|
|
+int main()
|
|
|
+{
|
|
|
+ B<int> x;
|
|
|
+}
|
|
|
+
|
|
|
+</pre>
|
|
|
+
|
|
|
+
|
|
|
+<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<T>::value).
|
|
|
+
|
|
|
+
|
|
|
+<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>
|
|
|
+#include <iostream>
|
|
|
+
|
|
|
+template<class T> struct A {};
|
|
|
+
|
|
|
+template<class T1>
|
|
|
+void f(const A<T1> &)
|
|
|
+{
|
|
|
+ std::cout << "f(const A<T1>&)\n";
|
|
|
+}
|
|
|
+
|
|
|
+template<class T>
|
|
|
+void f(T)
|
|
|
+{
|
|
|
+ std::cout << "f(T)\n";
|
|
|
+}
|
|
|
+
|
|
|
+int main()
|
|
|
+{
|
|
|
+ A<double> a;
|
|
|
+ f(a); // output: f(T) (wrong)
|
|
|
+ f(1); // output: f(T) (correct)
|
|
|
+}
|
|
|
+</pre>
|
|
|
+
|
|
|
+<strong>Workaround:</strong> Declare all such functions uniformly as
|
|
|
+either taking a value or a reference parameter.
|
|
|
+
|
|
|
+
|
|
|
+<h2>Library</h2>
|
|
|
+
|
|
|
+
|
|
|
+<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>
|
|
|
+#include <cmath>
|
|
|
+
|
|
|
+int main()
|
|
|
+{
|
|
|
+ double (*p)(double) = std::abs; // error
|
|
|
+}
|
|
|
+</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.
|
|
|
+
|
|
|
+<h2>Appendix: Additional issues with Borland C++ version 5.5</h2>
|
|
|
+
|
|
|
+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.
|
|
|
+
|
|
|
+<h3>[inline friend] Inline friend functions in template classes</h3>
|
|
|
+
|
|
|
+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<int>. However,
|
|
|
+Borland C++ v5.5 expects the function f to be declared beforehand:
|
|
|
+
|
|
|
+<pre>
|
|
|
+namespace N {
|
|
|
+template<class T>
|
|
|
+class A
|
|
|
+{
|
|
|
+ // "f is not a member of 'N' in function main()"
|
|
|
+ friend bool f(T x, T y) { return x < y; }
|
|
|
+};
|
|
|
+}
|
|
|
+
|
|
|
+int main()
|
|
|
+{
|
|
|
+ N::A<int> a;
|
|
|
+}
|
|
|
+</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>
|
|
|
+
|
|
|
+<hr>
|
|
|
+
|
|
|
+2000-09-30 <a href="../people/jens_maurer.htm">Jens Maurer</a>
|
|
|
+</body>
|
|
|
+</html>
|
Jens Maurer