Vladimir Batov wrote:
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? ;-)
I haven't worked out a good practice with Boost.Log yet, but I think I'll settle with something as short as blog or blg. I'm not saying that everyone has to use this scheme, I'm just saying that I find it practical (I have applied it in quite a few projects to be able to say so). In response you advise me to drop this practice because you like your naming better. IMO, it doesn't work this way. One of the qualities of the submission is the ability to "look good" in the user's environment.
I am not saying "boost::strings isn't good enough". It just looks odd to me.
I believe, Scott has already pasted the link to the naming policies, so "strings" doesn't apply yet. That is, until you have a string class in your namespace.
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.
How many people were using your aux::string? I don't think that as many as Boost users out there.
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.
Ok, if you have additions on your mind that clearly don't fit into an algorithms library, I agree that Boost.StringAlgorithms is not appropriate.
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.
It is shorter than the original string str = boost::string::from(i); However, I'm not stick with the "from_string" name either. Other participants also suggested better names, like "parse" or "convert". The point is that this name alone brings you the understanding of what the function does. "from" does not.
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". :-)
I don't think that this comparison is relevant in any way. Neither of these constructs is about parsing or formatting objects. Just to answer that, the closest thing to formatting in Boost.Log are formatters, which may look like this: fmt::ostrm << fmt::attr< int >("MyAttr"); Yes, it's longer, but it has completely different requirements and semantics. I don't want to go OT here, so if you have suggestions about Boost.Log, please, move to another thread.