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
> > several errors in my code making it operate better as a basic_string
> > interface and have seperated the safe_string.hpp file into the
> > headers (fsstring.hpp for string.h, fsstdio.hpp for stdio.h and
> > for wchar.h). I have also posted BoostBook format documentation to the
> > section.
> > However, we are still no closer to deciding which implementation to
> > We can either:
> >  Choose one implementation and drop the other (possibly collaborate);
> >  Continue both and put them against each other to see which is
> >  Drop both and develop one together from scratch.
> > Option  is not viable, since a lot of the hard work has already been
> > (size issues, etc.). I would like the implementation we use to be mine
> > I'm sure John feels the same way about his. I am also getting to the
> > 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
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
Also a good idea.
Is your PC infected? Get a FREE online computer virus scan from McAfee®
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk