Rob Stewart wrote:

Subject: Re: [boost] Re: static sized strings Date: Tue, 1 Jun 2004 17:13:38 -0400 (EDT)

...

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

From: "Reece Dunn" <msclrhd@hotmail.com> 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.

My s[ i ] throws if i > capacity() which shouldn't cause a problem. s.at( i ) throws if i > length().

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.

Sure. I have been writing tests for my library (boost-sandbox/fixed_string/test/*.cpp) with a BBv2 file to do the testing. I have the C-style functions test cases posted and have made a start with the basic_string cases [21.3.1-4]. There still need to be tests for when the operations will cause buffer overflow on unprotected code, and generate exceptions for functions like s.at( i ), but I am waiting until I have written the basic test cases. The tests currently use my naming conventions, but I am sure they can be adapted for John's versions as well for comparisons. I could also implement bench marcking tests for performance analysis.

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).

That would be a good idea.

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.

Also a good idea. Regards, Reece _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963