I have tested the sandbox version of the static sized strings. It works fine but there are a few inconveniences that I want to point out. 1. The abstract base class. --------------------------- Having an ABC to handle fixed strings of various lengths is a good idea but it is not very practical. I understand that the main purpose is to allow fixed strings to be passed to functions without using templates. int countwords(const boost::char_string & str); unfortunatly the ABC makes it difficult to pass anything but fixed strings. If you want to pass a string literal, a character array or a std::string you must create a temporary fixed_string<>. countwords(boost::fixed_string<20>("The quick brown fox")); Don't really have a good solution but maybe the base class could use an external buffer with constructors from char* and std::string. class char_string { const char* const extbuf; size_t len; protected: char_string() : extbuf(NULL) {} // not used since derived implements its own buffer public: char_string(const char* c) : extbuf(c), len(strlen(c)) {} char_string(const std::string& str) : extbuf(str.c_str()), len(str.length()) {} ... // virtual basic_string interface } Don't know how to handle non-const char[]. 2. Substrings ------------- One of the applications I can see for fixed_string is when you want to avoid dynamic allocation but still want to use the std::string interface and algorithms. In that perspective it seems strange that substr returns a std::string instead of a fixed_string. 3. resize --------- Still missing a method to update the length to reflect the current string length. I think a resize without arguments would be a good solution. boost::fixed_string str<10> strtime(str.buffer()); str.resize(); 4. operator[] ------------------------- I don't have the standard basic_string interface available but I am pretty sure that operator[] doesn't throw an exception if the argument is outside max_size(). I also looked at the alternative fixed_string implemenatation but since that version doesn't have full std::string interface I didn't test it. I am not sure I like the lazy length calculation for two reasons. - In my view, strlen is normally a "cheap" operation comparable to a function call. If the lazy evaluation prevents a function from being inlined, the benefit is lost. - It is tricky to detect when the length is invalid. With the current implementation, I can't say if the length is valid or not after "str[4] = str [5]" since that depends on the order of evaluation of "str[4]" and "str[5]".