 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Karl Heinz Buchegger
Guest
|
 Posted: Tue Jul 29, 2003 2:31 pm Post subject: Re: string-class |
 |
|
"Oliver S." wrote:
| Quote: |
You allocate the maximum chunk of memory for *every* string object,
even for a null string? What an idea! I bet no one ever tried such
a thing.
Millions of developers tried this
|
Might be. They tried this because
* it is a good exercise
* they need to practice dynamic memory management
| Quote: | because it's exactly the
C-way except that I'm doing a bounds-check here.
|
If you want it the C way, then do it the C way. In C++
this is not a good idea. And btw: you expect a *huge*
speed increase, do you? I tell you a secret: it will
not happen. The guys writing std::string aren't that
dumb. They don't reallocate every time a string gets
larger. There are good and very effective strategies to
avoid this.
--
Karl Heinz Buchegger
[email]kbuchegg (AT) gascad (DOT) at[/email]
|
|
| Back to top |
|
 |
John Dibling
Guest
|
| Posted: Tue Jul 29, 2003 2:43 pm Post subject: Re: string-class |
|
|
On 28 Jul 2003 23:11:41 GMT, "Oliver S." <Follow.Me (AT) gmx (DOT) net> wrote:
| Quote: | I've developed a string-class that holds the string in an array which
is a member-variable of the class and that has maximum-size which is con-
figurable through a template-parameter. If any operation would grow the
string beyond its maximum size, an exeception would be thrown. This kind
of string obviously has superior performance over a std::string because
there's never any additional memory-allocation. But before I'm going to
re-invent the wheel, I'd like to ask if someone here alreay encountered
a fully-fledged implementation of such a string-class on the web.
|
Why not just use a fixed-size char array, and not make out-of-bounds
errors?
</dib>
John Dibling
Witty banter omitted for your protection
|
|
| Back to top |
|
|
John Dibling
Guest
|
| Posted: Tue Jul 29, 2003 4:46 pm Post subject: Re: string-class |
|
|
On 29 Jul 2003 16:06:37 GMT, "Oliver S." <Follow.Me (AT) gmx (DOT) net> wrote:
| Quote: | 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
|
|
| Back to top |
|
|
John Dibling
Guest
|
| Posted: Tue Jul 29, 2003 10:52 pm Post subject: Re: string-class |
|
|
On 29 Jul 2003 21:56:36 GMT, "Oliver S." <Follow.Me (AT) gmx (DOT) net> wrote:
| Quote: | In that case, why not use a reserve()'d string?
Because even this needs an allocation/deallocation-pair.
|
Even a raw buffer needs to be allocated and deallocated. A
reserve()'s string can be reserve()'s by a ctor call, ensuring that
there aren't uneeded allocations. So this point is a wash.
| Quote: | A class like the one I suggested should have methods for string-typical
operations like the formatting-operations you mentioned.
|
[snip]
| Quote: | Most of the usefulness comes from the formatting-options (which are easy
to implement somewhat faster than formatting with the stupid stream-modi-
fiers of the iostream-lib). The bounds-checking is just one tiny feature.
|
Ok, now I think we are getting to the root of the issue. Suffer my
predictions of your reasoning, and please correct me as needed.
You feel that std::string is inadequate for 2 main reasons: 1) you
don't like the alloc/dealloc scheme it employs, and 2) it doesn't
provide comprehensive string support functions, like sprintf().
| Quote: | I didn't suggest the depicted string-class for general purpose ! But
I claim that a lot of std::string-uses could be replaced by such string
-objects and thereby significantly lowering the CPU-time string-opera-
tions take.
|
Much of industrial code consists of formatting short strings. I agree
that std::string's is often too inefficient as compared to using a raw
buffer for such formatting. But very often these formatted strings
need to then be saved in memory for a while, and a raw buffer isn't
the right tool for that job either. But combining the use of raw
buffers for formatting with std::strings for the occasional retention
of string data provides what I think is a very effective solution to
both problems. Maybe Iv'e just gotten used to this model of
programming, but I also find it to be an elegant and completely
general-purpose solution.
</dib>
John Dibling
Witty banter omitted for your protection
|
|
| Back to top |
|
|
Karl Heinz Buchegger
Guest
|
| Posted: Wed Jul 30, 2003 9:06 am Post subject: Re: string-class |
|
|
"Oliver S." wrote:
| Quote: |
If you want it the C way, then do it the C way.
In most cases you can estimate the maximum string-length a string will
have. So my suggested approach is suitable for all this cases. With the
lib I started you simply give the maximum lentgh as a template-parame-
ter and the calls would throw an exception if the bounds would be excee-
ded (a solution that does a fallback to heap-based strings in this case
would be most elegant, although I doubt that this is really needed).
In C++ this is not a good idea.
That's your opinion that bases on your personal preferences; nothing
more.
|
Oh. I already tested std::string compared to fixed length character
buffers. I found that in my applications it doesn't make a difference
in terms of speed. But the safety and ease that std::string brings
is more then worth that small spees penalty. And yes: The penalty
has always been small in real world programs.
--
Karl Heinz Buchegger
[email]kbuchegg (AT) gascad (DOT) at[/email]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
