|
Boost : |
From: Eric Friedman (ebf_at_[hidden])
Date: 2003-04-07 19:36:26
Gennadiy Rozental wrote:
> > typedef boost::variant<int const, std::string const> GlobalParameter;
> > GlobalParameter input_socket(12345);
> > input_socket = "test"; // no way to prevent this
> >
> > // ...or if that doesn't convince you...
> > GlobalParameter new_input_socket("test");
> > input_socket = new_input_socket; // no way to prevent this either
> >
> Let's return to the very begining of this thread:
> http://aspn.activestate.com/ASPN/Mail/Message/1593371
>
> Did I correctly undetand the reson why you think you could not revent
above
> assignment?
>
> If yes, my proposition is to put following code in the assignment operator
> ( and all other mutating operators like copy assignment above):
>
> BOOST_STATIC_ASSERT( !boost::is_const<T>::value );
>
> That should prevent user from trying to use assignment operators for the
> variant parameterized with const types.
First I want to make clear that my objection to your proposal has absolutely
nothing to do with any *technical* difficulties.
Rather, I argue your proposal is logically incoherent. You propose that
variant may be defined with const types. For example,
variant<int const, std::string const>
I do not see how the semantics of such a type might reasonably differ in any
way whatsoever from the following "natural" syntax:
variant<int, std::string> const
Peter Dimov noted this as well
(http://aspn.activestate.com/ASPN/Mail/Message/1594864). Further, I'm not
sure why you would *want* such semantics.
The other suggestion I think your proposal contains is to give meaning to
the case where not every parameterized types is const. For example,
typedef variant<int const, std::string> gvar;
It is this point I have argued against in my previous email messages. I
argue that no consistent semantics exist for such a type. Consider the
following cases and try to answer for yourself which should reasonably
compile:
gvar v1 = 12;
v1 = 100; // case 1.1
gvar v2 = 12;
v2 = "test"; // case 2.1
v2 = 14; // case 2.2
It seems you argue that case 1.1 shouldn't compile, which seems reasonable.
But it seems you believe case 2.1 should compile. So then what happens at
case 2.2? Since int and std::string are wholly unrelated, prohibiting
compilation seems silly. Yet allowing compilation undermines the very
purpose of the const type, as the variant will contain int(14) at the end of
the program segment. Your proposal, then, appears inconsistent.
Correct me if I've erred, but IMO this thread is getting old.
Thanks,
Eric
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk