|
Boost : |
Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-22 23:30:36
>> I am not sure Boost.Parameter can be applied for the Boost.Convert
>> task in question (although Andrey is really pushing for it
>> :-)). However, I must say it is a very nifty thing you've come up
>> with. I am thinking really hard where I might use it. :-)
>
> This seems to evade your earlier statement a bit:
>
>>> If you tell me that the user can make Boost.Convert understand that
>>> new parameter without modifying Boost.Convert, I'll be first to
>>> abandon manipulators in their favor.
Dave, it probably might well appear this way... but I am not really trying
to evade anything. The thing is that Boost.Parameter is a new thing to me
and I have not seen much code using it. So, I am still not sure how to plug
it into Boost.Convert (sorry for using the name I know it's not part of
Boost, I just need to refer to it somehow quickly).
Now I understand that Boost.Parameter allows me to call
convert<string, int>(str, some_user_defined_param = ...);
As I understand Boost.Convert does not know and does not make use of
"some_user_defined_param" but takes it in using ArgumentPack. How then does
the parameter make it to some user-defined formatter? Maybe it is because I
am still thinking in terms of manipulators -- a user writes his own and
plugs it into Boost.Convert as
convert_to<int>(str) >> std::hex;
How do we do that with Boost.Parameter? Should we write/specify some kind of
Boost.Parameter-aware manipulator? What the signature then might be? Is
there some other way?
convert<string, int>(str, default_ = -1, throw_ = false);
indeed looks trendy and I probably could extend the convert() interface that
far. However, I understand Andrey's interest is in the user providing his
own keyword (like throw_on_out_of_range_) so that it could be used somewhere
for formatting. Where and how that's what I am having difficulty with (due
to no experience with Boost.Parameter).
V.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk