Re: [boost] Re: static sized strings

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-06-01 18:30:02

Rob Stewart wrote:
>Subject: Re: [boost] Re: static sized strings
>Date: Tue, 1 Jun 2004 17:13:38 -0400 (EDT)
>
>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.

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