Re: [boost] Formal Review Request: Boost.String.Convert
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). RE: to/from: 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. RE: to_string/from_string 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 string std::Wstring s1 = bstring::convert<std::wstring>(foo); // same as above RE: convert("5").to<int>(), I like Scott's suggestion of the above. It looks cute. OTOH I am not sure where to stick it into though. Thanks, Vladimir.
On Tue, Feb 17, 2009 at 5:18 PM, <Vladimir.Batov@wrsa.com.au> wrote:
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);
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.
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 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'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 string std::Wstring s1 = bstring::convert<std::wstring>(foo); // same as above
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. 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()? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
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.
On Tuesday, February 17, 2009 9:12 PM Emil Dotchevski wrote:
On Tue, Feb 17, 2009 at 5:18 PM, <Vladimir.Batov@wrsa.com.au> wrote:
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);
For each operation, you're adding another pair of function names. *If* convert works reasonably for all (most?) cases, then that interface is better.
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.
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 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.
That you know you're converting to string implies calling to_string() in the one case or convert() with certain template/function arguments in the other. If you don't view convert as to/from string but as from one type to another, where string can be source, destination, or both, the directionality argument dissipates. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (4)
-
Emil Dotchevski -
Stewart, Robert -
Vladimir Batov -
Vladimir.Batov＠wrsa.com.au