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

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-05-13 09:32:30

>From: John Maddock

> > If a macro is added to describe this, then this may for example be
called
> > BOOST_NO_DEPENDENT_SPECIALIZATION.
>
> Fair enough, but I'm not sure about the name - the specialisation isn't
> "dependent" in the usual sense (ie dependent upon another template
> parameter).

I know. :) However, I couldn't come up with a better one. Any suggestion?

This may well be a quite compiler-specific issue, so
BOOST_BCC_PARTIAL_SPECIALICATION could also work well (similar to
BOOST_MSVC6_MEMBER_TEMPLATES).

As only classes may be partially specialized, the above should be
unambiguous, without needing "CLASS_TEMPLATE" in addition, there.

> > 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.
>
> There's actually a small paper on this, as a number of compilers have
> problems in this area: have you looked at: "Coding Guidelines for Integral
> Constant Expressions" www.boost.org/more/int_const_guidelines.htm

Yes, I've read that one a while ago, and I'll read it again now, and apply
the principles, and see if it helps. It's a good thing I already have test
cases.

> > 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.
>
> Does the code work if you use BOOST_STATIC_CONST rather than enum's, and
> ::fully::qualified::names when referencing the values?  If following the
> coding guidelines works then we can probably live without the macro?

I almost hate to admit it, but using every trick in the book, uh, article,
:) it does actually work. Here's the new version:

--- Start example ---

#include "boost/config.hpp"
#include "boost/type_traits/ice.hpp"
#include <iostream>

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

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

struct TestHelper
{
BOOST_STATIC_CONSTANT(int,value=1);
};

template<class T>
struct Test
{
typedef typename If<boost::type_traits::ice_ne<
::TestHelper::value,0>::value>::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;
}

--- End example ---

No, it's not pretty, but it works. :)

Thanks for the help. :) I thought I had tried everything, but apparently
not.

I guess it's not the first time you experience something like this.

Ok, it appears there's no need for a special macro for this integer
handling. Problems with it appear to be quite common, and not just for BCC.

I also see that the ice.hpp header is your work. From the docs:

"Rationale: A number of compilers (particularly the Borland and Microsoft
compilers), tend to not to recognise integral constant expressions involving
logical operators as genuine integral constant expressions. The problem
generally only shows up when the integral constant expression is nested deep
inside template code, and is hard to reproduce and diagnose."

Indeed. That's exactly what I found. However, I thought there was no other
way than to e.g. try to convert integer operations to type operations, where
possible.

I'll use the detailed guidelines in that document for the continued porting.
I may be able to change some workarounds as a result of it, too.

Regards,

Terje