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

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-05-13 15:30:55

----- Original Message -----
From: "Terje Slettebø" <tslettebo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, May 13, 2002 11:32 AM
Subject: Re: [boost] Possible defect macros for BCB for config.hpp

> >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:
>
>
Not so fast... :-(

Unfortunately, non-type template parameter support in BCC<=5.5 is so poor
that you might get a piece of code to compile on a small testbed, but then,
once you use it in some context, bcc starts to ICE in *totaly unrelated
code*. This sort of bug is very annoying because the user might end up
haunting bugs in her code while the real problem is in some non-type
template parameter farther up in the include chain.
I've seen this many times, particularly in code which uses complex (well,
not at all complex) expressions to set values of integral constant
expressions involving non-type template parameters.

I don't know about BCC5.6 (BCB6),  but I suspect it is just the same...

Bothering as it is, the safest thing -though the hardest to code- is to
completely avoid non-type parameters.

If you want, I can send you privately some meta programming tools and sample
usage code to ease handling of type parameters which actually carry values.
(or you can take a close look at mpl, from were I borrowed the
techniques...)

> --- 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;
> };
>
Just a note: remember that a 'full' qualification starts with '::', so the
code should be:

typedef typename If< ::boost::type_traits::ice_ne<
::TestHelper::value,0>::value>::Result Result;

BCC likes to choke on these details.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com