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

Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-02-18 12:51:43

On Wednesday, February 18, 2009 11:40 AM
Christian Holmquist wrote:
>
> > Isn't it so that
> string to_string(T const&, Format) is about string generation, such as
> Spirit::Karma
> and
> boost::optional<T> from_string<T>(String) is about parsing, such as
> Spirit::Qi.
> and
> StringT convert_string<StringT>(String)
> about character conversion.

The latter is better expressed as "transcode" if you wish to use separate names.  That aside, your statements are accurate.

> The name 'convert' doesn't tell me anything about strings,

Good!  My suggestion was to consider a type-to-type conversion facility for which converting to and from strings were special cases.

> for all I know
> the following could be valid:
> convert<std::vector<int> >(std::list<float> >()) ;

It could be made valid, though I doubt it would be supported.

> boost::to_string/boost::from_string would be very useful if
> made right, but
> seems this discussion is mostly about nifty expressions such as
> convert("5").to<int>(), which is close to unusable to me.

That isn't the right characterization of the discussion.  It's about figuring out what should be done and what interface best captures it.  The latter has consumed a great deal of discussion, but I'm hoping to spend more time on the former.

> How would the following trivial case be written?
> vector<int> v;
> std::vector<std::string> s;
> std::transform(v.begin(), v.end(), boost::bind(convert, _1, ????),
> std::back_inserter(s));

That's a curious "trivial case" but it adds a requirement if it should be supported because you've specified no template parameters for convert(), thus implying it should be a non-template function, unless I'm mistaken about some means whereby the compiler can deduce the template parameters.

It is things like this suggestion that must be considered for inclusion in the list of requirements for which to design the facility.  Many requirements will likely be rejected as enlarging the scope excessively while others will be considered paramount.  That is why I've avoided committing to any interface thus far.

> I've not seen much discussions on how to provide formatters, or how to
> extend with user-defined types. Isn't that important for such
> a library?

UDT extension is via the IOStreams insertion and extraction operators as mentioned in another post.  Handling formatters was suggested to be by returning a proxy that accumulates formatting information prior to converting to the output type.

_____
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.