Here is my quick review in hope to throw in some fresh thoughts... - What is your evaluation of the potential usefulness of the library? Strings with internal buffer are quite useful and it's plainly wrong to say they aren't IMO. The "eliminate buffer overrun"-motivation is not generic enough for my taste, though. Putting fixed_stringS into STL containers (which in turn could use a custom allocator, e.g. Boost.Pool) can significantly reduce the allocation costs (and would be my no.1 use case for such a library). Thinking the above use case a bit further I would also want a cached hash value (invalidated when the string gets modified). AFAICS I would currently have to overload the whole non-const interface to implement this behaviour... Brings me to: - What is your evaluation of the design? The scope of the library should be widened to provide a policy-based general purpose strings implementation. There are a lot of enhancements that can be made in terms of strings (and memory management) -- where to but the buffer, whether the buffer has a fixed size and what to do if a string gets larger than some limit are only three aspects of it. Lots of interesting specializations come to my mind, such as a variable sized string type built upon a static buffer plus an optional dynamic buffer, intrusive hashing (as mentioned above), copy-on-write, immutable string handles, an SGI-ropes-style backend, etc (not that all these features must be implemented by the library, but the extension points for them should exist). - What is your evaluation of the documentation? Jumping from the introduction straight to *_impl stuff (BTW. I don't like these names to be part of a public interface) seems like a pretty rough transition... Generally the documentation doesn't read as smooth as the documentation of other Boost libraries (based on subjective feeling), but after other reviewers' comments have been addressed I believe it will so I won't go into further detail here. - Did you try to use the library? With what compiler? Did you have any problems? - What is your evaluation of the implementation? Didn't use the library, yet and didn't do enough source reading to judge the implementation. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A glance plus reading some of the discussion around the review. - Are you knowledgeable about the problem domain? Security? Not really. - Should the library be accepted as a Boost library? Generally I welcome components that increase the control over memory access/management. I think the functionality provided by the library is Boost-worthy but as a policy of a more general solution. I'm confident the author can provide it, so I vote for another review when it's done ( *duck* ;-) ). Regards, Tobias