On Wed, Nov 27, 2019 at 8:36 AM Phil Endecott via Boost
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