Re: [boost] [string_ref] string literal constructor

Subject: Re: [boost] [string_ref] string literal constructor
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-11-07 18:40:45

On Nov 7, 2013, at 5:00 PM, Gavin Lambert <gavinl_at_[hidden]> wrote:

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

If code assumes a string_ref refers to a null-terminated string, that code is wrong.

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

Why not add named constructors to clarify the caller's intent?

___
Rob

(Sent from my portable computation engine)