One such alternative is to be more similar to ArrayLists that have both a Capacity and a Length attributes, but that is surely overkill as Strings are immutable after creation, so I think StringBuilder is the one messing with the immutability of strings and should be corrected as you propose
Fun, Rafael "Monoman" Teixeira --------------------------------------- "To be creative means to be in love with life. You can be creative only if you love life enough that you want to enhance its beauty, you want to bring a little more music to it, a little more poetry to it, a little more dance to it." Osho On Thu, Dec 3, 2009 at 4:02 PM, Mark Probst <mark.pro...@gmail.com> wrote: > SGen, our new garbage collector, doesn't explicitly store an object's > size but determines it via the object's vtable and, in the case of > arrays and strings, via the length field. String.InternalSetLength > changes that length field, which means that, from SGen's view, the > string's size changes. That's a problem because depending on an > object's size it is either stored in a regular heap section or, if it > is larger than a certain threshold, in the large object section (LOS). > SGen depends on being able to distinguish between the two, so it must > not happen that an object changes size, i.e. we have to get rid of > String.InternalSetLength, which is used by StringBuilder. > > The attached patch fixes this problem, but of course it has to do more > copying. Does anybody object to this? Any alternatives? > > Mark > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
