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

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-05-13 16:29:34

>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. :) )

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.

>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").

>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...)

Thanks, I'd like that. :) My email address is given in the posting.

I've read the MPL paper, and also read the preliminary docs for it. I also
think is an impressive library, so I have a live and let live attitude to
this, regarding both Loki and MPL. :) It seems that both has appeal.

I've also learned about the mentioned integer-is-type handling from MPL, and
has actually used it to get around the non-type parameter problems in BCC.
I'd still be interested in seeing your notes.

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

Right. I did it for one part there, but not the other.

Regards,

Terje