From: "Reece Dunn" <msclrhd@hotmail.com>

John Nagle wrote:

...

I've done some cleanup on my version of fixed_string at http://www.animats.com/source [snip] We're approaching convergence on this.

We are both working on variations of the same idea. As such, I have fixed several errors in my code making it operate better as a basic_string interface and have seperated the safe_string.hpp file into the appropriate headers (fsstring.hpp for string.h, fsstdio.hpp for stdio.h and fswchar.hpp for wchar.h). I have also posted BoostBook format documentation to the libs section.

However, we are still no closer to deciding which implementation to choose. We can either: [1] Choose one implementation and drop the other (possibly collaborate); [2] Continue both and put them against each other to see which is better; [3] Drop both and develop one together from scratch.

Option [3] is not viable, since a lot of the hard work has already been done (size issues, etc.). I would like the implementation we use to be mine and I'm sure John feels the same way about his. I am also getting to the stage where I am considering putting mine up for review (once I get the tests written).

John hasn't fleshed out his design quite as completely as you have yours, but he's close. John just raised a new point: accessing the N + 1'st element. That may not have been apparent had he not been working on his own version -- or have you already dealt with that? -- so both implementations remain useful. I laid out a plan previously for how to judge between the implementations. I suggest waiting to have either reviewed until you can both run your code through the same tests -- with and without errors -- to see if there is a clear winner. Another possible means to judge between the two is to find real-world C code using strings, that compiles with a C++ compiler. Then, each library author can translate the code according to the needs of the libraries. Diffs will reveal the extent of the changes needed, and copious notes could illustrate common mistakes made and error messages encountered during the translation. That information can clarify which design makes the translation of C string code into fixed_string code easiest (performance will have already been ascertained, so needn't be reassessed). If that doesn't reveal a clear winner, I've a suggestion for breaking the tie: I can pass the options through a coworker of mine. He was a C programmer for a very long time and has been writing C++ code for less time. He still thinks like a C programmer in a lot of ways, so he might have insights we're missing. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;