On 29 Jul 2003 16:06:37 GMT, "Oliver S." <Fo*******@gmx.net> wrote:
Why not just use a fixed-size char array, and not make out-of-bounds
errors?
Because that's by far not that handy.
In that case, why not use a reserve()'d string? Or a vector<char>?
What is not handy? Writing solid code? (Not a jab) Or are there
additional methods in your class (like formatting methods) that add
handiness to the char buffer? I agree that writing solid code isn't
easy; but that's why we get paid pretty well, and that's the glamorous
life of a C/C++ programmer.
It seems to me that you are essentially using a fixed-size char[] with
extra stuff plunked on top. That extra stuff can only be useful while
still developing code, in helping find the code that causes buffer
overruns etc. That is, once you have found and eliminated the bugs in
the code that uses the strings, the extra code youv'e added to your
char[] buffer has lost its usefullness. At that point, it is less
efficient than just using the raw buffer (in terms of memory, speed
and maintainability), so why do it?
Maybe I'm missing something. You have said that in most cases the
programmer will "know" how big the buffer will need to be in advance.
But suppose they don't. Suppose they want to use your string class in
a function that takes a variable number of paramaters, like in a
specialized version of sprintf. Then you throw an exception when the
buffer gets too big, essentially telling the calling code, "You
screwed up in calling me, now deal with this." Pretty rude,
especially if the fault isn't on the caller, but the fact that a
fixed-length buffer is of very limited usefullness. Furthermore, in
order to write robust, industrial code, everybody who uses your string
class will need to wrap all thier calls in try{}catch{} blocks,
greatly degrading performance. What a hassle.
Again I ask you, why not just use a fixed-length char buffer and avoid
all this mess?
</dib>
John Dibling
Witty banter omitted for your protection