Boost logo

Boost :

Subject: Re: [boost] [conversion] review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-01 02:10:19


Le 01/09/11 03:15, Emil Dotchevski a écrit :
> On Wed, Aug 31, 2011 at 5:45 PM, Gordon Woodhull<gordon_at_[hidden]> wrote:
>> On Aug 31, 2011, at 5:11 PM, Emil Dotchevski wrote:
>>> On Wed, Aug 31, 2011 at 1:13 PM, Gordon Woodhull<gordon_at_[hidden]> wrote:
>>>> On Aug 31, 2011, at 3:01 PM, Emil Dotchevski wrote:
>> In other words, the ugliness is confined to the definition of conversions and doesn't spill over into their use. But the conversion definitions do get to benefit from ADL... actually I don't see how a conversion library could benefit from implicit conversions of the target type, but I might be missing something.
> My point about ADL doesn't apply since the<> syntax is limited only
> to the point of the user calling convert_to, that is, as long as
> explicit_convert_to still uses ADL and it is not required to be a
> template, all is good.
>
> When I mentioned implicit conversions, I meant of the source type.
> Assuming the internals of convert_to<> do not require the actual
> conversion to be handled by templates,
This is the case. The behavior is similar to the obe of boost::swap.

boost::conversion::explicit_convert_to<Target>(source)

calls

explicit_convert_to(source, conversion::type_tag<Target>())

which could be overloaded.
> it is possible to define a
> small set of non-template overloads to handle a much larger set of
> input types that are already part of a carefully designed implicit
> conversion framework.
I don't know IIUC, when you use implicit, are you refering to predefined
by the library?
If yes, which conversion do you think that should belong to this set?
> If templates were required, the call to
> explicit_convert_to could instantiate a template instead of resorting
> to implicit conversion. I'm not saying that one is better than the
> other, only that both should be supported.
>
Here I'm lost.

Best,
Vicente


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk