string in Stack or Heap ? - Page 2
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 19 of 19

Thread: string in Stack or Heap ?

  1. #16
    Join Date
    Mar 2007
    Posts
    155

    Re: string in Stack or Heap ?

    Quote Originally Posted by BigEd781 View Post
    No, it is immutable simply because the class gives you no way to change its member data. Look at this class:

    Code:
    class Foo
    {
        public readonly int Id;
        public readonly string Name;
    
        public Foo( int id, string name )
        {
            Id = id;
            Name = name;
        }
    }
    That class is immutable. You pass some data into the constructor, the data is set, and now there is no way that it can be changed by the outside world.
    Brilliant. Very nice example.
    So all of it's member must be const/readonly. And string might have internally implemented similiar pattern. Am I right ?
    Last edited by thomus07; July 29th, 2009 at 10:50 PM.

  2. #17
    Join Date
    Jun 2008
    Posts
    2,477

    Re: string in Stack or Heap ?

    Well, it could have non-const data within the class, but I think you get the point; the class does not expose a way for the outside world to change said data, and that data is guaranteed to not be changed during the lifetime of the object. The string class will have an internal char[] that contains the actual string data. Whenever you call a method that seems to change the string, you are actually getting a new (new String( data )) back in return.

    An immutable class will simply not allow its state to be changed, period. This makes a class like that great for dealing with concurrency because you do not have to worry about intermediate states between writes and reads.

  3. #18
    Join Date
    Mar 2007
    Posts
    155

    Re: string in Stack or Heap ?

    Quote Originally Posted by BigEd781 View Post
    Well, it could have non-const data within the class, but I think you get the point; the class does not expose a way for the outside world to change said data, and that data is guaranteed to not be changed during the lifetime of the object. The string class will have an internal char[] that contains the actual string data. Whenever you call a method that seems to change the string, you are actually getting a new (new String( data )) back in return.

    An immutable class will simply not allow its state to be changed, period. This makes a class like that great for dealing with concurrency because you do not have to worry about intermediate states between writes and reads.
    Thanks again.

    So it's way clear now.

    So every time, when a string provides an illusion to change it's data, it's actually creating a new string object internally. And the original data is unchanged.

    After doing some research on this subject, I think it's an attempt to give a value type behavior to strings. Also as you told, it tries to provide const type behavior to strings, which is greatly helpful while using them in functions.
    But I figure out one disadvantage:

    Lets create an object to occupy 4 bytes say - A, B, C, D.
    When I want another 'E', it is NOT expanding the current memory, but it simply forgets, and create a new memory in entirely new location.
    So this is sort of an overhead.

    (Let's don't jump into StringBuilder for now)

    I believe there should be valid reasons, that are more critical comparing this overhead.

    I think the reason to be to - Take the value type advantage. Am I right ?
    Last edited by thomus07; July 30th, 2009 at 11:53 PM.

  4. #19
    Join Date
    May 2007
    Posts
    1,546

    Re: string in Stack or Heap ?

    If strings were mutable then every internal .NET function which returns a string would have to clone the string and return a copy. If you wrote a library, every place where you receive a user string and store it you'd have to clone it, every place you return a string to the user you'd have to clone it.

    It'd become a giant source of bugs and issues.

    The other thing is it's not possible to 'expand' a memory location as you suggest. If you want a 10 char string, you'd want .NET to allocate exactly 10 chars of space, otherwise you'd be wasting memory. So, what happens if you want to append a character? You have to get another memory location containing *11* chars of space, copy over the original 10 chars and append the new char. Essentially exactly what .NET does

    Of course, you could always hide this inside the string class, but as i said, it'd lead to a whole host of bugs and not give any performance benefits.
    www.monotorrent.com For all your .NET bittorrent needs

    NOTE: My code snippets are just snippets. They demonstrate an idea which can be adapted by you to solve your problem. They are not 100% complete and fully functional solutions equipped with error handling.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center