Re: [boost] Re: static sized strings

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-06-01 16:13:38

From: "Reece Dunn" <msclrhd_at_[hidden]>
> 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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;