Subject: Re: [boost] Review Request: Introduction of boost::string namespace and string-conversion functions
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-13 23:48:22
> Sorry, I still don't think that's a good idea.
There is nothing to be sorry about. Everyone has their convictions. That'd
be naive of me to expect having you converted just one paragraph.
> The problems that were mentioned seem quite real to me,
Yes, I understand... and I say you bring that problem onto yourself by
with bll, bsl, etc. I admit, it is convenient... but it just too limiting
and will not work in the long run. Stop doing that and the problem will go
away. BTW, with your naming schema how do you deal with Bost.Lambda and
> whereas the namespace name can be easily changed to another one without
I am not sure how you can say "easily changed" if I want one thing and you
want something else and somebody else might want something else again. There
is no need to change the boost::string though (IMHO) as as-is it does not
clash with *anything*. On the user level though every user can rename it to
anything he finds sensible. I guess, you will have to find something more
descriptive than 'bll', 'bsl'...
namespace another_one_without_problems = boost::string;
Therefore, IMHO the library name/namespace itself should be as descriptive
as possible (and in this context boost::string is just that). Then, everyone
will rename it to their liking.
> If boost::strings isn't good enough, there was another suggestion - to use
> the boost::algorithms namespace in the Boost.StringAlgorithms library.
> Actually, submitting these tools as the StringAlgorithms extension looks
> quite a viable idea to me.
I am not saying "boost::strings isn't good enough". It just looks odd to me.
I've never seen boost:lamdas, etc. And it does not clash with anything. And
given I've been using aux::string with no problem the whole "clashing"
argument does not stick with me.
I feel that the whole name-"clashing" argument is misguided. The namespaces
have been introduced exactly to avoid name clashes. So, that 'foo' in my
namespace could live happily with 'foo' in your namespace. Therefore, the
view that I cannot use 'foo' because it is already used in some other
namespace just does not grow on me. And I am not exactly sympathetic to the
cries like -- "look, I've opened up all the namespaces and now I have name
As for the boost::algorithms namespace it's a completely different course.
Dave suggested to start fresh. One of the steps would be to create a place
for anything-string. I like the idea. So, I jumped in and I am prepared to
stay that course trying to make it happen. For that I feel boost::string is
perfect as tomorrow I can put some auxiliary string-class there (I already
can thing of one) even though it's not an algorithm. Given our experience
with lexical_cast I am weary of trying to submit anything as part of
anything. Feel free to try.
>> 3. Naming of the conversion functions.
>> namespace boost::string obfuscated;
> I must say, this is my case. However, I tend to use acronyms for namespace
> namespace bll = boost::lambda;
> namespace bmi = boost::multi_index;
> As for this tool, I would probably
> namespace bsl = boost::string;
And for Boost.Log you'll use ...? Just admit it on the smallest scale the
strategy is OK. On a bigger scale it fails miserably. So, it won't work with
Boost.Log and is not needed for Boost.String. Can you live with that?
> Then the library usage becomes a mess.
No, the library does not become a mess -- your code becomes less readable.
Is it *my* problem, you think? Or maybe, just maybe, it is poorly chosen
>> string str = boost::string::from(i);
> That's too lengthy.
You are teasing me, right?
namespace bstring = boost::string;
string str = bstring::from(i);
string str = bstring::from_string(i);
string str = bsl::from_string(i);
Even with 'bsl' your version is longer. Then, what happened to your
objectivity (if anything below looks familiar ;-) ):
logging::core::get()->set_filter(flt::attr< severity_level >("Severity") >=
Just do not give me that Boost.Log is "special". :-)
>> the intention seems clear and the following feels like a tautology:
>> string str = boost::string::to_string(i);
> Maybe that's another sign that the namespace name is suboptimal.
No, it is a sign that '_string' is redundant. Namespaces are similar the
file hierarchy. Like "my-files/documents/letter". Given the hierarchy you
expect 'letter" to be a document and to belong to me... without naming the
file "my-letter-document". Similarly, I like
Similarly to, say,
I am sure to find many other examples.
> I think, "to<int>(str, -1)" does not exclude "to(str, default_ = -1)". I'd
> like to have both, especially since Boost.Parameter allows it. Then I
> could have:
> int i = to< int >(str, -1);
> int i = to< int >(str, default_ = -1);
> int i = to< int >(str, radix_ = 16);
> bool f = to< bool >(str, bool_alpha_ = true);
> int i = to< int >(str, locale_ = loc, default_ = 100);
It does indeed look fancy. I'll look into it closer (to at the very least
I'll deploy it *somewhere*). I have a few concerns though.
1) I need to be sure it does not impose default-constructibility
2) I am not sure it'll be more flexible than chaining like
int i = boost::string::to(str, -1)(some-locale)(some-manipulator);
as it seems to require to() to accept quite a few parameters. In other
words, if I use them, I can run out of them. If I don't I pay the overhead
3) If one interface does what we need, why introduce an alternative. Choices
often confuse people (they surely confuse me).
Again, let me have a closer look at Boost.Parameter.
>> template<class T>
>> boost::string::from(T const&) throw();
> I think, it should be symmetric to the "from-string" conversions and
> should have the same capabilities, including default values. See my
> suggestion above.
Makes sense. Will do.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk