On Sat, Aug 2, 2014 at 2:34 AM, Agustín K-ballo Bergé wrote: You wouldn't generally use `string_ref`s as automatic variables or members. I can't confirm or refute this statement using code of Boost, because
`boost::string_ref` has been used a little so far. But results of "grep
StringRef" inside LLVM code show that StringRef's are used often as
automatic variables. And in addition to explicitly defined class members
there are another dangerous `string_ref` use cases, namely lambda capturing
value and `bind` argument.
On Sat, Aug 2, 2014 at 2:46 AM, Nathan Crookston wrote: I suppose that would break cases like: std::string getStr();
print(std::string_ref sr) { std::cout << sr << std::endl; } print(getStr()); Causing people to have to write print(getStr().c_str()). It's possible to add `string_ref(reference_wrapper<const std::string>)`
constructor to allow people write `print(boost::cref(getStr()))` instead of
`print(getStr().c_str())`. The first version is more efficient and less
ugly IMO. I want to emphasize, that it should be `boost::cref` not `std::
cref`, because `std::cref(std::string &&) = deleted`. It seems to me, that
prohibition of constructing `reference_wrapper` from temporary in C++11 is
one more argument in favor of my proposition to prohibit `string_ref`
construction from temporary string.
On Sat, Aug 2, 2014 at 2:24 AM, Marshall Clow It would mean that string_ref will no longer compile under C++03. Of course, I propose to hide it under corrsponding ifdefs. Something like
this:
#ifndef BOOST_NO_CXX11_RVALUE_REFERENCES
#ifndef BOOST_NO_CXX11_DELETED_FUNCTIONS
template<typename Allocator>
basic_string_ref(std::basic_string