Amazon.com Widgets Recent Posts
Welcome, Guest. Please login or register.
Did you miss your activation email?
September 22, 2014, 07:15:21 PM
Home Help Search chat Login Register   
News: Read this please.The Great Kangaroo Escape Looking for reviews of the 4th ed on Amazon!   Twitter:  @skochan
                     

+  Official Forum for Programming in Objective-C (the iPhone Programming Language) - Stephen Kochan
|-+  Recent Posts
Pages: 1 2 [3] 4 5 ... 10

 21 
 on: September 15, 2014, 02:43:41 PM 
Started by jonr - Last post by jonr
Brian,
Thanks again for the feedback.

2) I like this approach; how you change  your syntax depending on the context.  It's interesting to note that when passing a pointer to a function you have the asterisk hugging the data type and not the name.  I think this underscores the fact that deep down inside you agree with me about the official term for describing data types  Tongue.  I will have to say that I was exposed to that way of thinking about data types (in how to describe them) by a co-worker who is an experienced C, C++ and C# developer.  Also, I see that you have side-stepped  Tongue responding to my specific reasoning that I stated earlier: 
i
Code: (Objective-C)
int var1;   // the variable 'var1' is of type int. My reasoning is: If this is true, then the following has to be true.
int *var2;  // The variable 'var2' is of type int*
  Also, something else underscores this approach for me--compiler messages.  I'm referring to situations where the compiler is expecting a pointer but you screw up and make a mistake and the compiler gives you a message.  The message usually says something like, 'expected type int* ; int given..blah blah blah..'  So, that's all i've been saying here, I'm just bringing up the technical code description of the data type and intentionally avoiding any spoken language influence.  I don't think what I'm saying is at odds with your description or vice versa. Would you agree with that? 
2a)
One last thing about function/method/pointer syntax:  What do you do when you have a function that returns a pointer?  If there was ever a time for the asterisk to be next to the data type that would be it IMHO, but typically people don't do it that way.  So, you always will see 
Code: (Objective-C)
int *function(char arg);
  I find that it looks odd to have the asterisk right next to the function name and decoupled from the data type name..it's odd and harder to read IMHO.  Based on what you have told me your approach is for functions that take pointer args, I would be that you would agree with me here and you put the asterisk next to the return type name?  Btw, in your example of 'the function'...isn't that incorrect syntax?   Tongue  Wouldn't the compiler choke on seeing 'the' there instead of a valid return type?  Also, would you agree that with Objective-C since it calls for parentheses around both the return type and arg type that it sort of takes away the need to care about where the asterisk is visually?  Something like XYPoint * would always be blanketed by a pair of parentheses.

3. Ok, what you are saying makes sense, but let me pose the question a different way.  How then would you reconcile what you are saying here with what Stephen is saying in the book.  You are saying here that:
Quote
This allocates the memory needed to store an object of that type. Its memory address is returned, but not to the calling code yet so it does not get stored into the origin variable at this point,
  In the book, Stephen writes (what I quoted just earlier):
Quote
When you send the alloc message to a class, you get back a new instance of that class.  In Program 3.2, the returned value is stored inside your variable myFraction.
The only way I can think of reconciling what you both are saying here is to understand that a) Stephen was describing alloc all by itself, in a separate description apart from init and/or b) His description may not be 'timeline sensitive' as your is; in other words, the quote from the book I just cited was saying where the returned value *eventually* goes and perhaps he wasn't describing it in sequence as you have been (I think) doing.  Also, sorry if I have asked this before, would the nesting of the calls have anything to do with the sequencing of all this?  Let's say you didn't follow best practices (as Mitch was discussing), and you just did an alloc.  To the best of your knowledge would doing it this way (unadvised, I know) cause the memory to be stored in the variable at THIS POINT IN TIME?  Btw, I'm familiar with 'Option' key method and have been reading some of Apple's description of this but I find I get lost sometimes with it.  I should try it again; thanks for mentioning int.

4) Brian, thanks again for the help and the encouraging words.  I have a tendency to perhaps be too detailed oriented and I would think people feel that I'm doing something like beat(deadhorse).  But I've found that in almost all skills that I've learned that knowing the details/'nuts and bolts' helps you gain true knowledge which you can use intelligently over time with an upside that could get enormous.  By not fully understanding the base concepts fully you end up just operating as if you are using rote memorization and the knowledge is too static, which I think makes it difficult to think abstractly enough to learn programming effectively.  I've found this applies to a lot of things...music, construction/design, learning a spoken language.  It probably applies to all learning; I only have direct experience in the things that I've learned over the years.  I spent 9.5 years working as a Quality Engineer (black box tester) at a major software company so I'm used to asking questions and poking around 'under the hood'.  If someone tells me not to do something, I do it.  If they tell me to stay within the limits, I go outside...I do all these things just to cause breakage and failure.  From that you can learn how things work.  I wouldn't suggest if if you are in medicine and working on people's bodies   Tongue, but with software testing you need to do that.

Cheers,
jonR

 22 
 on: September 14, 2014, 08:44:35 PM 
Started by jonr - Last post by BrianLawson
2) No, I would say that it is a pointer to an XYPoint object. That removes the computer language syntax from the English language description. In practice how I write my code depends upon the emphasis I want to make. When declaring a pointer I use the XYPoint *origin; form, but when passing pointer arguments to functions I tend to use the function(XYPoint* origin) form. Smiley

3) They are the same in this case because init returned the same object alloc created. To (hopefully) better explain the order of things, first the alloc method is called for the XYPoint class. This allocates the memory needed to store an object of that type. Its memory address is returned, but not to the calling code yet so it does not get stored into the origin variable at this point, instead it is passed directly to the init method. init does its thing and returns the address of the memory that was initialized. That memory may or may not be the same memory as was originally allocated. Whatever the case, the address returned by init is passed to the original caller and that address gets stored into the origin variable.

You might find it helpful to read the documentation on the init and alloc methods. Press the Option key and point to one of the method names. The pointer will turn into a question mark. Click on the method name and a window will pop up with the documentation for that method. At the bottom of the window is a link to the full documentation page within the Help system.

4) Yes, I would say that you are on track. You have been asking some good insightful questions and I'm glad I am able to help you with your understanding. Hopefully, other readers of this forum will find this discussion helpful as well.

 23 
 on: September 14, 2014, 07:49:23 PM 
Started by jonr - Last post by jonr
Thanks, Brian!

2. Yes I realize that all those ways are valid; there is leniency with whitespace.  My point though was what the proper name or data type of XYPoint *myPoint is strictly speaking when communicating that with code and not using human language.  My assertion is that the data type is XYPoint* .  This is following the following convention:  for int var; var's data type is int.  For int *var; var's data type is int*.  So, when looking at it this way, myPoint's data type should be XYPoint*.  Do you agree with this?

3. Ok, I recall what Mitch said, but it was more of a warning about something that may or may not happen.  If the return of the address does not occur until after both alloc and init are called, how do you explain the fact that the memory address that is inside the pointer (revealed by %p) is always the same after alloc and after init.  You see, you did explain to me what init does that alloc doesn't do; I get that--it inits the data at the memory address the pointer 'points to'.  Is this a matter of you using the term 'return of the address' properly while I am doing it incorrectly?  In other words, when I say that %p shows the memory address stashed inside the pointer after alloc is applied, and I see that same memory address is there after init is applied (remember, in my tests I was not nesting them) does that merely means that the memory is *known* and not necessarily returned?  Is that where I'm going wrong?  But please consider what Stephen states in the book:
Quote
When you send the alloc message to a class, you get back a new instance of that class.  In Program 3.2, the returned value is stored inside your variable myFraction.
Hmmm, I can't reconcile this statement with your point that this doesn't get done until after init is called. He then explicitly talks about what init does:
Quote
The init method returns a value--namely the initialized object. You store the return value in your Fraction variable myFraction.
So, you can see that both of these calls return something.  The call to init returns the initialized object, which you've explained to me as the 'stuff' that is at the address that the pointer is pointing to.  And as Stephen states in the first quote above, alloc returns something as well, a returned value, which I take to be the memory address.  I would think that this is the memory address, inside the pointer-->the memory address that has the data that init initializes.  Where am I still off track?   Tongue  I'm trying to follow your explanation and the book's explanations closely and can't get them to mesh 100%.

4. Thanks, Brian for this verification.  Btw, because of your help I think I fully appreciate the difference between copying a pointer and copying an object and what can happen / will happen / won't happen when you go either route.  I find this slightly humorous with regards to the differences between 8.5's & 8.5B's approaches to setting the origin WHEN compared to the struggles I went through with finally starting to understand the power of pointers during my C studies.  I'm referring to understanding what pointers can do when for example you have a function that returns a pointer.  The rudimentary studies showed us how if you pass a reference from a function (rather than a value) you can change a value of a variable that is located outside the function in question.  I'm just describing a quick and dirty use case here.  But now returning back to my Objective-C studies and 8.5 vs 8.5B setter methods, it seems that we are wanting to 'back off' using pointers because it will do stuff that we don't want to do.  In other words we didn't want the changing of the point object to change the origin of the rectangle; we wanted them to be distinct.  So, I find this a little bit ironic.  Btw, is my overview of this stuff--my experience with C pointers and this issue that 8.5  vs 8.5B highlighted relatively on track with regards to what is going on?
Cheers,
jonR

 24 
 on: September 14, 2014, 04:59:52 PM 
Started by jonr - Last post by BrianLawson
2) Yes, it is a syntax thing. origin is a pointer to an XYPoint class object. The syntax can be written in any of the following ways, the compiler interprets them all the same.Which way you choose to use is just a personal choice.
Code: (Objective-C)
XYPoint *origin;
XYPoint* origin;
XYPoint * origin;
XYPoint*origin;
3) No, the return of the address does not happen until after the nested method calls to alloc and init. Going back to that other thread discussion, Mitch made the point that the address might actually change between the alloc and the init. If alloc returned the address before calling init then init did change the memory space used for the object, the address would have to be returned a second time or it would be lost, a very inefficient way to do things.

4) The copying of an object happens by the creation of a new object of the same type followed by the copying of the contents of the original object into the contents of the new object. This is why you have to copy both pt.x and pt.y into the new XYPoint's x & y ivars so, yes, you are right copying an object means copying its values. The test at the beginning of the method if (! origin) prevents a new XYPoint object from being created with each call to the method.

 25 
 on: September 14, 2014, 04:18:27 PM 
Started by jonr - Last post by jonr
Brian,

Thanks again for this additional info; it's extremely helpful!
Just some follow-ups to some of what you stated:

2) This could be just a syntax nitpick but technically speaking isn't origin in this case really a type of XYPoint*? Obviously your way communicates it properly but I am focusing on how the type would be represented just using code and not English decriptions.  For instance take int *a.  This is an int pointer or a type pointer to an int, but technically wouldn't its type really be int*?  I know that the most common way of writing pointer declaration syntax is int *pnt; not int* pnt; although both are accepted. (Of course the first way (most common) makes doing multiple declarations on a single line easier).  In the first example the '*' is decoupled from the type and associated with the var-name, but the '*' really is part of the type name I would think.

3) Ok, thanks..for some perverse reason I find these details interesting.  Tongue  A follow-up question:  You said: 
Quote
...then it initializes that object and finally returns the address of that space to the origin pointer.
.  Doesn't the returning of the address to the pointer occur after *alloc* and not necessarily after *init*?  In other words it would be *in between* those two calls.  I don't know if you are describing it the way you did because of the nesting, or had the order incorrect, or the most likely situation:  I am wrong and you are right.  Tongue  Let me bring in mention a discussion of alloc and init from that other thread where you were helping me sort it out.  There, you reminded me that my test of using %p in NSLog to see differences between alloc and init should show the same value.  You pointed out that I was mixing up the contents of the pointer (memory address) with the contents of that memory that's being pointed to.   So, since %p was showing the same contents after both alloc and init, I take that to mean that the address is returned after alloc since it doesn't change after init--(it's known after alloc and stays the same after alloc); only the *contents* at that memory address changes when you call init.

5)  Thanks; I'm glad I understood both #4 and this one.  But for this one, what I was asking / wondering about was exactly how the newly written method in 8.5B that allocated it's own point object specifically illustrated copying an object.  I don't get where the copying comes into play.  I know that a new point object is created inside the method. Perhaps understanding where the copying is going on will help me.  Is it because when you create a fully allocated point object you are then in a position to be able to copy the values? And that's what drilling down and accessing 'x' and 'y' is all about?  So, if I'm correct on this, copying then really means copying values, so I'm still not sure where the term copying objects comes from.
thanks again,
jonR

 26 
 on: September 14, 2014, 02:33:37 PM 
Started by jonr - Last post by BrianLawson
No, I'm not an instructor or teacher. In fact, I'm currently in the last semester of my CS degree. However, I have been a programmer for over 30 years working on everything from an Apple II+ to the Space Shuttle Launch Processing System and the USAF intelligence database system. I also enjoy doing support and helping people learn.

1) I'd say yes, your situation is typical.

2) Yes, XYPoint *origin is just a variable declaration of type pointer to an XYPoint object.

3) The statement XYPoint *origin; reserves space for the pointer while the statement origin = [[XYPoint alloc] init]; first allocates space for the XYPoint object instance then it initializes that object and finally returns the address of that space to the origin pointer. The compiler reserves the space on the stack for the origin pointer variable. The space for the XYPoint object instance gets allocated from the heap at runtime by a call from the Objective-C runtime to the operating system. Think back to the C language malloc function. Objecitve-C's alloc method is the equivalent to malloc.

4) Yes, you've got it. Smiley

5) You've got this one too, it is an example of copying an object rather than the pointer.

 27 
 on: September 14, 2014, 01:57:15 PM 
Started by jonr - Last post by jonr
Brian,
Thanks again for this additional help; you explanation is really good as usual. Btw, are you a teacher/instructor?  You have a knack for breaking things down and explaining them clearly.  I'd like to make some comments and ask a few more questions and would be interested in your responses.

1. With regards to what you said about beginners with regards to pointers:  When I was studying C I found that I went back and forth with pointers.  Sometimes I thought I 'got it' but then I would regress.  But now I think I have a fairly decent theoretical understanding of them, and have worked out most of the issues with them.  My stumbling block now is using that theoretical knowledge and being able applying it to typical programming scenarios.  For some reason I couldn't do that to grok that XPoint *origin; is merely a variable declaration and nothing more.  So, in your experience, is the understanding of pointers something that a lot of people perhaps start understanding theoretically while still having problems with them in real-world settings?  Just wondering if my situation is typical.

2. Getting back to XPoint *origin;:  So, was I correct above in stating that this is merely a variable declaration just as int var; and int *ptvar;?  In this case it's a pointer of type XYPoint.  I guess technically its type would be XYPoint*, just as an int pointer's type is int*.

3. You stated that with the declaration of XYPoint *origin; that the compiler reserves the memory space for the variable.  This is consistent with what I learned working with C.  That's why it's necessary to list the type of the variable.  But how then do you compare or reconcile the reserving of space that happens as the result of a call to alloc with the compiler's reserving of space just for the declaration?  Is this perhaps an example of memory that's reserved from the stack and VS memory that's allocated from the heap?  I'm thinking back to that other thread I started awhile back about alloc and init and the other one where I asked why objects have to be represented by pointers.  Lastly: If the compiler is reserving the memory space based on the declaration, who or what exactly is doing that as the result of alloc.

4. In the book in chap. 8, pg. 168, after the issues illustrated by programs 8.5 and 8.5B, Stephen brought up an interesting point, that he states will be fully covered in a later chapter.  He states that the exercises 8.5x didn't call for synthesizing origin's methods because they would have behaved just like the one's we wrote for 8.5 which copied the pointer (something we didn't want to do).  I know then when learning about 'deep-copying' later on, etc. I will find out about this but I'd like to ask the following:  Can I assume then that this is a common issue when dealing with accessor methods for ivars that are objects?  Since they are not other types of data types such as ints or floats, I would think that accessor methods for ivars that are objects (pointers), due to the fact that there is indirection involved, the kind of copying will always be important.  A full explanation is not necessary as I'll get to this in a later chapter, but is my 'hunch' correct?

5.  Lastly, in the above mentioned section of the book where Stephen mentions the default behavior of the synthesized setter is to copy the pointer (I mentioned this above).  (I take it he is referring to origin = pt;) He then talks about a different type of synthesized setter that does make a copy of the object.  (We'll get to this later in the book so I don't need to know how to do this now). But from this I take it that in exercise 8.5B, when we rewrote the setter method so that it allocates it's own point object, that this was  an example of copying the object rather than the pointer; correct?  If so, I'm not sure how the term 'copying the object' fits in with what we actually did in that method where we allocated a new point object.

Sorry this we so long...

thanks,
jonR

 28 
 on: September 14, 2014, 05:17:56 AM 
Started by jonr - Last post by BrianLawson
origin is just a place in memory to store some kind of data, in this case it is used to store a pointer to a XYPoint object. It has been declared and the compiler has reserved the memory space for it by the statement
Code: (Objective-C)
XYPoint *origin;
but it has not yet been initialized with any value and so does not point to any object yet. Because it does exist as a variable, you can assign a value to it so the statement
Code: (Objective-C)
origin = pt;
is legal and it does work. origin and pt now both point to the same XYPoint object.

It isn't a trivial matter, pointers take some time to get used to and it is common for beginners to confuse or conflate the pointer with the object/memory it is pointing to.

 29 
 on: September 13, 2014, 10:29:49 PM 
Started by jonr - Last post by jonr
Brian,

Thanks for the additional reply; no need to apologize.  I actually got a lot out of your previous post even though it wasn't what I asked; it did serve as a good underscore of what was discussed in the book.

Your explanation here makes sense and it was sort of what I was thinking (I think one of my 'guesses' in my previous post was sort of close) but I wasn't 100% sure and couldn't really explain it.  Btw, your example of pointing out that
Code: (Objective-C)
origin.x = pt.x
is another way of saying
Code: (Objective-C)
origin setX: pt.x;
Is a really helpful point.  I think Stephen mentioned examples like this a few times in the book to put dot notation in proper perspective.

So, I understand this (I think) but the problem is the more I think of it and compare the two program examples (8.5 vs 8.5B) I get to mental dead ends. 

For instance, in this latest explanation, you state that the problem is that the origin object doesn't actually exist yet, and that it is not a valid pointer.  That's why you can't assign the x & y coords. Then if that is the case why can you even do:
Code: (Objective-C)
origin = pt;
at all?  If origin is not a valid pointer with regards to assigning the x & y coords. then how can it be a valid pointer with regards to being able to receive the data that's stored inside pt when doing the copying illustrated by
Code: (Objective-C)
origin = pt;

I guess this is the only missing piece of this puzzle for me at this point.  I'm sure it's a trivial matter but I can't really get it completely straight.
thanks,
jonR

 30 
 on: September 13, 2014, 08:25:26 PM 
Started by jonr - Last post by BrianLawson
Sorry Jon, I did misinterpret your question, my apologies. The reason you do not want to assign the x & y coords from the point object to the origin object without first ensuring that the origin object actually exists and you have a valid pointer to it is that without first initializing the origin pointer to something, who knows what that pointer contains and where it is pointing in memory. Therefore you have no way to know where origin.x will actually be stored, or if it even be stored. The value in origin may point to may point to some location outside your program's memory or it may point to somewhere within your own code. Either way, your program would crash. Or it may point to somewhere within your program's data memory which wouldn't crash the program but it would trash whatever data is already stored there causing a very difficult to find bug in your code. Remember that
Code: (Objective-C)
origin.x = pt.x
is just another way of saying
Code: (Objective-C)
origin setX: pt.x;
, origin must be set before you can use it.

Pages: 1 2 [3] 4 5 ... 10


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Entire forum contents (c) 2009 classroomM.com. All rights reserved.