[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

20017: [MUD-Dev] [TECH] String Classes, Memory Management, and Fragmentation

[Full Header] [Plain Text]
From: "Adam Martin" <amsm2@cam.ac.uk>
Newsgroups: nu.kanga.list.mud-dev
Date: Fri, 13 Jul 2001 09:20:18 +0100
References: [1]
Organization: Kanga.Nu
----- Original Message -----
From: <Daniel.Harman@barclayscapital.com>

> In java at least you shouldn't reuse the Stringbuffer objects
> either. If I recall correctly, Java Stringbuffers grow, but they
> don't shrink :) This is a real problem if you are using a string
> buffer that has grown a lot, as when you copy it to a string, it
> copies the whole buffer, not just the bit you think is
> populates. You then end up with some very large padded strings.
> So you end up having to create lots of string buffer objects,
> which takes you back to the first problem I mentioned! (That last
> bit about copying the whole buffer not just the data you think is
> in it, I am 98% sure is accurate, but I don't have time to check
> for now, and its how I remember it).

Could you please explain that a bit further? I understand the
problems with the immutable String objects w.r.t GC, but I'd not
noticed problems with StringBuffer's, and I can't understand how
what you describe would work?

The bit in particular where you say "as when you copy it to a
string, it copies the whole buffer, not just the bit you think it
populates. You then end up with some very large padded strings." -
Surely, if the resulting String is any larger than it should be,
then it will not be the correct String, and the result is incorrect?

Sorry if I'm missing something obvious!

Adam M

_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev