[Boost-Users] Re: Compile error with boost::tokenizer and Forte 6U2

From: rogeeff (rogeeff_at_[hidden])
Date: 2001-12-18 15:16:54

--- In boost_at_y..., George Heintzelman <georgeh_at_a...> wrote:
> 
> (moved to boost developers list)
> 
> [snip most of the changes for SunPro CC]
> 
> > Also ifdef BOOST_STATIC_ASSERTs on is_input_or_output_iter and 
> > forward_iter_with_real_reference (~lines 616-630). 
> 
> Whoa Nelly. I also found most of the changes you suggested, but I 
> looked into these assert failures compiling on SunPro 5.3 -- and I 
> found that they really were indicating that the compiler was doing 
> something wrong with the typedefs inside the constructed iterator. 
> Ignoring the problem by #ifdefing these out I think may cause 
problems 
> with the iterator adaptors in some contexts, though I think they 
will 
> probably work correctly for simple dereferencing and incrementing.

All examples, token_iterator and everywhere where I am using 
iterator_adaptors,  it's working properly.

> 
> To fix (at least partly) these, I found I needed to turn on some of 
the 
> hacks for BORLANDC in the detail/named_template_params header, 
> specifically the ones to use
> type_traits::yes_type instead of a bool specialization.  I also 
needed 
> to turn on BOOST_BUGGY_INTEGRAL_CONSTANT_EXPRESSIONS for the 
> static_assert header; I suspect the BORLANDC #ifdefs I had to turn 
on 
> are related to this same problem, and they ought to be unified in 
the 
> config header.

Sure. I forgot to mention that. SunPro 5.3 still does not support ANY 
expression with non-type parameters. And it seems that it also have 
some other problems with them.

> 
> Once that was done, the compiler still got itself quite confused 
> by the line in detail/named_template_params.hpp:
>       typedef typename choose_arg_or_default<typename 
is_default<Arg>
> ::type>::type Selector;
> Splitting this up into
>       typedef typename is_default<Arg>::type is_default;
>       typedef typename choose_arg_or_default<is_default>::type 
Selector;
> seemed to keep the compiler from getting itself all screwed up.

It was already implemented this way in 1.25.0

> 
> This got me part of the way there, but one of those two 
Static_asserts 
> was still firing, and it seemed to me correctly so (that is, 
correctly 
> in that the compiler was behaving incorrectly elsewhere). I came to 
the 
> conclusion that it was still the same buggy integral constant 
> specialization problem -- if I were to rewrite some of the selector 
> code to use yes_type instead of a bool specialization, I believe I 
> could get it to work, but given that that would have meant some 
> wholesale changes to type_traits, I stopped there.

I made majority of type_traits working either. Without to much 
efforts ( with using of partial specialization)

> 
> George Heintzelman
> georgeh_at_a...

Gennadiy.

P.S. By the way: I was not able to answer to you ealier cause my 
SunPro compiler got screwed.  The trivial program like this causes a 
core dump:

int main()
{
   try {
     throw 1;
   }
   catch(...) {
   }
   return 0;
}

It does not seem to catch an exception. Did you meet such weird thing?
HELP please!