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

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2006-01-31 04:13:05

Paul A Bristow wrote:
>As another silent downloader, I just want to agree that we really do need a
>fixed_string,
>(a less than ideal name for what I would call a bounded_capacity string).
>This one looks reasonable but I was unclear that it was the right one.

There are currently some design flaws that I intend to fix for the next 
review that have been discussed in other posts.

>I suggest that the answer is to reject for now, but ask Reece to do a LOT
>more work on the documentation.  It left me confused, and although this is
>not an uncommon state ;-) it would appear that I am not alone.

Hopefully, for the next review, the documentation should be a lot better.

>Doxygen is NOT helping at all - it is deluding the author in thinking the
>job is done automatically..

Doxygen is useful for creating a reference. It is not a substitute for a 
tutorial/overview/how to use guide, a la the Spirit documentation.

>What we need here is a full discussion of the rationale - pros and cons -
>for why this design is the least worst, at least.

I will come up with a list and post it later on today.

>(In the end, the language is at fault - it doesn't have built-in 
>array-bound
>checked arrays where the compiler at least knows the fixed maximum 
>capacity.
>While it might have been better if we hadn't started from there, we did, 
>and
>we are now seeking as good a bolt-on fix as possible.)

The C/C++ language was designed so that you didn't pay for (in performance 
and memory) what you didn't use. Bounds checking and overrun protection fall 
into this category. Also, as Dave has pointed out, in some applications it 
is bad to clip the string contents or throw an exception.

That said, slightly OT, if design by contract support becomes available in 
the language, you could add that bounds checking as pre/post conditions or 
class invariants.

- Reece