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

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-05-13 17:17:44

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

> >From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>
> > >From: John Maddock
> >
> > > 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*.
>
> Yes, I know. What's ICE, by the way? (Aside from the Boost library with
the
> same name. :) )
>
It stands for Internal Compiler Error. (that is, the compiler catching an
Access Violation or so within itself)

>
> That's why I, like I said in the previous posting, thought I'd have to use
> type-only code, where possible. I'll see how far this integer constant
code
> goes in BCC. If I could avoid having to use integer-is-type, it may be
> better, so I won't have to kind of simulate integers that way. It's
> different in a library like MPL, where they're supposed to be possible to
> use with the library components, that expects a type.
>
The real problem is that it is too complicated to *really* know how well
non-type template parameters work, since it usually appears to work within a
certain context, only to start ICEing the compiler when the same code is
used elsewhere. That is, you might get your port of Loki to work 'here', but
eventually someone would try it 'there' and it will give him a headache,
because he won't be able to realise what's choking the compiler unless he
really knows about these BCC subtelties.

> >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.
>
> I know. It's possible - MPL does it - and for MPL, it means you can treat
> integers and types uniformly. However, it also means, if you don't need
> that, that it tends to obfuscate the code a bit (like "next<i>::value",
> instead of "i+1").
>
I known, it really obfuscates the code a bit more than a bit :-)

Best,

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