Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-02-18 09:59:30
On Tuesday, February 17, 2009 9:12 PM
Emil Dotchevski wrote:
> On Tue, Feb 17, 2009 at 5:18 PM, <Vladimir.Batov_at_[hidden]> 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
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_at_[hidden]
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk