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
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
>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
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<
>BCC likes to choke on these details.
Right. I did it for one part there, but not the other.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk