Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2012-11-16 14:05:26

On Fri, Nov 16, 2012 at 8:50 PM, Yanchenko Maxim
<maximyanchenko_at_[hidden]>wrote:

> 17.11.2012, 02:29, "Yakov Galka" <ybungalobill_at_[hidden]>:
> > On Fri, Nov 16, 2012 at 7:18 PM, Yanchenko Maxim
> > <maximyanchenko_at_[hidden]>wrote:
> >
> > I do not see it as an optimization tool. As written in the first
> paragraph
> > of the paper it is intended to remove such nonsense in the future:
> >
> > void open(const char *p, ios_base::openmode = ...);
> > void open(const std::string &p, ios_base::openmode = ...); // added in
> C++11
> >
> > runtime_error(const char *p);
> > runtime_error(const std::string &p); // added in C++11
>
> First, it wasn't a big deal to write c_str() while sending an std::string
> to open().
>

I agree. I would leave it a const char *.

Second, instead of adding an overload, they could just replace it with
> std::string version - everything would work as expected (except code that
> uses exact signatures).
>

I guess you cannot use exact signatures of member functions (the
implementation is permitted to add arbitrary default parameters). This
will, however, break existing code. When you call f.open("xyz") no
std::string is constructed in C++03, so no operator new is called. Changing
it to const std::string & would change this behavior.

Or you care about unnecessary std::string creation? Then it's optimization.
> (I believe you don't really care about it in face of file operations.)
>

I do not care for the file case, but for other things that accept strings
it may matter (like runtime_error -- it adds one more heap allocation. This
is important in error handling, where you do not want to increase the
likelihood of failing to create an exception object).

[...] If you care not about speed but about clean and *generic* interface
> (just std::string is already clean enough), then you need a templated
> open(iterator_range, openmode) where iterator_range can be any char
> sequence (e.g. coming from expression-template code like
> dir+'/'+filename+'.'+ext).
>

I care for as generic code as possible within the limits of separate
compilation.

> [...]
> > This discussion has already been raised here in the context of boost
> > program_options.
>
> Could you give me a reference subj or a link, please?
>

http://boost.2283326.n4.nabble.com/program-options-Some-methods-take-const-char-others-take-std-string-td3733894.html

-- 
Yakov