(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. 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. 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::type Selector; Splitting this up into typedef typename is_default<Arg>::type is_default; typedef typename choose_arg_or_default::type Selector; seemed to keep the compiler from getting itself all screwed up. 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. George Heintzelman georgeh@aya.yale.edu