Re: [boost] [string_ref] string literal constructor

Subject: Re: [boost] [string_ref] string literal constructor
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-07 17:00:22

On 7/11/2013 20:33, Quoth Antony Polukhin:
> But from the view of usability user may assume that library will
> determinate the size in this situation:
>
> const char s[] = {'0', '1', '2'}; /* User knows that this is not zero
> terminated*/
> string_ref test(s); // Size of array is determinated at this point. Why not
> have {ptr, 3}?
>
> Questions about nonzero terminated strings arise quite often.
>
> On the other hand, if we apply the strlen_s then users may be surprised by
> the following:
>
> const char s[] = {'0', '1', '2', '\0', '\1'}; /* User knows that this has
> fixed size*/
> string_ref test(s); // Size of array is determinated at this point. Why *we
> have* {ptr, 3}?
>
> Looks like there is no solution that will satisfy all the users.

Which is why I think it ought to be explicit (always requiring the size 
to be provided -- the app can call a strlen_s equivalent itself if it 
wishes that behaviour).

The first example in particular actually seems potentially dangerous to 
me, because the ability to handle the non-terminated string is "hidden", 
making it more likely that the author would forget and pass s to 
something else that's expecting a terminated string.

Or perhaps they get into the habit of writing code like the first 
example, and then at some point someone moves s to be a parameter (or 
extracts the string_ref construction into a subfunction).  This code 
style increases the risk that they won't notice the array decaying into 
a pointer and end up calling the non-array constructor, which is 
expecting a terminated string.