Boost logo

Boost :

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-06-07 07:15:12

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
> <> 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.

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 >, <=, >=.

> 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...

> 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.

> I'll have to more carefully look at your proposals for additional get
> functions to see whether I am convinced of their utility.

I'd appreciate that very much.


Boost list run by bdawes at, gregod at, cpdaniel at, john at