From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-05-13 18:50:01
>From: Fernando Cacciola <fcacciola_at_[hidden]>
> >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
> >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
> 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
>> type-only code, where possible. I'll see how far this integer constant
>> 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
>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',
>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.
I understand. Maybe the safest bet, if the BCC compiler is detected, to use
type-only algorithms, where possible. It appears that wherever you use an
int, you can use a type instead, for it. There are some cases that makes
this hard to do, though, like use of sizeof. No matter what I've tried, I
haven't got a couple of algorithms that relies on Convertible (like
boost::is_convertible) to work, namely MostDerived, and DerivedToFront. I've
tried very hard to get these to work, but it appears that the integer
calculations messes it up, and sizeof returns an int.
>> >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 know, it really obfuscates the code a bit more than a bit :-)
However, a man's got to do what a man's got to do, I guess (or woman). :) At
least, all this will be hidden inside the library, and even if it may be
hard to understand, it makes it easier to use.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk