From: Pavel Antokolsky aka Zigmar (zigmar_at_[hidden])
Date: 2006-01-30 04:52:07
On 1/30/06, Reece Dunn <msclrhd_at_[hidden]> wrote:
> Pavel Antokolsky aka Zigmar wrote:
> >For me personally, the reason I didn't submit any review, that I'm not
> >completely understand the purpose of the library. The documentation
> >(as few mentioned) lacks motivation and general description. So how
> >can I review the library, if I can't understand what the library is
> >trying to solve and how. I can't say for others, but for it is the
> >reason. I suggest that even if documentation can't be updated during
> >formal review, that the author will give a little more extended
> >explanation here, at mail list.
> If the introduction does not make this clear, I have written the
> documentation wrong. *This* is why feedback is useful - to know what people
> don't understand about the documentation, so I can address those issues for
> the next review. Otherwise, the documentation will most likely still suffer
> from the same problems.
Unfortunatly, it is not clear. Now, I'm beginning to see the point.
Originally, after the reading introcution, especially first sentence
"There is a lot of C (and even C++) code, that uses character
buffers and the C-style string functions for various reasons: updating
legacy C code, wanting to keep executable size down without linking to
a large dynamic library or wanting to tune performance by keeping the
strings on the stack."
) I've got the idea, that the main purpose it to create _fast_
stack-based strings with C++ interface (something like boost::array),
and buffer overrun protection are just nice feature of such strings.
As far as I understand now from you description, previews reviews and
my look at the code, perfomance is not a main goal at all, and the
buffer protection is the target. But then, why string should be
"fixed" (and, AFAIU, it is not exactly fixed)? Isn't it just, say,
safe_string? I'm not criticizing, just trying to understand the
-- Best regards, Zigmar
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk