Martin wrote:
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?
Good point. That needs to be done.
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.
I wasn't too happy about "data", but it seems to be needed, given fixed_string's intended use as a retrofit to legacy code. People will want to code things like char_string<80> line; int cnt = read(fd,line.data(),line.capacity());
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.
I have such a function, but it's private, and used internally within the class. Do you think the lazy evaluation approach I used is good? I have mixed feelings. John Nagle