Boost logo

Boost :

Subject: Re: [boost] Heads up - string_ref landing
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-11-27 00:48:49


On Mon, Nov 26, 2012 at 7:03 PM, Yanchenko Maxim
<maximyanchenko_at_[hidden]>wrote:

> 26.11.12, 20:54, "Daniel James" <dnljms_at_[hidden]>":
> >
> > On 26 November 2012 11:56, Andrey Semashev <andrey.semashev_at_[hidden]>
> wrote:
> > > The problem with std::string is the same as with string_ref - it
> > > doesn't support implicit construction from an arbitrary range, so my
> > > examples with custom string types would still not work.
> >
> > Shouldn't construction from an arbitrary range be explicit? Arbitrary
> > implicit conversions are problematic. To get implicit construction
> > from third party strings, I'd use some sort of explicit customisation
> > mechanism.
>
> Hi Daniel, I'm fully with you here. The construction of string_ref should
> be explicit (except maybe literals if we can detect them in compile time)
> as we're giving away pointers to something that is externally managed.
> Look at std::string::c_str/data, any smart_ptr::get etc - everything is
> explicit for a reason. Implicit conversions to pointers are very dangerous
> here.
> No containers give away their internals implicitly, and this is Good Thing.
>
> Consider a vector of pointers, for example. You don't want to implicitly
> put a pointer managed by a smart pointer there, you want it to be explicit
> so it's visible and you don't forget putting reset/release near a
> push_back. Same applies to a vector of string_ref - you want to be sure
> that the string referred by it lives as long a needed, and there is no
> other way except explicit construction.
>

I was under the impression that string_ref's proposed purpose was to
provide a generic concrete (i.e., non-template) interface for string
algorithms (both as parameters and results), and for this purpose, the
above arguments seem irrelevant. The lifetime concerns are no worse than
for a std::string const &.

- Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk