Re: [boost] Fixed String review

On Mon, Dec 2, 2019 at 3:07 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

wt., 26 lis 2019 o 18:34 Vinnie Falco via Boost napisał(a):

...

On Tue, Nov 26, 2019 at 8:31 AM Phil Endecott via Boost wrote:

...

You've chosen to return a string_view from substr(). I think that's a bit dangerous; code that does "auto a = s.substr(...)" could end up with a dangling view when s is a fixed string; this makes it more difficult than it should be to migrate from one string type to another, or to write generic code.

Again we have to refer to the purpose of the container. People are using this for performance, the very last thing they want from substr() is to receive a copy. Users can opt-in to making a copy if they want, by constructing a new static_string from the string view returned by substr. If we go with your suggestion, no one can opt out of copies.

Even if this is a valid design choice when considered in separation, it is clearly in conflict with the goal of being a drop-in replacement for std::string. It looks like the library is aiming at being a drop-in replacement for some subset of usages of std::string. It would be beneficial to outline this subset clearly in the initial sections of the documentation.

+1. FWIW, I find "this is a drop-in replacement" to be a typically unattainable goal for anything that is not based on some kind of polymorphism (compile- or runtime). That is, the polymorphic drop-in mechanism only cares about a subset of API and/or behavior. Zach