I finally have an update for the string_ref proposal, converting it to
a set of changes against the C++14 draft. The most recent version
lives at https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
and I've attached a snapshot.
The LWG is still deciding whether this should aim for a TS or C++14
(or both?), and feedback from here will help inform that decision.
I've uploaded a new version to
http://jeffrey.yasskin.info/cxx/2012/string_ref.html with updates from
this thread. I'm planning to send this off to Clark tomorrow, although
if https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5sW8yp5i8mo/discussion
keeps agreeing on string_view, I may switch to that name first.
Ultimately, I think we want to allow this conversion based on detecting contiguous ranges. Any constructor we add to work around that is going to look like a wart in a couple years. I think we'll be better off making users explicitly convert when they can't add an appropriate conversion operator, and then we can add the optimal constructor when contiguous iterators make it into the library.
On Fri, Jan 11, 2013 at 2:48 AM, Nicol Bolas <jmck...@gmail.com> wrote:
> I don't like the idea of making a proposal somewhat incomplete (you do
> recognize the need for user-defined conversions) on the assumption that in a
> year or two someone will come along with a fix. I say we give the user the
> ability to provide something that will work and be extensible now. If the
> eventual Range proposal comes along that can't handle things this way, then
> we already have our solution. If another solution appears, we can use that.
> It may leave a wart, but it will be a very small and harmless one. And it's
> not like anyone will really notice one more wart in our string classes...
We don't have to wait a year or two, we could write a proposal to fix
the contiguous range detection issue tomorrow.
We don't have to wait a year or two, we could write a proposal to fixthe contiguous range detection issue tomorrow.
On Fri, Jan 11, 2013 at 4:18 PM, Nevin Liber <ne...@eviloverlord.com> wrote:Great!
> On 11 January 2013 02:52, Olaf van der Spek <olafv...@gmail.com> wrote:
>>
>> We don't have to wait a year or two, we could write a proposal to fix
>> the contiguous range detection issue tomorrow.
>
>
> FYI: I'm working on a contiguous_iterator_tag proposal for Bristol (but it
> probably won't be done before the mailing deadline next week).
Isn't that deadline today though?
Could you also consider a conversion operator to T* for such iterators?
On Fri, Jan 11, 2013 at 10:43 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>> We don't have to wait a year or two, we could write a proposal to fix
>> the contiguous range detection issue tomorrow.
>
>
> True. But if we put basic_string_ref/view into a TS, it won't necessarily
> have the contiguous range fix as part of the TS. So there will be no
> extensibility mechanism. Also, if that proposal doesn't make it for C++14
> and this one does, then again, we won't have an extensibility mechanism.
Actually can't we just define operator string_ref() on other classes?
On Fri, Jan 11, 2013 at 9:08 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>
>
> On Friday, January 11, 2013 8:30:44 AM UTC-8, Olaf van der Spek wrote:
>>
>> On Fri, Jan 11, 2013 at 5:17 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > The point would be for code we don't own. Like CString and the myriad of
>> > other string classes used by the multitude of C++ libraries out there.
>>
>> I hope the owners of these libs include support themselves.
>
>
> Reality always ensues. That's why we like customization points to be free
> functions, so that they can be implemented without modifying the class.
See also https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8t5EFJfLn0I/26ihRCq8N2sJ.
Sent from my BlackBerry 10 smartphone.
From: Ville Voutilainen Sent: Friday, January 11, 2013 1:12 PM Reply To: std-pr...@isocpp.org Subject: Re: [std-proposals] Re: Update to string_ref proposal |
--
I think the issue is auto conversion.Can a function that takes a string_view automatically take a CString, or do I need to call a conversion.
Note: The library provides implicit conversions from const charT* and std::basic_string<charT, ...> to std::basic_string_ref<charT, ...> so that user code can accept just std::basic_string_ref<charT> as a parameter wherever a sequence of characters is expected
constexpr int compare(basic_string_ref s) const noexcept;
constexpr int compare(const charT* s) const noexcept;If a single overload on basic_string_ref isn't good enough for basic_string_ref members, why should it be acceptable for "user code"?Add a sub-subclause "x.y.2 basic_string_ref iterator support [string.ref.iterators]"
typedef implementation-defined const_iterator;
A random-access, contiguous iterator type.Where is the notion of a contiguous iterator defined?
In the declaration of the interface, const charT& basic_string_ref::at( size_t pos ) const
which is inconsistent with the detailed description later on: constexpr const_reference at( size_type pos ) const.
- Is declared with a parameter of type size_t instead of size_type
- is not declared constexpr
I finally have an update for the string_ref proposal, converting it to
a set of changes against the C++14 draft. The most recent version
lives at https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
and I've attached a snapshot.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.html#string.view.ops
"This conversion is explicit to avoid accidental O(N) operations on
type mismatches."
On Friday, October 10, 2014 4:41:35 PM UTC-4, Ville Voutilainen wrote:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4081.html#string.view.ops
"This conversion is explicit to avoid accidental O(N) operations on
type mismatches."I'm not sure I agree with this decision. In my view (pun not intended), string_view should become the default way to pass around const references to string. That is passing around const std::string& and const char* will disappear in favor of std::string_view (by value). Similarly we won't pass around const std::vector<T>& anymore but instead std::array_view<T>. Not only are the views more efficient (one less indirection), but they also make interfaces much more flexible by accepting a range like concept instead of hard container type. Having to say foo(std::string_view("abc")) is very clumsy.
On Tue, Oct 28, 2014 at 4:06 PM, Tony V E <tvan...@gmail.com> wrote:
> Now with string_view, we have a 3rd choice. Safer than char *, faster than
> string, more general than either. So we don't want to encourage the
> conversion to string. We'd prefer you fall into and stay in the
> "string_view valley", and do extra work to get out of the valley in either
> direction (toward string or char *). ie instead of foo(someStringView)
> working (implicitly), we subtly encourage you change foo() to take a
> string_view.
Are there no good reasons to have a string value / reference anymore?
What if I need c_str()?
IMO having an explicit constructor to encourage people to use
string_view as parameter type doesn't seem right.
What if it's a third-party lib that can't be easily updated?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
> std::string s("Hi there");
> std::string_view v(s);
> bool equal = (s == v); // ambiguity!
Shouldn't comparisons be doable without any conversions?