Re: Fixed String review

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2019-11-27 17:23:10

On Wed, Nov 27, 2019 at 8:36 AM Phil Endecott via Boost
<boost_at_[hidden]> wrote:
> struct NameAndAddress {
>   static_string<14> firstname;
>   static_string<14> surname;
>   static_string<30> address_line_1;
>   static_string<22> city;
>   static_string<10> postcode;
> };

Ahh...I can't argue with this.  `sizeof(std::string)` is

* 32 bytes on gcc 8.3.0
* 24 bytes on clang 9.0.0

This is a pretty compelling argument, I am convinced. Therefore, this
library should provide specializations for optimizing small strings.
This could include storing the current size as (C-N) in the last
character position where C is the capacity and N is the size.

> (Yes, yes, you probably wouldn't want to make those fields fixed-size
> in real code, but it's an example we can all understand.)

Actually.... small fixed size fields come up in database applications
all the time. And with sizeof(std::string) being 32 bytes on clang, a
specialization will allow a generous 31 characters which is actually
quite nice.

> ...it's still going to be an improvement over using std::string's
> operator+.

Okay, I agree that we need to do _something_. I'm not sure exactly
what that something is. I'm hesitant to endorse operator+ because of
the unpredictable behavior. How about a free function `concat(...)`
which allows the caller to optionally specify the maximum capacity of
the resulting string,

> Vinnie, are you saying that this (i.e. small strings that are trivially-
> copyable) is not a supported use for the library?'

\sigh. Yes, it needs hash and probably the other stuff.

> auto sub_sv = std::string_view(s).substr(pos,count);

I can support this if there is consensus that substr() should return a
fixed capacity string instead of a view.

> Maybe std::string should have a method to do that more succinctly?

Umm... I think std::string has enough members :) it needs a rest.

> >> My initial thought was that static_string should be implemented
> >> on top of boost::container::static_vector<char>. My rationale...
> > ...
>
> Vinnie, I have literally just said that I'd prefer this to be an
> improved static_vector

You said it should use boost::container::static_vector. That's a
non-starter for me. A goal for the library is to not use any external
dependencies. I am also not a fan of Boost.Container's idiom of
Options template parameters. It confuses tooling and it is hard to
teach. I don't mind it in Boost.Intrusive because intrusive containers
are already a tool for experts. But I'd like the fixed capacity
strings to be more accessible. There are also string-specific
optimizations which wouldn't work if the implementation was tied to
static_vector. No I don't think that coupling the two is a good idea
at all.

Regards