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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-14 05:40:25

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.