[boost] Re: value_initialized, deep const, and template instantiation

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2004-01-28 10:56:53

Hi Him,

> value_initialized has non-deep (shallow?) const semantics. const
> value_initialized<T> is supposed to be const.  Unfortunately, due to
> compiler errors in VC++ and Borland, it has
>
> operator T &() const
>
> instead of
>
> operator T&()
> operator const T&() const
>
> which breaks const-correctness in a big way.
>
> I'd like for there to be a config macro that identifies this error.
>
> [snip]
>

Deep const semantics are definitely needed in value_init<>.

However, using a configuration macro to select the correct
version for non-broken compilers was considered and rejected
in order to avoid having two different compiler-dependent
versions of the same utility.

It would be very confusing if constantness semantics were to change
depending on the compiler.

This situation is unlike those cases were an interface has additional
methods enabled for better compilers, because in that case,
the additional methods are unavailable on lesser compiler
and so there is no behavioral ambiguity.

> For those compilers, I think there would be value to adding operator->
> for the invocation of member functions, like boost::optional.
>
I'm not sure.
operator-> generated a long discussion because of its implied pointer
semantics.
In the case of boost::optional<>, the possibility of the uninitialized
state is my corner argument in favot of it.
Yet with value_initialized<> I can't see any favorable argument.

FWIW, both the deep-const and the member access issues are solved
by the recommended interface:

value_initialized<X> const cx ;
get(cx).foo();

> As an alternative, deep-copy would break const expectations in generic
> functions that take a const T &, but it would preserve it elsewhere, so
> it may be worth some more thought.

Yes, though value_initalized is a value wrapper, so it must have deep-copy.

> Finally, I have come up with a similar class (which I wrote with deep
> const sematics, although I am open to argument about shallow const) for
> solving the following problem:
>
> ----------------------------------------------------------------------
> #include <iostream>
>
> template<typename T>
> struct wrap {
>    static const T joe;
> };
>
> template<typename T>
> const T wrap<T>::joe;
>
> struct call_out {
>    int num;
>    call_out() : num(77) {}
> };
>
> template<typename T>
> struct check_call {
>    check_call() {
>      std::cout << wrap<T>::joe.num << std::endl;
>    }
> };
>
> check_call<call_out> x;
>
> int main(){}
> -----------------------------------------------------------------------
>
> This outputs 0, not 77, on gcc 3.3.2, intel 8, and vc6. I don't know if
> that's correct, 14.7.1/1 says:
>
>
> "... in particular, the initialization (and any associated side effects)
> of a static data member does not occur unless the static data member is
> itself used in a way that requires the definition of the static data
> member to exist."
>

Interesting.... don't know if it is comforming or not.

> If this is std-conforming behavior, or not, i have a workaround that allows:
> ------------------------------------------------------------------------
> #include <iostream>
> #include "can_init.hpp"
>
>
> template<typename T>
> struct wrap {
>    static can_init<const T> joe;
> };
>
>
> template<typename T>
> can_init<const T> wrap<T>::joe;
>
>
> struct call_out {
>    int num;
>    call_out() : num(77) {}
> };
>
>
> template<typename T>
> struct check_call {
>    check_call() {
>      wrap<T>::joe.ensure_init();
>      std::cout << wrap<T>::joe->num << std::endl;
>    }
> };
>
>
> check_call<call_out> x;
>
>
> int main(){}
> -----------------------------------------------------------------------
> which obviously uses deep const. Is there any interest in including this
> in boost/utility/?

If you can guarantee proper initialization for any compiler were it is available,
I'd say yes, I'm interested.

> Should it have shallow or deep const semantics?
>
Deep const, as it is a value wrapper (and not a pointer wrapper)

HTH

Fernando Cacciola
SciSoft