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

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-12-18 15:44:09

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

I found that iterator_category, value_type, reference and pointer do 
not get always get defined correctly. I can't be more specific without 
going back into my work, as I didn't keep as good notes as I should 
have. I am not sure that the examples test this functionality. If you 
have can make a projection_iterator that gets these things defined 
correctly, I really want to see the changes you made for it. Be sure to 
check it for both iterator classes and for pointers...

> > 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, 
[snip]

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

It does "support" (as in, compile) the expressions with non-type 
parameters. Many things about them even work. It does seem to have some 
problems with specializing based on them, in my experience, though 
simple tests give correct answers.

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

    template <class Arg, class DefaultGen, class Base, class Traits>
    class resolve_default {
#if defined(__BORLANDC__)
      typedef typename choose_arg_or_default<typename is_default<Arg>
::type>::ty
pe Selector;
#else
      // This usually works for Borland, but I'm seeing weird errors in
      // iterator_adaptor_test.cpp when using this method.
      enum { is_def = is_default<Arg>::value };
      typedef typename choose_arg_or_default<is_def>::type Selector;
#endif

is what is in 1.25.0, and still in the CVS. In my changes, I selected 
the __BORLANDC__ branch here.

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

Nope, sorry. Seems to work correctly for me...

George Heintzelman
georgeh_at_[hidden]