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
> 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
> > 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
> > 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
I care for as generic code as possible within the limits of separate
> > 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk