What, exactly constitutes a mutable action on an instance?

  • Though it's clearly defined in the docs when to use NSMubleAnything vs. NSAnything (insert Array, Dictionary, String, etc for Anything), there is no compiler warning when you perform a simple action such as allocate a string and then reassign values to it.

    With this in mind, what exactly constitutes a mutable action?

    If we take this:

    NSString *myString;
    myString = @"Hi";
    myString = @"Hi there";

    I'm clearly expecting some type of warning from the compiler when myString is redefined, but I don't see one in Xcode 4.6.1.  Is this redefinition not a mutable action?  It sure seems like it is.

    Thanks in advance.
  • On May 28, 2013, at 08:39:21, Alex Zavatone <zav...> wrote:

    > Though it's clearly defined in the docs when to use NSMubleAnything vs. NSAnything (insert Array, Dictionary, String, etc for Anything), there is no compiler warning when you perform a simple action such as allocate a string and then reassign values to it.
    >
    > With this in mind, what exactly constitutes a mutable action?
    >
    > If we take this:
    >
    > NSString *myString;
    > myString = @"Hi";
    > myString = @"Hi there";
    >
    > I'm clearly expecting some type of warning from the compiler when myString is redefined, but I don't see one in Xcode 4.6.1.  Is this redefinition not a mutable action?  It sure seems like it is.

    The example you've given is not changing the string, it's simply pointing the string pointer to a new string (changing the address it points to). This would require a mutable string:

    [myString appendString:@"Hi there"];

    because it's changing the string, but it will leave myString at the same pointer address.

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • On 28 May, 2013, at 9:39 PM, Alex Zavatone <zav...> wrote:

    > Though it's clearly defined in the docs when to use NSMubleAnything vs. NSAnything (insert Array, Dictionary, String, etc for Anything), there is no compiler warning when you perform a simple action such as allocate a string and then reassign values to it.
    >
    > With this in mind, what exactly constitutes a mutable action?
    >
    > If we take this:
    >
    > NSString *myString;
    > myString = @"Hi";
    > myString = @"Hi there";
    >
    > I'm clearly expecting some type of warning from the compiler when myString is redefined, but I don't see one in Xcode 4.6.1.  Is this redefinition not a mutable action?  It sure seems like it is.

    myString is a pointer to an NSString (or subclass thereof). It's not const, it's not static so the pointer can point to any NSString (or subclass thereof) and be reassigned at will. There is a huge difference between an NSString, which cannot be mutated and a pointer to an NSString which can.

    This is pretty basic.
  • On May 28, 2013, at 9:50 AM, Roland King wrote:

    >
    > On 28 May, 2013, at 9:39 PM, Alex Zavatone <zav...> wrote:
    >
    >> Though it's clearly defined in the docs when to use NSMubleAnything vs. NSAnything (insert Array, Dictionary, String, etc for Anything), there is no compiler warning when you perform a simple action such as allocate a string and then reassign values to it.
    >>
    >> With this in mind, what exactly constitutes a mutable action?
    >>
    >> If we take this:
    >>
    >> NSString *myString;
    >> myString = @"Hi";
    >> myString = @"Hi there";
    >>
    >> I'm clearly expecting some type of warning from the compiler when myString is redefined, but I don't see one in Xcode 4.6.1.  Is this redefinition not a mutable action?  It sure seems like it is.
    >
    >
    > myString is a pointer to an NSString (or subclass thereof). It's not const, it's not static so the pointer can point to any NSString (or subclass thereof) and be reassigned at will. There is a huge difference between an NSString, which cannot be mutated and a pointer to an NSString which can.
    >
    > This is pretty basic.

    Yes, it's pretty basic, and this is why I am asking.  To make sure I've got it 100% right.

    Though you stated that myString is a pointer to "an NSString" I'm expecting that myString is a pointer not to NSString, but an instance of NSString.  Which is correct?

    I'm having to explain mutabie vs nonmutable to web devs and am providing concrete examples of what constitutes legit/non legit actions, so wanted to make sure that I have everything properly understood in my head and am interpreting the compiler feedback correctly.

    Thanks much.
  • On May 28, 2013, at 9:46 AM, Steve Mills wrote:

    > On May 28, 2013, at 08:39:21, Alex Zavatone <zav...> wrote:
    >
    >> Though it's clearly defined in the docs when to use NSMubleAnything vs. NSAnything (insert Array, Dictionary, String, etc for Anything), there is no compiler warning when you perform a simple action such as allocate a string and then reassign values to it.
    >>
    >> With this in mind, what exactly constitutes a mutable action?
    >>
    >> If we take this:
    >>
    >> NSString *myString;
    >> myString = @"Hi";
    >> myString = @"Hi there";
    >>
    >> I'm clearly expecting some type of warning from the compiler when myString is redefined, but I don't see one in Xcode 4.6.1.  Is this redefinition not a mutable action?  It sure seems like it is.
    >
    > The example you've given is not changing the string, it's simply pointing the string pointer to a new string (changing the address it points to). This would require a mutable string:
    >
    > [myString appendString:@"Hi there"];
    >
    > because it's changing the string, but it will leave myString at the same pointer address.

    Excellent.  This is part of the information that I'm looking for.
  • Alex,

    What your three lines of code do:

    > NSString *myString;

    Compiler allocates space for a pointer on the run time stack.

    > myString = @"Hi";

    Compiler creates an NSString object somewhere in the heap with the value @"Hi" and points the pointer to it.

    > myString = @"Hi there";

    Compiler creates another NSString object somewhere else in the heap with the value @"Hi there" and points the pointer to it. Depending on the type of memory management you are using the first string might leak since there is nothing pointing to it any more. If you are using ARC the compiler will insert a call to release to remove the first string.

    There is nothing in your code that tries to mutate a string. All it does is create two different strings.

    Tom Wetmore
  • Alex,

    Forget what I said about memory management. It is wrong.

    Your confusion probably stems from the fact that the pointer named myString is allowed to point to any number of string during the execution of your program. It is the objects that are immutable, not the pointers to them.

    Tom Wetmore

    On May 28, 2013, at 12:11 PM, Thomas Wetmore <ttw4...> wrote:

    > Alex,
    >
    > What your three lines of code do:
    >
    >> NSString *myString;
    >
    > Compiler allocates space for a pointer on the run time stack.
    >
    >> myString = @"Hi";
    >
    > Compiler creates an NSString object somewhere in the heap with the value @"Hi" and points the pointer to it.
    >
    >> myString = @"Hi there";
    >
    > Compiler creates another NSString object somewhere else in the heap with the value @"Hi there" and points the pointer to it. Depending on the type of memory management you are using the first string might leak since there is nothing pointing to it any more. If you are using ARC the compiler will insert a call to release to remove the first string.
    >
    > There is nothing in your code that tries to mutate a string. All it does is create two different strings.
    >
    > Tom Wetmore
  • On May 28, 2013, at 7:44 AM, Alex Zavatone wrote:

    >
    > On May 28, 2013, at 9:46 AM, Steve Mills wrote:
    >
    >> On May 28, 2013, at 08:39:21, Alex Zavatone <zav...> wrote:
    >>
    >>> Though it's clearly defined in the docs when to use NSMubleAnything vs. NSAnything (insert Array, Dictionary, String, etc for Anything), there is no compiler warning when you perform a simple action such as allocate a string and then reassign values to it.
    >>>
    >>> With this in mind, what exactly constitutes a mutable action?
    >>>
    >>> If we take this:
    >>>
    >>> NSString *myString;
    >>> myString = @"Hi";
    >>> myString = @"Hi there";
    >>>
    >>> I'm clearly expecting some type of warning from the compiler when myString is redefined, but I don't see one in Xcode 4.6.1.  Is this redefinition not a mutable action?  It sure seems like it is.
    >>
    >> The example you've given is not changing the string, it's simply pointing the string pointer to a new string (changing the address it points to). This would require a mutable string:
    >>
    >> [myString appendString:@"Hi there"];
    >>
    >> because it's changing the string, but it will leave myString at the same pointer address.
    >
    > Excellent.  This is part of the information that I'm looking for.

    To toss in another complication: the object assigned to an NSString or NSMutableString variable might not be an object of that type - unlike C++, ObjC doesn't care (it might not even be an NSString at all, but in that case something odd probably happened).

    Hence the warnings not to inspect the result of a method returning NSString - it might happen to be an NSMutableString but you should not try to mutate it. And if you somehow get an NSString object in an NSMutableString variable, the compiler will be happy but mutable methods will fail at runtime.
  • On May 28, 2013, at 6:39 AM, Alex Zavatone <zav...> wrote:

    > NSString *myString;

    You’ve declared myString as a _mutable_ pointer to an _immutable_ object. If you had declared it as

    NSString* const myString = @“Hi";

    then the variable itself would be immutable, and the compiler would give you an error if you tried to reassign it. (You often see this style used when declaring a string constant in a header file, since it’s supposed to stay constant and no one should reassign it.)

    Working with C++ will beat this concept into your head (for better or worse).

    —Jens
  • May I add two questions to this enlightening thread?

    1. With ARC, do we still have to worry about string1 leaking in the following scenario?

    @property (nonatomic, copy) NSString *string1;
    …..
    self.string1 = @"Hello";
    string1 = @"Hello hello";
    string1 = @"Hello hello hello";

    2. How do the strong, copy and weak keywords in the property declaration affect this?

    Thanks!

    Diederik

    Op May 28, 2013, om 10:16 PM heeft Jens Alfke <jens...> het volgende geschreven:

    >
    > On May 28, 2013, at 6:39 AM, Alex Zavatone <zav...> wrote:
    >
    >> NSString *myString;
    >
    > You’ve declared myString as a _mutable_ pointer to an _immutable_ object. If you had declared it as
    >
    > NSString* const myString = @“Hi";
    >
    > then the variable itself would be immutable, and the compiler would give you an error if you tried to reassign it. (You often see this style used when declaring a string constant in a header file, since it’s supposed to stay constant and no one should reassign it.)
    >
    > Working with C++ will beat this concept into your head (for better or worse).
    >
    > —Jens
  • On Wednesday, 29. May 2013 at 8:37, Diederik Meijer | Ten Horses wrote:

    > May I add two questions to this enlightening thread?
    >
    > 1. With ARC, do we still have to worry about string1 leaking in the following scenario?
    >
    > @property (nonatomic, copy) NSString *string1;
    > …..

    No, ARC perfectly manages this - no leaks in this case.

    self.string1 = @"Hello";
    self.string1 = @"Hello hello";          <- @"Hello" deallocated unless it's strongly referenced elsewhere
    self.string1 = @"Hello hello hello";  <- @"Hello hello" deallocated unless it's strongly referenced elsewhere

    > 2. How do the strong, copy and weak keywords in the property declaration affect this?
    >
    >

    Here's nice tutorial from Ray http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1 You can learn something here.

    Real life example …

    strong - you're walking your dog on the lead, someone call your dog and he can't run
    copy - like strong, but your dog is cloned and you're walking your new clone on the lead
    weak - you're walking your dog off the lead, someone call your dog, he can run and you're without your dog

    … if your property is weak and you do assign @"Hello" object to it, the object disappears and your property will be nil. That's because there's no strong reference to your @"Hello" object.

    ;-)
  • On May 28, 2013, at 23:37 , Diederik Meijer | Ten Horses <diederik...> wrote:

    > 1. With ARC, do we still have to worry about string1 leaking in the following scenario?
    >
    > @property (nonatomic, copy) NSString *string1;
    > …..
    > self.string1 = @"Hello";
    > string1 = @"Hello hello";
    > string1 = @"Hello hello hello";

    No, you don't have to worry. When dealing with objects, ARC handles all retain/release correctly, regardless of whether the assignment is to the property or the ivar. That's kinda the point.

    > 2. How do the strong, copy and weak keywords in the property declaration affect this?

    ARC still does the right thing, whether you use the ivar or the setter.

    The "ownership" keyword is multi-purpose (unfortunately, IMO):

    1. It defines the ownership attribute of a synthesized ivar (or must match the ownership attribute of a manually declared ivar). For this, copy is the same as strong.

    2. It defines the behavior of a synthesized setter. For this, copy makes a copy, everything else just does an assignment (with the appropriate memory management according to the ivar ownership attribute).

    3. It declares the ownership attribute of the property itself, separately from the ivar. For this, strong and copy represent a strong property; weak represents a weak property; __unsafe_unretained represents no ownership. However, the property's ownership attribute has no actual effect on the compiler. Everything the compiler does via synthesis is covered under #1 and #2.

    Note that #1 and #2 are in truth private implementation details of the class. #3 is the public API contract, and communicates to clients of the class whether the property takes ownership of the property value.
  • Thanks Robert and Quincey, that's very helpful!

    Op May 29, 2013, om 8:26 AM heeft Quincey Morris <quinceymorris...> het volgende geschreven:

    > On May 28, 2013, at 23:37 , Diederik Meijer | Ten Horses <diederik...> wrote:
    >
    >> 1. With ARC, do we still have to worry about string1 leaking in the following scenario?
    >>
    >> @property (nonatomic, copy) NSString *string1;
    >> …..
    >> self.string1 = @"Hello";
    >> string1 = @"Hello hello";
    >> string1 = @"Hello hello hello";
    >
    > No, you don't have to worry. When dealing with objects, ARC handles all retain/release correctly, regardless of whether the assignment is to the property or the ivar. That's kinda the point.
    >
    >> 2. How do the strong, copy and weak keywords in the property declaration affect this?
    >
    > ARC still does the right thing, whether you use the ivar or the setter.
    >
    > The "ownership" keyword is multi-purpose (unfortunately, IMO):
    >
    > 1. It defines the ownership attribute of a synthesized ivar (or must match the ownership attribute of a manually declared ivar). For this, copy is the same as strong.
    >
    > 2. It defines the behavior of a synthesized setter. For this, copy makes a copy, everything else just does an assignment (with the appropriate memory management according to the ivar ownership attribute).
    >
    > 3. It declares the ownership attribute of the property itself, separately from the ivar. For this, strong and copy represent a strong property; weak represents a weak property; __unsafe_unretained represents no ownership. However, the property's ownership attribute has no actual effect on the compiler. Everything the compiler does via synthesis is covered under #1 and #2.
    >
    > Note that #1 and #2 are in truth private implementation details of the class. #3 is the public API contract, and communicates to clients of the class whether the property takes ownership of the property value.
    >
  • Hello dear members!

    Could you pls help me. I browsed a lot but could not find real answer

    I'm implementing Voice over IP application. I'm getting output from mic on one iPhone and I would like to send that data in real time to another device (or may be some other device in group chat).

    I'm thinking about direct iphone to iphone communication (in different networks) for data transfer. May be by means of client-server architecture.

    How could I do that?

    Is there any way that allows me data transfer between two or more devices by means of internet? I could use web server as a middle node to help device to establish communication.

    PS
      At extra case I could use web server and store data in SQL database but it is less preferable case b/c of performance issue during live audio transfer/streaming

    Thank you a lot!
    Rufat
  • On May 29, 2013, at 1:06 AM, Rufat A. Abdullayev <rufataa...> wrote:

    > Could you pls help me. I browsed a lot but could not find real answer

    What types of search keywords did you use?

    > I'm implementing Voice over IP application. I'm getting output from mic on one iPhone and I would like to send that data in real time to another device (or may be some other device in group chat).

    This is a big topic. There are many protocols and frameworks, and many books written about it. You’re not going to get any simple answer.

    Issues include:
    * Discovery of the other device’s IP address (Bonjour works locally; at wider range you need some kind of server)
    * Making a direct P2P connection to a device behind a NAT or firewall
    * Using UDP for streaming (TCP is usually inappropriate, because packet loss is OK but latency isn’t)
    * Voice-oriented data compression algorithms
    * Real-time low-latency audio recording and playback
    * Echo cancellation (this is a must unless both sides are using headphones)

    Google’s libJingle might be a good place to start <https://developers.google.com/talk/libjingle/>

    —Jens
previous month may 2013 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today