From: Eric Friedman (ebf_at_[hidden])
Date: 2006-06-08 01:31:28
Yuval,
Yuval Ronen wrote:
> Eric Friedman wrote:
>
>>As for operator!= (and operator<=, etc.), while I do think it may be
>>useful, it raises the question of what requirements variant imposes on
>>its bounded types. Specifically, adding support for these operators is
>>not so straightforward as saying operator!= is simply !(*this == rhs).
>>The idea of operator== and operator< is that if the current bounded type
>>is the same in both variant instances, then operator overload _for that
>>type_ will be invoked. To support this same behavior for the other
>>operators would require adding to the bounded type requirements. See
>><http://boost.org/doc/html/variant/reference.html#variant.concepts> for
>>a refresher on variant's approach to concepts. Maybe this is an
>>overly-pedantic response on my part, though.
>
>
> I think it *is* as straightforward as saying operator!= is simply
> !(*this == rhs). There is no other way that makes sense.
I of course agree with you that this definition of operator!= makes
sense, but I am reluctant because this is not how C++ works: the
language allows entirely separate definitions of operator== and
operator!=. It would seem unfortunate I think if variant called
operator==(T,T) but never operator!=(T,T)...
> Operators >, <=, >=, on the other hand, are completely different. I
> think there is no natural ordering of variant objects, so not supporting
> them is logical. Operator < is an exception because it's used for
> ordered conrainers. IOW, I completely agree with your decision to supply
> operator < and not supplying operators >, <=, >=.
Now how is that operator!= as !(lhs == rhs) makes sense, but operator<=
as (lhs < rhs || lhs == rhs) is completely different?
>>The reason (or at least one of them) that apply_visitor accepts visitors
>>by reference and not by value is that I had intended to introduce a
>>dynamic_visitor counterpart to static_visitor in a more general
>>Boost.Visitor library. Passing by value would interact poorly with
>>polymorphic dynamic visitors due to slicing. If you are interested, I
>>believe Boost.Visitor is probably still sitting around in the Boost
>>Sandbox CVS on Sourceforge.
>
>
> Then maybe different names should be used for dynamic_visitors, for
> example apply_dyn_visitor(). We need to consider whether the need for
> dynamic_visitors is large enough in order to justify the negative impact
> on the static_visitor's interface. Have you found there is great need
> for dynamic visitors? I have to admit that I've never needed them... Not
> to mention that the whole standard library is based on static functors
> passed by value...
I think my opinion here is that a visitor is fundamentally different
from a functor. Functors model function types; they may be implemented
with a template, but logically they have a single signature. By
contrast, a visitor is a set of functions with different signatures used
to handle a set of different cases.
Also, looking back to your original email, you mentioned a desire to
pass temporary visitor objects. I believe that is supported with the
current implementation. The following compiles just fine under gcc 3.4:
#include "boost/variant.hpp"
class TestVisitor : public boost::static_visitor<>
{
public:
template <typename T>
void operator()(const T&) const
{ /*...*/ }
};
int main()
{
boost::variant<int, double> var;
apply_visitor(TestVisitor(), var);
}
>>Variant already supports reference types, at least on modern compilers.
>>However, references are not assignable, and so as noted in the concepts
>>documentation for variant, this implies that the resultant variant is
>>not assignable. To address your comment about boost::optional, then,
>>variant does not allow rebinding of references.
>
>
> No problems here.
> I just want to express my opinion that the decision regarding reference
> support should apply both to Optional and to Variant.
So you think Optional should change or Variant should change?
Eric