[boost] Possible defect macros for BCB for config.hpp

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-05-12 08:08:24

Hi all.

The following is a quite long posting, as it describes a couple of defect
macros for Borland C++ Builder 6.0, with test cases, that might be added to
config.hpp.

I'm currently working on making Loki more portable (I'm working on a port to
Borland C++ Builder, for one thing), and I've read the mentioned config.hpp
docs, to be able to make it portable the Boost way.

This should also make it easier to use with Boost, and easier to submit to
Boost, too, should it come to that.

During the course of this, I've come across some idiosyncracies (which seems
to be the polite word for standards noncompliance) in BCB 6.0, which appear
to not have corresponding macros in config.hpp, or the borland.hpp compiler
configuration.

Following the advice in the docs for config.hpp, I'm posting test cases
here, and invite feedback.

As far as I know, this should be legal C++, as it's used in Loki. It also
works on Intel C++ 6.0, which I'm using as a kind of reference.

I could of course check for __BORLANDC__, which I do now, but I feel that
more descriptive terms can be better, as this documents in the code what is
intended, and it may be changed later, if later versions work, thus giving a
more fine grained control than checking for compiler or version, alone.
Besides, it may be things that occur in other compilers, as well.

Case 1 - Partial specialization problem
------------------------------------------------------

#include <vector>

template<class T1,class T2>
class Test
{
};

template<class T1,class T2>
class Test<std::vector<T1>,T2>
{
};

template<class T>
class Test<std::vector<int>,T>
{
};

int main()
{
Test<std::vector<int>,double> v; // [1]
}

------------------------------------------------------

[1] Error - E2295 Too many candidate template specializations from
'Test<T1,T2>'

It's unable to differentiate between the two specializations, claiming they
are eqally good matches, which is wrong.

If a template with just one parameter is used, then it works. Therefore, T2
is in the example, too.

If a macro is added to describe this, then this may for example be called
BOOST_NO_DEPENDENT_SPECIALIZATION.

Another problem with BCB is its handling of non-type template parameters.
This appears to not be mentioned in config.hpp or borland.hpp, either.

Like I said, I could use __BORLANDC__, but it appears that Boost code
prefers to use the config.hpp macros, instead of compiler specific macros.

The problems with non-type parameters was harder to pin down. The following
is the simplest example I could come up with, to demonstrate it:

Case 2 - Non-type parameter problem
-----------------------------------------------------

#include <iostream>

template<bool flag>
struct If
{
typedef char Result;
};

template<>
struct If<false>
{
typedef char Result[2];
};

struct TestHelper
{
enum { value=1 };
};

template<class T>
struct Test
{
enum { index=TestHelper::value };

typedef typename If<index!=0>::Result Result;
};

int main()
{
if(sizeof(Test<char>::Result)==sizeof(char))
  std::cout << "Passed\n";
else
  std::cout << "Failed\n";

char n;

std::cin >> std::noskipws >> n;
}

-----------------------------------------------------

Again, this works on Intel C++.

Even doing a minor change in the above, makes it work on BCB, too. For
example, replacing TestHelper::value with 1. However, in real code, this may
not be possible to do. This is just to demonstrate it in the simplest way.
The above is also the kind of code that is used in Loki, and I had to make
workarounds for it.

I don't really know what to call this, as it may well be BCB specific, so
one could have a parallel to the  "BOOST_MSVC6_MEMBER_TEMPLATES", something
like:

BOOST_BCB6_NONTYPE_PARAMETERS

However, this implies an additional feature, and not a missing one.

I feel that BOOST_NO_NONTYPE_PARAMETERS, in combination with the above one,
could be an overkill, too. After all, it supports non-type parameters. It's
just that in more complex situations (typical in metaprogramming), it
doesn't work.

By the way, these insights may be useful for porting other libraries to BCB,
as well.

Regards,

Terje