Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Yanchenko Maxim (maximyanchenko_at_[hidden])
Date: 2012-11-16 13:50:29

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().
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).

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.)

Again, char_range utilizes unsafe knowledge about std::string internals. This is generally a bad thing and should be considered only when you want to optimize something.

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).

But it's clearly an overkill, especially given that inside open() there is a call to an API function that takes filename as a zero-terminated C string - therefore you'll need to do c_str() anyway.

> 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?

Thanks,
Maxim