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