Re: [boost] Review Request: Introduction of boost::string namespace and string-conversion functions

Subject: Re: [boost] Review Request: Introduction of boost::string namespace and string-conversion functions
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-02-13 13:47:52

Vladimir.Batov_at_[hidden] wrote:
>
> Tally so far
>
> 2. The name of the namespace.
>
> People largely seem content with "boost::string".
>
> Andrey Semashev expressed a concern that the name was too generic and
> could clash with std::string (using namespace boost; using
> namespace std).
> A fair point. However, I do not feel it is a boost::string
> "problem" per
> se but rather the "problem" with using-directives (or rather
> mis-using-directives). Using-directives beat the whole purpose on a
> namespace and best avoided (see Stroustrup 8.2.3). From my actual
> experience it was not an issue. Long time ago I've introduced
> aux::string
> in two sizeable projects and honestly did not have one single
> complain
> about name clashing.

Your counterarguments are not without merit but too easily dismiss the problem when choosing a different name could resolve them readily.

> Bo Persson also expressed a concern siting it'll make it
> "very hard to
> propose the utilities for inclusion in a future language
> standard". May
> be. May be not. When things of that magnitude happen (which
> seem quite
> remote at present) components get moved from a namespace to a
> namespace
> (several times) anyway. Like some stuff from the "boost"
> namespace moving
> to the "tr1" namespace just ultimately to be moved to the
> "std" namespace.
>
>
> Therefore, unless something major comes up later we are settling on
> "boost::string".

That's rather dismissive of the complaints.  "text," "convert," and "conversion" seem at least as good as "string."

> 3. Naming of the conversion functions.
>
> The "to/from/is" set seems to sit well with the majority of people.

I don't understand how you can claim that.  Few commented for or against "is."  As I recall the tally, excluding yourself, there was one that suggested "is" was fine and one (me) that said it wasn't.  (You later note that you'll keep "is" as a placeholder pending further consideration, so I'm glad my concern isn't lost.)  A number complained about "to" and "from."  It didn't strike me that there was a majority favoring anything yet.

> The to_string/from_string was floated around as alternatives.
> I feel that
> the "_string" extension indeed serves a mildly useful purpose
> when the
> "string" namespace is obfuscated. Like

Not just obfuscation, as you describe it, but also elimination by way of using directives or using declarations.

>         namespace boost::string obfuscated;
>
>         string str = obfuscated::from(i); // What the...?
>         string str = obfuscated::to_string(i); // Somewhat better but
> still...
>
> When used sensibly
>
>         string str = boost::string::from(i);
> or
>         namespace boost::string str;
>         string str = str::from(i);
>
> the intention seems clear

Your notion of "sensible" use is not how all will use such functionality.  Consider what can be extremely common:

void f()
{
   using boost::<something>::from;
   ...
   std::string s(from(i));
   ...
   s = from(j);
   // etc.
}

"from" is not as meaningful.  That name almost requires retaining the enclosing namespace or a namespace alias.

> the following feels like a tautology:
>
>         string str = boost::string::to_string(i);

That only applies if both "string" and "to_string" are the selected names when finished.

> Can we agree on the following interface:
>
>         template<class T, class String>
>         boost::string::value<T>
>         boost::string::to(String const&, T const& =T()) throw();

I'm not convinced.  Naming is still an issue, of course, but this interface doesn't include the Boost.Parameters idea, for example.

> 6. Something-To-String Conversion Interface.
>
> That did not seem to generate much heat at all. I'll
> summarize to make
> sure we see it the same way:
>
>         template<class T>
>         boost::string::value<std::string>
>         boost::string::from(T const&) throw();

Same answer.

> Does not throw. No default value (do we need one?). Returns

If T is not restricted to built-ins, then there are many reasons why the conversion would fail.  If the function is not to throw an exception, then there would need to be a default.  (Imagine using this for input validation, which can set the stream state to fail when the validation fails.)

> 8. Throw/No-Throw Behavior.
>
> You might have noticed that the interface above *never*
> throws anything on
> failure. I would like to highlight the fact (as it's different from
> lexical_cast behavior) and make sure people are happy with
> it. Those who
> need an exception thrown could do
>
>         boost::value<int> i2 = boost::string::to<int>(str, -1);
>         if (!i2.good()) throw something youself;
>
> Is it satisfactory?

Yes and no.  Both approaches should be supported from the start.  Getting an exception makes calling code simpler, but code that expects failures or that can't use or afford exceptions in some context would benefit from the non-throwing interface.  Yes, others can add exceptions to the non-throwing version, but it would be better to include that in the library.

The non-throwing version could be requested using overloading with std::nothrow_t.

> 9. Requested features.
>
> a) Handling any container<char> (Phil Endecott). I
> implemented a rough cut
> using boost::range and it handles std::(w)string,
> char/wchar_t const* with
> ease. To handle any container we might look into extending
> the interface
> with something like
>
>         template<class T, class Range>
>         boost::string::value<T>
>         boost::string::to(Range const&, T const& =T()) throw();
>
> I have not looked into it throughly yet though.

That is a wise direction to pursue.

The string-oriented focus may be the problem with the namespace and function names.  Perhaps this functionality be merged with the lexical_cast improvement ideas to create a general purpose type conversion facility.  Instead of thinking about conversions to and from strings, think of those conversions as special cases of a more general type-to-type converter of which lexical_cast is a degenerate form.  That suggests something like using "conversion" as the namespace name and replacing "to" and "from" with "convert."

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.