Re: [boost] [Review] Fixed Strings review period extended

From: John Maddock (john_at_[hidden])
Date: 2006-01-30 06:03:33

> As you might have expected, I read through the reviews _very_
> carefully.
>
> There are two reasons, why I proposed to extend this review.
> 1) The library was downloaded by more than 400 interested people and
> I don't expect the 3 reviews to represent all of them.
> 2) Even if the currently reviewed library won't be accepted to Boost
> mainly for the reasons stated by the three reviews, I think we need a
> Fixed Strings library in Boost and the more dicussion we get the
> better for a future library.

As one as the silent downloaders, here's my non-review:

1) The introduction and rationale to the docs are very encouraging, they 
lead me to think that there's a good little library here, but...
2) Once you get past the introduction things go downhill (sorry Reece). 
Really the docs have all the problems that lead me to dislike Doxygen docs 
in general: too much detail in all the places you don't need it 
(implementation details) and too little detail where required: for example 
the fixed_string class has next to no docs - just a list of constructors and 
assign member functions.  Where are all the other basic_string interfaces? 
The introduction seems to suggets that they should be there, but there's 
nothing in the docs.  Could be that they're present in a base class, but as 
a potential user *I don't want to know that*, I just want "give me the 
interface, and give it to me fast".

Doc's asside let me throw in a couple of design questions, these are all 
open issues BTW and just me thinking out loud really:

1) Should the fixed_string be an aggregate?

Currently we have Boost.Array that is an aggregate, but this design is not? 
If it were fixed_strings could be statically initialised:

fixed_string<char, 10> s = { "abc" };

Potentially this leads to problems with the string length not being 
initialised (or set wrongly), but I believe there may be solutions to that 
(use the value zero as a "not set" value, and lazy initialise the length on 
demand).

2) Do we need all the these policies?

There seems to be a lot of detail about various policies (formatting for 
example) that I would have expected to "just work", while the one policy 
that most people seem to want (overflow control) is missing).

Those were this issues that stood out to me, but with apologies to Reece, I 
should stress that I haven't been able to give this the time it deserves.

Regards, John.