Subject: Re: [boost] Review Request: Introduction of boost::string namespace and string-conversion functions
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-13 17:13:07
> Your counterarguments are not without merit but too easily dismiss the
> problem when choosing a different name could resolve them readily.
1. If I wrote only a paragraph instead of a 3-volumes' analysis, it does not
imply it was dismissed "too easily".
2. I sited that from my experience of actually having aux::string (for about
5years) it was not a problem once.
3. I indeed think that by cryptic aliasing Andrey brings the obfuscation
problem onto himself. Still he is adamant to deploy this technique. In such
a setting I feel he should be dealing with the consequences rather than me.
4. I'd expect it to be quite obvious (from this discussion) that *nothing*
is resolved easily if more than one person involved.
>> Bo Persson also expressed a concern siting it'll make it
>> Therefore, unless something major comes up later we are settling on
> That's rather dismissive of the complaints.
I am not sure what you expected of me. I considered the complains. I counted
how many complained (2) vs. how many replied but did not raise/see it as an
issue (~5 with me). I provided summary and the result and moved on. What
should I have done instead?
> "text," "convert," and "conversion" seem at least as good as "string."
I am sure "text" will be as controversial. The other two are not good as the
idea was to have a namespace for anything-string related and not just
conversion. So, are you *actually* suggesting something else or just
criticizing my "dismissive" style? Does your original "for boost::string"
>> The "to/from/is" set seems to sit well with the majority of people.
> I don't understand how you can claim that.
I counted the number of people complaining and *not* complaining about any
particular name. Then I compared the numbers. Then, I went with the bigger
> ... the tally, excluding yourself,
And you are excluding myself because...?
> ... A number complained about "to" and "from."
Again, I counted the numbers. I went with the bigger one and moved on. What
am I missing?
> It didn't strike me that there was a majority favoring anything yet.
Well, I am not sure how I can react to a nebulous "It didn't strike me".
Should I recount? Do you have different numbers/names showing I cheated? Do
you feel I rushed and should have waited longer?
>> 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.
Elimination *is* obfuscation. You strip me of my name and then complain that
you find it hard to address me. Does it immediately become *my* problem?
>> namespace boost::string obfuscated;
>> string str = obfuscated::from(i); // What the...?
>> string str = obfuscated::to_string(i); // Somewhat better but
>> When used sensibly
>> string str = boost::string::from(i);
>> 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.
It is *never* possible to please all.
> 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.
I find it hard arguing against examples like that. It is clearly a bad
practice. The solution is *not* to deploy it. And the solution lies with the
user. The expectation of messing something up and expecting someone else
having to deal with it sounds infantile to me. If one sticks his fingers
into an electrical socket and gets hurt, should we immediately replace it
with a horse power? Then, that poor horse will be guilty of trampling
somebody who jumped under its feet...
>> Can we agree on the following interface:
>> template<class T, class String>
>> 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.
In other words, the interface *you* are suggesting is ... Without it it is
hard to apply any metrics to such a broad range of opinions. We won't be
able to please everyone. I'll go with the majority regardless it the
minority is convinced or not.
>> 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::from(T const&) throw();
> Same answer.
I do not feel I can decisively act on your answer and need more information
about what exactly you are proposing.
>> 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
Yes, I think it makes sense.
boost::string::from(T const&, std::string const& =std::string())
>> 8. Throw/No-Throw Behavior.
> 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
> The non-throwing version could be requested using overloading with
I'll have to think about it. I do not like the "std::nothrow_t"-based
solution as my usage-pattern is largely non-throwing. So, I do not want
typing std::nothrow_t all the time.
> 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."
The "lexical_cast improvement" was the original suggestion. It did not fly
with many people (including the author and the maintainer). So, the
decision's been made to start fresh.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk