New Boost version and new libraries

A new (for me) version of Boost is available (1.73.0) and has two new libraries that look interesting.

Boost.Nowide and Boost.StaticString.

Any thoughts on those libraries?
nowide is something many people approached from slightly different angles, nice to see it distilled to a boost library.

static_string was extracted from boost.beast internals into a reusable component, and is pretty much the same as static_vector from boost.container, just with string API. std::string API is not something to be proud of, but it did become universally known and useful.
Last edited on
I understand why Boost.Nowide came about, trying to make Windows deal with Unicode as other operating systems do. UTF-8 vs. UTF-16. A simple concept that is unfortunately revolutionary.

Boost.StaticString OTOH, is a bit more of a head-scratch for me. std::string's capacity isn't set at compile time?

std::string API is not something to be proud of

Yet the library authors chose to replicate much of the std::string API for their boost:static_string API. Less than perfect design lives on. :(

Am I correct in understanding that boost:static_string stores its data on the stack instead of the heap as std::string supposedly does?

I sure wish there were some examples for using these two libraries available, even if brief code snippets in the Boost documentation. Other Boost libraries have examples to play with.
std::string's capacity isn't set at compile time?

Without checking references, I assume it works like std::vector in that it dynamically manages memory at runtime if it needs to.

Yet the library authors chose to replicate much of the std::string API for their boost:static_string API. Less than perfect design lives on. :(


If you'd managed to make it all the way to the end of the sentence you half-quoted, you'd see that preserving the API is exactly the point - it's something that all C++ developers are (or should be) familar with, so won't have to learn an unfamilar API (with the inevitable mistakes that brings with it); also it can be easily slotted in to replace std::string without refactoring the code that uses it.

Preserving what you call a bad API isn't a mistake or a bad decision, it's a major reason for having the class in the first place.

Last edited on
Topic archived. No new replies allowed.