Re: [boost] Porting to Borland C++ (was: Possible defect macros for BCB for config.hpp)

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

Ok.

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

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.

Regards,

Terje