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: 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 
sticking
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 
Boost.Log? ;-)

> whereas the namespace name can be easily changed to another one without
> problems.

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 
clashes".

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
> aliases:
>
>   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 
namespace aliases?

>>         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 ;-) ):

BOOST_LOG_DECLARE_GLOBAL_LOGGER_CTOR_ARGS(my_logger, src::logger_mt, 
(arg1)(arg2)(arg3))
pSink->locked_backend()->set_formatter(fmt::ostrm
logging::core::get()->set_filter(flt::attr< severity_level >("Severity") >= 
warning);

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

    boost::string::replace()
    boost::string::dedupe()
    boost::string::trim()

Similarly to, say,

    boost::filesystem::exists()

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 
requirement.
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 
price.
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::value<std::string>
>>         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.

V.