Boost logo

Boost :

Subject: Re: [boost] [conversion] Motivation for two NEW generic conver_to and assign_to functions
From: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2009-10-26 14:42:15

vicente.botet wrote:
> Hi,
> I have modified the convert_to implementation with your suggestions (see below) and now we can do:
> B b;
> A a1 (convert_to(b, type_tag<A>() ));
> The user can add overloading on the namespace of the class From, or specialize the boost::conversion::convert_to function.
> I have defined the tag with a defaulted parameter value type_tag<Target> tag=type_tag<Target>(), so we can also do
> A a1 (convert_to<A>(b));
> I have added still an overloading to simplify some uses as
> a = convert_to(b, a);
> The Target parameter is not used other than to retrieve the type.
> template <typename Target, typename Source>
> Target convert_to(Source const& from, Target const&);
> What do you think? Does this interface satisfy your expectations?
> Best,
> Vicente

That seems to be about what I had in mind originally. I think wrapping
the ConvertPolicy (Target::allocator_type in my example) in with the
Source parameter is a good idea, after some thought. My only additional
suggestion (and perhaps I'm thinking about this wrongly) is to provide a
special pair class for just such purposes. E.g., a convert_pack or
conversion_pack or s/pack/pair/, which holds its member objects by
reference and uses names more descriptive than "first" and "second".
Wrapping everything up in a std::pair might create ambiguous overloads
that convert from "actual" std::pair's, and it's also clearer what the
source information actually consists of. Essentially, I'd like there to
be a distinction between the "value information" (e.g., the number the
object represents) and the "non-value information" (e.g., how the object
dynamically allocates memory) within the Source.

A couple of days ago John brought up some issues with using ADL exactly
in this fashion, however. One suggested solution was to put an
additional tag in the signature unique to the library implementing the
conversion. I don't like this. I'm not sure how best to determine what
that tag is suppose to be, and it adds seemingly unnecessary syntactic
weight to the invocation of convert_to. It seems that somehow, 2
implementations of the same conversion operation need to be able to
coexist. E.g., if we're converting from type1 in lib1 to type2 in lib2,
we should prefer the convert_to overload in lib2 over the convert_to
overload in lib1 (somehow), or vice versa.

- Jeff

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