Re: [boost] [string_ref] degree of conformance to standard proposal

Subject: Re: [boost] [string_ref] degree of conformance to standard proposal
From: Peter A. Bigot (pab_at_[hidden])
Date: 2013-12-22 20:51:19

On 12/22/2013 07:26 PM, Marshall Clow wrote:
>
> On Dec 22, 2013, at 6:21 AM, Peter A. Bigot <pab_at_[hidden]> wrote:
>
>> (Background: I need a string_view with features in N3762 that aren't in
>> N3442 (viz., pos parameters to the string methods).  I'm trying to
>> determine how much effort I should put into a set of patches to update
>> the Boost implementation to the latest draft proposal.)
>>
>> The default constructor for Boost.string_ref produces an object which
>> returns a null pointer from data().  N3442 and its successor N3762 both
>> require the return value from data() to be non-null
>> (http://isocpp.org/files/papers/N3762.html#h5o-5).
>
> Yeah; I’ve spoken to Jeffrey (author of the proposal) and will be filing a defect report about that.

Against N3762, or against Boost?

>
>> GCC's libstdc++ folks solved this by adding a constexpr unit length
>> string to serve as the base referenced object
>> (http://gcc.gnu.org/ml/libstdc++/2013-11/msg00104.html).  But for Boost
>> I don't see how this can be changed without introducing a link
>> dependency.
>
> Right.
>
> Not to mention that if you initialize a string_ref ( NULL, 0 )
> then requiring its’ data() call to return non-null means extra code.

Yeah, but it does make it compatible with std::basic_string which
(AFAICT) can never return a null pointer from data().

>
> If the length of the string_ref is 0, then the return value of data() is meaningless; you can’t do anything useful with it.
>
> * You can’t dereference it, any more than you can dereference the end() iterator of a vector.
> * You can’t compare it to a pointer in another container (undefined behavior).

But you *can* compare it to pointers in other string references to the
same underlying std::string or char array. In fact the delimiter
interface in N3593 makes use of this: when no more delimiters are found,
an empty string is returned with data() pointing to the end of the
underlying string, allowing the same code to be used to extract the
delimited sequence instead of having to special-case a check for end().

> * You can compare it with NULL, but what does that tell you?

Nothing; unless N3762 changes the check will never succeed.

>
>> In a cases like this, how closely does Boost want to track the standard
>> proposals?
>>
>> Similarly, the standard proposal has settled on *string_view instead of
>> *string_ref.  Would Boost rename the library/class, or just introduce an
>> alias?
>
> I have that on my to-do list.
>
> My thought is to rename the classes to match the standard, but keep the string_ref typedefs for compatibility.

That's the route I'd take.

>
> I will happily consider patches for the missing features.
> [ Though my opinion is that replicating the entire interface of std::string in string_[ref|view] is a mistake ]

https://github.com/pabigot/utility/tree/feature/N3762 has a bunch of
changes including a fix for #9518. There are still some missing
overloads which I'd prefer to fix before merging.

If you'd like, take a look at that branch as a work-in-progress. If you
have any comments I think you should be able to add them to the commits
even without a pull request. Please don't merge it; I haven't looked at
the corresponding documentation changes that should be part of each
commit yet. When I get around to that the branch will be rebased.

Peter