From: Itay Maman (itay_maman_at_[hidden])
Date: 2002-07-20 06:44:03
Having been inspired by the "boost::function<R(*)(A1,A2)>" discussion, I
thought we might borrow something to Boost.Variant:
Instead of supplying variant_cast<>/extract<> functions, variant.hpp can
supply overloaded versions of any_cast<>, which accept a variant value,
rather than a boost::any value. These functions will use some sort of
deprecation trickery (as described in the above-mentioned discussion), and
will provide the same functionality as variant_cast<>.
By doing so, boost::variant will have full source-code compatibility with
existing any-based code, with the additional benefit of promoting the use of
functor visitors, over the (clumsy) "if (any_cast<T>(&v))" constructs, in
future code. The down side of this idea is the coupling of variant semantics
to an any-related primitive, but I think this cost might be worth paid.
"Eric Friedman" <ebf_at_[hidden]> wrote in message
> Eric Friedman and Itay Maman have decided to collaborate on the
> of a single variant library design and implementation rather than to offer
> two competing libraries. This decision was made upon the realization that
> the two libraries were continually borrowing both inspiration and
> implementation techniques from each other, ever-blurring the lines between
> the work of the two authors.
> Eric and Itay have not yet developed a single implementation or even come
> final decisions on the library's design; discussion is under way between
> authors at this time.
> Topics currently under discussion include:
> (1) Variant-to-variant conversion.
> "Strict" conversion requires each of the source variant's bounded types to
> be unambiguously convertible to one of the destination variant's bounded
> types; "Non-strict" requires only the source variant's runtime value to be
> convertible to one of the destination variant's bounded types, throwing an
> exception if the conversion does not exist or is ambiguous.
> Which should be the default conversion method (strict being safer,
> non-strict more useful), and should both methods be supplied?
> (2) Default construction of variant types/"emptiness" of variant values.
> Should variant default construct the first type specified in its bounds or
> should it initialize to an 'empty' state (like boost::any)?
> The former is arbitrary (though arbitrariness may be documented). But the
> latter, while elegant, may introduce greater complexity in user code
> can a variant be "emptied" once it is non-empty? under what conditions
> the user check against variant::empty()? and so on).
> Currently variant::empty() is provided only for type signature
> with boost::any and always returns a true value. Is the concept of an
> variant an important or useful one?
> (3) Algorithmic complexity of variant visitation.
> O(1) is possible but introduces need for some thread-safety primitives and
> (minimal) space overhead; O(N) is achievable via cascading if statements.
> On one hand it is unlikely N (i.e. the number of bounded types) will grow
> large, and so the question seems moot; on the other hand, there may be
> for variant that have not yet been imagined -- and which may leverage N
> is large.
> What should be required of a conforming variant implementation?
> (4) Non-member variant functionality, e.g., type_switch, extract<T>,
> try_convert (for non-strict variant-to-variant conversion), etc.
> Should these facilities be treated as separate libraries from
> as they are not variant-specific? How would such an approach be handled if
> variant were accepted into Boost?
> Feedback is welcome and desired.
> Eric Friedman and Itay Maman
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk