Re: [boost] Re: Boost.Variant collaboration effort

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-22 11:00:57

I think I understand why you have two extract functions. If I'm not
mistaken, the pointer version allows you to test for extractibility by
returning NULL instead of throwing an exception. FWIW, I didn't consider
that an option for the Boost.Python library, since my users usually expect
a special python object called None to be converted into a NULL pointer.
Another reason the class version is important in my case is that some
extractions don't access an lvalue, but actually create a new rvalue (whose
storage is maintained inside the extract class). It can be important to be
able to test for convertibility first, then do the conversion. Each part of
the job does some work, and one wouldn't want to throw out the work done by
the first step when doing the second.

Not that any of this amounts to a criticism of your proposed interface...

-Dave

----- Original Message -----
From: "Eric Friedman" <ebf_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Sunday, July 21, 2002 11:58 PM
Subject: [boost] Re: Boost.Variant collaboration effort

> See my attached implementation of extract.hpp (the current version of
what
> is being used in Boost.Variant).
>
> Simplified implementation (i.e. without const considerations,
workarounds,
> etc.):
>
>     template <typename Holder>
>     struct extract_traits;
>
>     template <typename T, typename Holder>
>     T* extract(Holder* operand)
>     {
>         if (!operand) return static_cast<T*>(0);
>         return extract_traits<Holder>::template
> extract_pointer<T>(*operand);
>     }
>
>     template <typename T, typename Holder>
>     T& extract(Holder& operand)
>     {
>         T* result = extract_traits<Holder>::template
> extract_pointer<T>(operand);
>         if (!result) throw bad_extract();
>         return *result;
>     }