[boost] [mpl][tru64cxx] set still failing

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2005-06-22 05:30:41

Hello again,

Despite recent changes by Dave Abrahams, mpl::set is still
failing in tru64cxx as shown in the last regression cycle:

http://tinyurl.com/9qzuh

(Dave's works weren't intended to tackle this issue anyway,
so this comes as no surprise.)
The reason for the regression lies in recent changes to the
associated toolset jam setting strict_ansi mode compilation.
The offending code is:

        BOOST_STATIC_CONSTANT(bool, value =
              ( sizeof( BOOST_MPL_AUX_OVERLOAD_CALL_IS_MASKED(
                    Set
                  , BOOST_MPL_AUX_STATIC_CAST(aux::type_wrapper<T>*, 0)
                  ) ) == sizeof(aux::no_tag) )
            );

and the error message goes like "NULL reference is not allowed".
Digging deeper, I'm pretty sure the problem has to do with tru64cxx not
accepting selected implementation of BOOST_MPL_AUX_PTR_TO_REF
in boost/mpl/aux_/ptr_to_ref.hpp when the pointer passed is null.
There are two alternative implementations of this macro:

1. (MSVC, EDG)
#   define BOOST_MPL_AUX_PTR_TO_REF(X) \
    *BOOST_MPL_AUX_STATIC_CAST(X*, 0) \
/**/

2. (remaining compilers)
#   define BOOST_MPL_AUX_PTR_TO_REF(X) \
    aux::ptr_to_ref(BOOST_MPL_AUX_STATIC_CAST(X*, 0)) \
/**/

tru64cxx, which is EDG-based, uses #1; it used to work OK, but
when strict_ansi mode was selected, the compiler didn't like #1 anymore.

So my questions are:

A. Is there any reason why EDG is forced to use implementation #1?
The CVS history doesn't shed much light about this.
B. If A is unavoidable, can we macro-detect strict ansi mode so as to
divert EDG+strict_ansi to implementation #2?
C. If B has negative answer, could we at least eliminate the null
pointer
in boost/mpl/aux_/ptr_to_ref.hpp (by using a dummy make_ptr function,
perhaps)?

Thank you,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo