Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-05-05 04:28:19

> Scott McMurray <me22.ca+boost <at> gmail.com> writes:
> ...
> I really like the split into two parts, to allow a direction word.
> 
> If you don't like the ::from, what about something like this?
>     foo(convert(x).to<int>());
>     optional<int> i = convert(x).to<int>(std::nothrow); // or maybe
> .try_to<int>()
> 
> It's arguably the same as the .value() in Vladimir's lib, except that
> by delaying providing the type, it makes sense that it's needed.

int foo = convert("123").to<int>();

looks *very* attractive as it allows to have the converter proxy which from my
experience (which obviously can be wrong) is essential for any functionality
beyond lexical_cast. Still it removes that "excessive" converter exposure that
some people have strong objections to.

The fallback value and additional configuration (locale, formatting, etc.) 
could probably be provided with (just thinking out loud):

int foo = convert("not int").to<int>(-1);
int foo = convert("not int")(format_ = std::hex).to<int>(-1);

So, 'convert' returns a Target-type-less converter, right? The only wrinkle I
can see so far is that 'convert' now does not know the Target type and,
therefore, has to accept/support all configuration parameters (format, locale,
etc.) for all Target types even if those configurations do not make sense for
that ultimate Target type. It could be quite confusing.

The advantage of the original proposal was that the Target type was known much
earlier (at the time of converter construction), so non-applicable
configurations would not compile/be accepted.

Hmm, I am afraid the above might not be implementable. Say, the user wants to
supply his own manipulator (or locale). That manipulator obviously has to be
attached to something (std::istream). However, we do not have that stream in the
converter as the converter cannot possibly know if that stream will be needed.

V.
V.