Changes between Initial Version and Version 1 of Guidelines/Borland

Timestamp:

Feb 14, 2010, 12:21:08 PM (13 years ago)

Author:

Daniel James

Comment:

--

Guidelines/Borland

@@ +1 @@
+[[PageOutline]]
+
+= Portability Hints: Borland C++ 5.5.1 = #intro
+
+It is a general aim for boost libraries to be
+[wiki:Guidelines/Requirements#Portability portable]. 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.
+
+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 http://www.borland.com/.
+
+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.
+
+== Preprocessor symbol == #preprocessor
+
+The preprocessor symbol `__BORLANDC__` 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.
+
+||Compiler                 ||`__BORLANDC__` value||
+||Borland C++ Builder 4    ||0x0540              ||
+||Borland C++ Builder 5    ||0x0550              ||
+||Borland C++ 5.5          ||0x0550              ||
+||Borland C++ 5.5.1        ||0x0551              ||
+||Borland C++ Builder 6    ||0x0560              ||
+
+== Core Language == #core
+
+=== [using-directive] Mixing `using`-declarations and `using`-directives === #using-directive
+
+Mixing `using`-directives (which refer to whole
+namespaces) and namespace-level `using`-declarations
+(which refer to individual identifiers within foreign
+namespaces) causes ambiguities where there are none. The
+following code fragment illustrates this:
+{{{
+namespace N {
+    int x();
+}
+
+using N::x;
+using namespace N;
+
+int main()
+{
+    &x;     // Ambiguous overload
+}
+}}}
+
+=== [using template] `using`-declarations for class templates === #using-template
+
+Identifiers for class templates can be used as arguments to
+`using`-declarations as any other identifier.
+However, the following code fails to compile with Borland
+C++:
+{{{
+template<class T>
+class X { };
+
+namespace N
+{
+    // "cannot use template 'X<T>' without specifying specialization parameters"
+    using ::X;
+};
+}}}
+
+=== [template const arg] Deduction of constant arguments to function templates === #template-const-arg
+
+Template function type deduction should omit top-level
+constness. However, this code fragment instantiates "f<const int>(int)":
+{{{
+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);
+}
+}}}
+
+=== [function address] Resolving addresses of overloaded functions === #function-address
+
+Addresses of overloaded functions are not in all contexts
+properly resolved (std:13.4 [over.over]); here is a small
+example:
+{{{
+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)
+}
+}}}
+
+'''Workaround:''' Always use C-style casts when
+determining addresses of (potentially) overloaded
+functions.
+
+=== [string conversion] Converting `const char *` to `std::string` === #string-conversion
+
+Implicitly converting `const char *` parameters
+to `std::string` arguments fails if template
+functions are explicitly instantiated (it works in the usual
+cases, though):
+{{{
+#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 *)"
+}
+
+}}}
+
+'''Workaround:''' 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 `std::string` or declare the
+template function as taking a `const char *`
+parameter.
+
+=== [template value defaults] Dependent default arguments for template value parameters === #template-value-defaults
+
+Template value parameters which default to an expression
+dependent on previous template parameters don't work:
+{{{
+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;
+}
+}}}
+
+'''Workaround:''' If the relevant non-type
+template parameter is an implementation detail, use inheritance
+and a fully qualified identifier (for example,
+::N::A<T>::value).
+
+=== [function partial ordering] Partial ordering of function templates === #function-partial-ordering
+
+Partial ordering of function templates, as described in
+std:14.5.5.2 [temp.func.order], does not work:
+{{{
+#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)
+}
+}}}
+
+'''Workaround:''' Declare all such functions
+uniformly as either taking a value or a reference
+parameter.
+
+=== [instantiate memfun ptr] Instantiation with member function pointer === #instantiate-memfun-ptr
+
+When directly instantiating a template with some member
+function pointer, which is itself dependent on some template
+parameter, the compiler cannot cope:
+
+{{{
+template<class U> class C { };
+template<class T>
+class A
+{
+    static const int v = C<void (T::*)()>::value;
+};
+}}}
+
+'''Workaround:''' Use an intermediate `typedef`:
+{{{
+template<class U> class C { };
+template<class T>
+class A
+{
+    typedef void (T::*my_type)();
+    static const int v = C<my_type>::value;
+};
+}}}
+
+(Extracted from e-mail exchange of David Abrahams, Fernando
+Cacciola, and Peter Dimov; not actually tested.)
+
+== Library == #library
+
+=== [cmath.abs] Function `double std::abs(double)` missing === #cmath-abs
+
+The function `double std::abs(double)` should be
+defined (std:26.5-5 [lib.c.math]), but it is not:
+{{{
+#include <cmath>
+
+int main()
+{
+    double (*p)(double) = std::abs;  // error
+}
+}}}
+
+Note that `int std::abs(int)` will be used
+without warning if you write `std::abs(5.1)`.
+
+Similar remarks apply to seemingly all of the other standard
+math functions, where Borland C++ fails to provide
+`float` and `long double` overloads.
+
+'''Workaround:''' Use `std::fabs` instead if type genericity is not required.
+
+== Appendix: Additional issues with Borland C++ version 5.5 == #5.5-issues
+
+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.
+
+=== [inline friend] Inline friend functions in template classes === #inline-friend
+
+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:
+{{{
+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;
+}
+}}}
+
+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].