Re: System::String class design decisions

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Edward Diener (eddielee_at_tropicsoft.com)
Date: 02/16/04 

Date: Mon, 16 Feb 2004 18:32:54 -0500

Eric Newton wrote:
> There's also the notion that we think of strings as one "thing"
> instead of a group of chars in memory, all consec. ordered near each
> other... whereas int's and even decimal's are represented by a finite
> space of memory bytes... hence why strings arent value types, as the
> concept goes...

That is true, but I like the analogy that value types are fairly simple as
far as the data they contain is concerned while ref types have much more
complicated data requirements. By this analogy System::String should be a
value type.

>
> Personally I like the immutability of it, and using StringBuilder isnt
> internally modifying a string... its modifying a char array that
> looks like a string but if you look closely, there's always some
> padding at the end of the internal "string"

I think it is a kludge, whereas modifying strings directly is a much clearer
and easier programming idiom.

>
> As more seasoned developers, we just need to stress the importance of
> encouraging string manipulation via StringBuilder or via char arrays,
> and help the novice developers understand why this is a better
> practice.

I do understand that manipulating strings as character arrays in-place is
better, or more natural, so perhaps that is what you mean. Still I would
have preferred Sytem::String to have the same ability to manipulate string
in-place, as a character array, as System::Text::StringBuilder and dispense
with the latter.

>Especially in light of C++ strings which were easy to
> overflow and hence write arbitrary code...

This last doesn't make sense to me unless you are talking about C
null-terminated strings. I admit that because of std::string in C++ I
haven't used a C null-terminated string in many years. Of course one can try
to assign a character to a std::string position which doesn't exist, but I
think this usage of std::string is really minimal given all of the
functionality in the class for manipulating strings via member functions. I
find std::string to be much more usable than
System::String-System::Text::StringBuilder, or any other string class past
or present.

>
>
>
> "Edward Diener" <eddielee@tropicsoft.com> wrote in message
> news:%23gDDhhm8DHA.2676@TK2MSFTNGP10.phx.gbl...
>> Am I curious about two of the major design decisions for the
>> System::String class and why they were made. Those two decisions are:
>>
>> 1) System::String is an immutable class, with
>> System::Text::StringBuilder being the class that allows a string to
>> be modified internally. 2) System::String is a reference class
>> rather than a value class.
>>
>> OK, I will admit right off, rather than try to forestall my
>> criticism of these design decisions in some other way, that I am a
>> C++ progammer and that the std::string class in C++ is mutable and
>> almost always stack-based in actual use rather than dynamically
>> allocated. Given that prior orientation, and knowing that the Java
>> string class, like the .NET System::String class, is also immutable
>> and reference based, I am still curious as to the design decision in
>> .NET to follow this same path.
>>
>> The practical reason I mention this is that it seems as if it would
>> have been much easier from the programmer's point of view to deal
>> with System::String as a value class and as a mutable class, rather
>> than have to:
>>
>> 1) Make changes to System::String which returns another dynamically
>> allocated System::String, or using another class,
>> System::Text::StringBuilder just to make changes, something which
>> seems like a kludge to me.
>> 2) Create System::Strings simply by writing 'System::String x(...some
>> constructor)' without having to write 'System::String x = new
>> System::String(...some constructor)'.
>>
>> I do realize that any string class which can contain a variable
>> length series of characters does have to use dynamic memory
>> internally, so that my criticism of the second design decision above
>> is not base directly on using dynamic memory rather than stack-based
>> memory. My questioning of the design decsions above, and being
>> interested in any justifications for them, is based on ease of use
>> from the programmer's point of view. To me it is much easier to be
>> able to instantiate a string class directly as a stack-based object,
>> and change that particular object if necessary, than to have to
>> instantiate a string as a dynamically allocated object, and have
>> changes made to that object result in a new string being dynamically
>> allocated and passed back to me.

Relevant Pages

  • Re: Segmentation fault
    ... Here you ask for a pointer to char. ... to a random position in memory. ... There's nothing else than a string the user could enter;-) ... to the use of scanf(). ...
    (comp.lang.c)
  • Re: Degenerate strcmp
    ... thing of searching through the memory at s1 and s2. ... pointers are passed to strcmp. ... actually a string. ... I think the subtle point is the following: a char * isn't actually the ...
    (comp.lang.c)
  • Re: Something wrong in my program
    ... what becomes of the memory block starting at this address is no ... our text buffer can contain 15 characters ... a string is a char array *terminated ...
    (comp.lang.c)
  • Re: return a string
    ... Here, you're saying to return a character, not a string. ... char * prt_tralha ... since you've allocated new memory for tralha. ... the third compiler error. ...
    (comp.lang.c)
  • Re: Concat some string not ended...
    ... > i try to concat some string not ended ... What you're dealing here with are simple char arrays ... 'size' isn't compile-time constant and thus the length of the array ... a char pointer and than allocate enough memory. ...
    (comp.unix.programmer)