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.