I have looked at both implementation and got some comments: 1. Both implementations use a size independent base class. I can see the need for such a class but don't understand how to use it in the way proposed. The base class only implements a few methods so in my view it is more or less useless. E.g. a function taking a "base" argument can't iterate or look at the string content without converting it to a c-string (so it could just as well use a c-string argument). Why not implement the full interface in the base class? 2. I couldn't find any background discussion on what non-const operations should be allowed on the string. Only the std::string interface is mentioned but since the fixed_string is guaranteed to be continuos it makes sense to also allow non-const access to the string. In both versions c_str() is const while data() is const only in the sandbox version. I think a const c_str() and non-const data() (as an overload to keep the std::string interface) is the way to go. 3. As mentioned in other posts, length is messy and I don't think there are any way to safely store the length inside the class. There will always be a risk that the non-const operations add/removes a '\0' in the wrong place. One solution may be to add something similar to the CString's "ReleaseBuffer()" (with a better name) that allows you to force an update of the length after an unsafe operation. And last just an idea I got from the flex_string implementation: Why not allow use of the "struct hack" as a performance option. e.g. template <typename CharT> class fixed_string_base { const size_t capacity_; mutable size_t length_; CharT str_[1]; protected: fixed_string_base(size_t n) : capacity_(n), length_(0) {} // std::string interface + special fixed_string operations }; typedef fixed_string_base<char> char_string; typedef fixed_string_base<wchar_t> wchar_string; template <size_t n, typename CharT> class fixed_string : public fixed_string_base<CharT> { CharT str_[n]; public: fixed_string() : fixed_string_base<CharT>(n) {} };