From: "Reece Dunn" <msclrhd@hotmail.com>
Rob Stewart wrote:
From: "Reece Dunn"
consider when doing this is that the strings don't exceed capacity, resulting in additional logic.
That should fail, shouldn't it? Yes, that would mean a swap() that throws, but the strings aren't really swapped if you only swap some characters.
The same is true though of all the other functions (e.g. assign): what happens if the string doesn't fit?
Those are different functions with different semantics. Assignment can fail for a variety of reasons. swap() isn't supposed to and it isn't supposed to throw.
I'm not sure which is worse: a swap() that throws or only partially swapping. The former violates exception safety guarantee assumptions made by other code, but the latter means that swap() may not really swap, which violates semantics.
I have gone for a clip to capacity design for all the fixed_string functions. Thus:
fixed_string< 5 > str; str.assign( "Hello there!" ); // str == "Hello"
That's perfectly reasonable but doesn't implicitly apply to swap(). It may be that there is no better solution than to apply that to swap(), but I don't think it does just because it applies to assign().
Any error handling policy that is implemented has it's own advantages and disadvantages. Another problem with using exceptions is adapting C code: there may not be any try-catch blocks in the code, resulting in unhandled exceptions.
The good news is that C code won't call swap()! That is, any code written in the C way won't think to call swap(); that's a C++ idiom. (Yes, I realize that we're talking about converting C code to use a C++ class, so many changes are possible, but I'm assuming that minimal changes are intended to such code.)
The clip strategy is not ideal either, but I believe it is the best approach considering the code it is abstracting: you will usually have a buffer large enough for the application you are using it for (filenames/paths, command line strings, URLs, etc.)
One possibility is making the error handling a policy class so it can be adapted to suit the users needs with the current behaviour as default.
I think clipping is appropriate. The whole point is that the client is supposed to allocate a string large enough to hold the expected data. If the code ever tries to store more than expected, the rest should just be truncated. I don't think there's any need to be fancier than that. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;