Boost logo

Boost :

Subject: Re: [boost] [conversion] review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2011-08-31 21:15:52


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:
>>>> I do agree however that the call syntax should not rely on <>. One
>>>> reason is that it turns off ADL. Another reason is that sometimes an
>>>> implicit conversion to match an existing non-template overload is
>>>> preferable to instantiating a template.
>>>
>>> The function overload customization point in Conversion uses a dummy parameter and no <>.  convert_to<> is a just a more pleasant wrapper over that.  So I think these language features are still available.
>>
>> What makes it more pleasant? Is it more convenient? In what use cases?
>
> We are talking about a library that emulates overloading static_cast. The wrapper makes it look somewhat like static_cast<>(), whereas if you directly had to use the customization point it would be a mess:
>
> conversion::convert_to<Target>(source);
> versus
> explicit_convert_to(source, conversion::type_tag<Target>())

Ah. I'm not sure I like the fact that it is modeled after static_cast
but I understand.

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

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode


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