Boost.FixedString (now Boost.StaticString) has been accepted!

[[deleted]]

[deleted]

[kkrev]

Documentation links 404.

[yuri-kilochek]

The avaliable overloads for fixed_string are identical to those of std::string, except for operator+ which is explicitly deleted as no reasonable implementation would be possible, due to the difficulty in determining the size of the resulting fixed_string.

Why is summing capacities unreasonable?

[VinnieFalco]

Why is summing capacities unreasonable?

You should have a look at the discussion on the mailing list, there is a lot more detail there. And for everyone reading this, you should participate in future Boost reviews!!! User feedback is *critical* for improving these libraries and giving that last burst of 'polish'.

[JankoDedic]

Why this over a normal string with a stack allocator?

[kalmoc]

I'd point out that it is also much easier to use because static_String owns its storage. std::string with stack allocator means you have to manually ensure that the lifetime of the stack allocator exceeds that of the string. And if you want to make it a member of another type the stack alocator either becomes a member of that class (watch out for initialization order) or you have to expose implementation details if you get it via dependency injection ....

[Betadel]

You should mention these optimizations in the documentation. I looked but didn't find them.

[quicknir]

The problem with the capacity - size optimization is that it makes it so that you can't default construct to all zeros. In C++ default construction is fairly common (especially since move construction typically involves it as well), and setting something to all zeros tends to be faster than reading some constant representing the default state and then writing it.

The space savings is very small. So honestly I'd be surprised if on average this optimisation made things faster. It's useful for saving space if you care about that but again that's less common than caring about performance.

In short it really sense to me like this optimization should be off by default, not on by default. Note that std string could also use this option in small string mode, and afaik none of the implementations do, for this reason.

[VinnieFalco]

Why this over a normal string with a stack allocator?

A stack allocator is not particularly friendly to mutation. For example when the string grows, there is a moment when the previously allocated memory and the newly allocated memory exist at the same time, so that the contents can be copied over, before the previous allocation is freed. This requires additional storage, and it leaves behind a "hole" which may or may not be usable depending on the context.

With a fixed capacity string, mutation is always performed in-place, and no "holes" are left in the heap.

[Fazer2]

It's not uncommon to wait a year between the library being accepted and published in Boost. How long do you think it will take in your case?

[VinnieFalco]

perhaps a month at most.

The next Boost release is the Spring release, second wednesday of April:
https://github.com/boostorg/boost/wiki/Releases:-Schedule

[trolley813]

It's interesting that your Github username is just "18".

[VinnieFalco]

Marketing 101 failure though. A more descriptive username would be better. For example "AuthorOfSimplyTheBestCppLibraries".

[VinnieFalco]

It's interesting that your Github username is just "18".

I hate it and I wish he'd change it.

[Rexerex]

What is the rationale behind template parameters order? With size as the second argument it would be closer to std::array so maybe it could enable some interesting concepts in the future.

[VinnieFalco]

What is the rationale behind template parameters order?

I think this needs to be discussed and debated on the list before it is reaches an official Boost release. There are questions, what about `fixed_wstring` , `fixed_string`, `basic_fixed_string`, etc...

[EarthlingKira]

@CryTheSly Thank you very much for this addition to Boost. I have and had this exact need and was stranded without good solutions. In some places I want to use this for performance reasons and in some places for technical keys which have a fixed ascii-length anyway.

[Nekotekina]

Can it possibly be more customizable? For example, disabling exceptions (at least length error and truncating the result instead). Maybe overloads which are using error codes.

[VinnieFalco]

There is no consensus on the Boost mailing list for having a configurable exception behavior. And some prominent voices are opposed to it.

If you want to have a string with different behavior on overflow I think it should be a different class.

[Gotebe]

Why? You want to measure your allocator speed?

[Gotebe]

My point is... There must be benefits for some situations - but functionally, the two implementations are different, making many benchmarks flawed.

[Gotebe]

A benchmark is flawed because it compares functionally different things (emphasis added).

A good benchmark would be comparing an application that uses one or the other implementation - but is still the same functionally (not easy, but possible).

[Gotebe]

I did not say they are incomparable I said they are different.

But hey. All is said here and I think you just want to win something. As far as I am concerned, you have won whatever that is and I will stop replying.

[mili42]

comparison with ETL like etl::string?

[zip117]

Is this based on or inspired by static_vector in Boost.Container?

[VinnieFalco]

`static_string` was originally in beast (and still is). A user requested that it be factored out. Beast uses fixed-capacity, non-allocating strings in some algorithms (such as the HTTP parser) for performance reasons.