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

Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-18 01:26:51

>>        string encrypted = boost::string::convert(naked_str) >> my_cypher;
>>        string decrypted = boost::string::convert(encrypted) >> my_cypher;
>
> What's wrong with:
>
> std::string encrypted=encrypt(naked_str);
> std::string decrypted=decrypt(encrypted);
> ...
> Sigh. I guess it is possible to cram any functionality that takes a
> string and returns a string into convert() and >> but I wouldn't call
> it appropriate.

I am not sure there is anything wrong with your example as such. In fact, I 
might probably argue on your side of the fence as my usage pattern is pretty 
much limited to string-to/from-type. It does not mean though I can guarantee 
there are no other applications/usage patterns that I cannot think of at the 
moment or have no use for right now. That string-to-string use case was 
brought up and instead of arguing its validity (that I personally do not 
feel qualified) I tried to see how well the framework could accommodate it. 
If it turns out you are right and we do not need it, then it OK as it is 
merely one use-case supported by the underlying design. It'd surely be a 
disaster if it was the other way around, i.e. the underlying design was 
shaped for the case that turned out not-needed.

Still, I think that there might be a use for such chaining

convert(str) >> my_cypher >> something-else >> some-more;

and for building "my_cypher" blocks as generic components. Like std::endl() 
vs. "\n". But honestly I am not sure.

> I still can't think of a use case when I'd want to convert a
> non-string to string, or string to non-string, but I don't know which
> way.

I feel that by this reasonable statement you are arguing *for* convert() 
(without the need to say which way explicitly)... unless I misinterpreted 
your statement (which would be typical).

...
> I was specifically concerned with the foo header, that is, how would
> the foo to_string declarations look like, not how you'd call them.

I am not sure I understand. 'foo' won't have a to_string() method. The reqs 
to enable string-to-foo are to have op>>() and op<<() for the class (as 
lexical_cast does). But I am sure you know that. So, I am at a loss.

> Note that both to_string overloads I specified aren't templates. If we
> assume that fmt is some kind of formatting string, then foo.hpp could
> look like:
>
> #include <string>
>
> class foo;
> std::string to_string( foo const & );
> std::string to_string( foo const &, char const * fmt );
>
> What would this header look like using convert()?

I do not understand. Is it "how header look" or "header using convert" or 
...?

std::string
to_string(Foo const& foo)
{
    return boost::string::convert(foo);
}

Is it what you were after? Probably not. Maybe you are asking how your 
formatter could be fitted to convert()? No? I am sorry I do not understand.

V.