|
Boost-Commit : |
From: daniel_james_at_[hidden]
Date: 2007-11-04 14:09:17
Author: danieljames
Date: 2007-11-04 14:09:16 EST (Sun, 04 Nov 2007)
New Revision: 40750
URL: http://svn.boost.org/trac/boost/changeset/40750
Log:
Add borland_cpp.html from the old site. Fixes #1258.
Added:
website/public_html/beta/development/borland_cpp.html (contents, props changed)
Added: website/public_html/beta/development/borland_cpp.html
==============================================================================
--- (empty file)
+++ website/public_html/beta/development/borland_cpp.html 2007-11-04 14:09:16 EST (Sun, 04 Nov 2007)
@@ -0,0 +1,423 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+<head>
+ <title>Portability Hints: Borland C++ 5.5.1</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
+ <link rel="icon" href="/favicon.ico" type="image/ico" />
+ <link rel="stylesheet" type="text/css" href=
+ "/style/section-development.css" />
+ <!--[if IE]> <style type="text/css"> body { behavior: url(/style/csshover.htc); } </style> <![endif]-->
+</head>
+
+<body>
+ <div id="heading">
+ <!--#include virtual="/common/heading.html" -->
+ </div>
+
+ <div id="body">
+ <div id="body-inner">
+ <div id="content">
+ <div class="section" id="intro">
+ <div class="section-0">
+ <div class="section-title">
+ <h1>Portability Hints: Borland C++ 5.5.1</h1>
+ </div>
+
+ <div class="section-body">
+ <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>
+
+ <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/>.</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>
+
+ <h2>Preprocessor symbol</h2>
+
+ <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>
+
+ <table border="1" summary="">
+ <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>
+
+ <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();
+}
+
+using N::x;
+using namespace N;
+
+int main()
+{
+ &x; // Ambiguous overload
+}
+</pre>
+
+ <h3>[using template] <code>using</code>-declarations for class
+ templates</h3>
+
+ <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<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>
+
+ <p>Template function type deduction should omit top-level
+ constness. However, this code fragment instantiates "f<const
+ int>(int)":</p>
+ <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>
+
+ <h3>[function address] Resolving addresses of overloaded
+ functions</h3>
+
+ <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<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>
+
+ <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>
+
+ <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 <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>
+
+ <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>
+
+ <p>Template value parameters which default to an expression
+ dependent on previous template parameters don't work:</p>
+ <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>
+
+ <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<T>::value).</p>
+
+ <h3>[function partial ordering] Partial ordering of function
+ templates</h3>
+
+ <p>Partial ordering of function templates, as described in
+ std:14.5.5.2 [temp.func.order], does not work:</p>
+ <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>
+
+ <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>
+
+ <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<class U> class C { };
+template<class T>
+class A
+{
+ static const int v = C<void (T::*)()>::value;
+};
+</pre>
+
+ <p><strong>Workaround:</strong> Use an intermediate
+ <code>typedef</code>:</p>
+ <pre>
+template<class U> class C { };
+template<class T>
+class A
+{
+ typedef void (T::*my_type)();
+ static const int v = C<my_type>::value;
+};
+</pre>
+
+ <p>(Extracted from e-mail exchange of David Abrahams, Fernando
+ Cacciola, and Peter Dimov; not actually tested.)</p>
+
+ <h2>Library</h2>
+
+ <h3>[cmath.abs] Function <code>double std::abs(double)</code>
+ missing</h3>
+
+ <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 <cmath>
+
+int main()
+{
+ double (*p)(double) = std::abs; // error
+}
+</pre>
+
+ <p>Note that <code>int std::abs(int)</code> will be used
+ without warning if you write <code>std::abs(5.1)</code>.</p>
+
+ <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>
+
+ <p><strong>Workaround:</strong> Use <code>std::fabs</code>
+ instead if type genericity is not required.</p>
+
+ <h2>Appendix: Additional issues with Borland C++ version
+ 5.5</h2>
+
+ <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>
+
+ <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<int>. However, Borland C++ v5.5 expects the function
+ f to be declared beforehand:</p>
+ <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>
+
+ <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>
+ </div>
+ </div>
+ </div>
+ </div>
+
+ <div id="sidebar">
+ <!--#include virtual="/common/sidebar-common.html" -->
+ <!--#include virtual="/common/sidebar-development.html" -->
+ </div>
+
+ <div class="clear"></div>
+ </div>
+ </div>
+
+ <div id="footer">
+ <div id="footer-left">
+ <div id="revised">
+ <p>Revised $Date: 2007-10-22 22:55:52 +0100 (Mon, 22 Oct 2007) $</p>
+ </div>
+
+ <div id="copyright">
+ <p>Copyright © 2000-2002 <a href=
+ "/users/people/jens_maurer.html">Jens Maurer</a></p>
+ </div><!--#include virtual="/common/footer-license.html" -->
+ </div>
+
+ <div id="footer-right">
+ <!--#include virtual="/common/footer-banners.html" -->
+ </div>
+
+ <div class="clear"></div>
+ </div>
+</body>
+</html>
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk