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!