[[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].


Copyright © 2000-2002 [http://www.boost.org/users/people/jens_maurer.html Jens Maurer]