[boost] Re: static sized strings

From: John Nagle (nagle_at_[hidden])
Date: 2004-05-25 10:57:32

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