Subject: Re: [boost] Formal Review Request: Boost.String.Convert
Date: 2009-02-17 20:18:37
I am not sure I can answer all the questions sent so far individually.
Some of the questions have been discussed/answered and hopefully this
email might be of some help also.
RE: convert() and directionality
I've decided to stick with Robert's convert() (and his op>> as well. Thank
you, Robert) as I agree with his view to leave the door open for possible
extensions. That attitude has already proven useful to extend the
conversions onto string-to-string (that I did not anticipate). With
convert() it'll be easy to extend the existing functionality onto
wstring<->u8string, etc. In string-to-string context the directionality
issue is mute and I personally find convert() as very much appropriate.
Even with string-to/from-type conversions directionality is still present
(via types). I agree that with convert() the directionality is somewhat
more subtle compared with to/from (or whatever the alternatives).
Yes, I understand quite a few people are not exactly thrilled with
to/from. However, it is still here. Apologies. There are two (and a half)
reasons for that --
1) conceptual. Even though I am getting to like convert() more and more, I
am still occasionally longing to express explicitly the direction of the
conversion with to/from.
2) technical. This to/from-based interface is used in my current project
and I am reluctant to needlessly disturb it in any way to avoid code
reviews, etc. etc.
2.5) I happen to still like its terseness and directness as my code simply
reads "string::to<int>" for string-to-int. I am getting more and more
comfortable with convert() though. However, I've been using to/from for
about 5 years and it feels like old shoes. Just give me some time to get
used to something new.
Somehow I did not like to_string/from_string from the start. I dunno. Just
irrational primal dislike. I am sorry. Now it seems I might try putting
some smoke-n-mirrors around that by justifying it by the functionality
that Hartmut mentioned -- conversion from one symbol/character set to
another. I've implemented it (v0.14) and it it like this:
string encrypted = boost::string::convert(naked_str) >> my_cypher;
string decrypted = boost::string::convert(encrypted) >> my_cypher;
That is, we are converting from a string to again a string. In such
context I very much like the direction-less nature of convert().
>> My problem is that I can't think of a case when I would be writing
>> code that doesn't "know" if it is going "to" or "from" string.
Again, string-to-string (or string-from-string) comes to mind. Any
directionality seems superfluous and I personally find the code above
quite appropriate. Any other suggestions are always welcome as hartmut
only brought it up yesterday and I only gave it a cursory thought (can I
say a "cursory" thought? it kinda does not feel right).
>> I've needed to convert things specifically to std::string plenty of
>> times to justify a simple interface where to_string returns
>> std::string. I want to be able, in a header file, to just say:
>> struct foo;
>> std::string to_string( foo const & );
>> std::string to_string( foo const &, fmt );
>> and be done with it.
I hope that the suggested interface and implementation allow enough
flexibility and simplicity without limiting one to std::string only:
namespace bstring = boost::string;
std::string s1 = bstring::convert(foo);
std::string s1 = bstring::convert(foo) >> std::hex; // add formatting
std::Wstring s1 = bstring::convert(foo, std::wtring()); // convert to wide
std::Wstring s1 = bstring::convert<std::wstring>(foo); // same as above
I like Scott's suggestion of the above. It looks cute. OTOH I am not sure
where to stick it into though.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk