Re: [boost] Formal Review Request: Boost.Convert

Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-02-27 14:20:13

On Fri, Feb 27, 2009 at 11:02 AM, Stewart, Robert
<Robert.Stewart_at_[hidden]> wrote:
> On Friday, February 27, 2009 1:55 PM
> Emil Dotchevski wrote:
>> On Fri, Feb 27, 2009 at 5:40 AM, Stewart, Robert
>> <Robert.Stewart_at_[hidden]> wrote:
>> >>
>> >> What's wrong with the following call syntax:
>> >>
>> >> boost::convert<target>( source const & [,arg1,arg2,...] )
>> >>
>> >> that is, the caller provides the target type for the
>> >> conversion, then
>> >> the first argument is considered the source (deduced
>> >> automatically),
>> >> and the rest of the arguments configure the conversion.
>> >
>> > That only works if the argument types and number are known
>> > ahead of time.  The Boost.Parameter approach allows for open
>> > ended extension -- for good or ill.
>>
>> I don't understand. The overload-based approach can also be extended
>> -- by providing more overloads, user-defined or generic overloads
>> given by the convert framework itself.
>
> Each of your arg1, arg2, ...argN must have a type or be deduced by the compiler in a function template.  In order to use them as formatting options, the function [template] must understand which parameters(s) map to the needed formatting option(s), while ignoring the rest.  Thus, the order, purpose, etc. must be known beforehand.  Each new, custom formatting option extends the set introduced by *all* other custom formatting options.  That is untenable.
>
> With the Boost.Parameters approach, the formatting options are gathered into, conceptually, a dictionary which is accessed by keys.  A given convert function template must know about the keys it deems important and can use them to access the desired options.

In fact in many languages that's exactly how arguments get passed. But
obviously it isn't appropriate in C++ in general. For sure, there are
cases when you have to resort to dictionaries of parameters.

I don't see why this is necessary in the case of convert. Whenever the
caller uses a formatting parameter, the function the call binds to has
to understand that parameter. In our case, there are two contexts that
can deal with formatting parameters: the user-defined overloads, and
the generic framework overloads. If the formatting parameter is
generic, then it's reasonable for the framework to handle it. If not,
then it is irrelevant to the framework itself. It can't do anything
with it, well, other than pack it into a dictionary to send it to the
user. :)

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