I'm asking this because I'm relatively new to interpreter development and I wanted to know some basic concepts before reinventing the wheel.
I thought of the values of all variables stored in an array which makes the current scope, upon entering a function the array is swapped and the original array put on some sort of stack. When leaving the function the top element of the "scope stack" is popped of and used again.
Is this basically right?
Isn't swapping arrays (which means moving around a lot of data) not very slow and therefore not used by modern interpreters?
Why swap the array? Just look at the top array on your stack. Furthermore, in most languages you don’t have to copy the array when you want to swap it, you can just swap references or pointers.
This is also what an interpreter might do. An alternative is having a special data structure for the current scope which holds a reference to its parent frame explicitly.
Python uses the C stack to keep track of its scope. Everytime a new scope is entered a new function call is made so that the scope's data is always held in the local variables on the stack.
For some other interpreters, everything is kept on the stack something like your suggestion. However, the interpreter acts on the top of the stack in-place. There is no need to copy things back and forth since there is only one copy.
Related
For a while now I have been a little confused about the role of constant members within a language, such as Java or C. I understand that at the source code level, they prevent certain critical members from being mutated and changed, but when compiled or interpreted, is there any difference between them and variable members at all or are they all just pointers to memory addresses?
I thought that perhaps the compiler/interpreter has to implement something special to allow a variable to be mutable, something it wouldn't have to when handling a constant member (perhaps making execution faster or making it use less memory?), is this true or am I completely up the wrong tree?
The const variable and the variable are not stored in the same place once your code is executed. The constant values will go in the flash memory with your program. The variables will go in the flash too but will then be copied in the ram to be modified as your program runs. Making a variable const makes your computer save time and space by not pushing everything in the ram. When you need to modify it, you will push it into the Ram anyway, but most of the time const variables will not be modified.
This is in addition to the software fact that you might want to prevent your code to modify a value by mistake.
I have a situation where I must generate a sequence of objects, and pass them back to an application one at a time (think block-based, or fast enumeration).
However, each object is going to be relatively expensive to generate, so I am looking for ways to avoid this cost.
It happens to be the case, that given one object of the sequence, the next one can be efficiently generated by a simple modification of the former. For this reason, it is tempting to "cheat" by only ever creating one object, and then keep passing that same object back to the application, and only carrying out the "cheap" modification "behind the scene" at each step in the sequence.
The problem is, of course, that the application may choose to (and it should be allowed to) store a reference to some, or all of the objects somewhere else. If it does that, the "illusion" of a true sequence of unique objects breaks down.
If Objective-C allows it, a neat way of solving this problem would be to detect when the application actually does store references elsewhere, and whenever that happens, replace the object by a copy of itself, before applying the modification that produce the next element in the sequence.
I don't know what the official name of this idiom is, but we could call it "copy on write if leaked", "copy on write if shared", or simply "copy on write".
My question is then: Does Objective-C, with ARC enabled, allow for such an idiom to be implemented?
And, is it even the right way to solve this kind of problem in Objective-C?
I did notice that with ARC enabled, there is no way I can extract the reference count from an object, nor override the methods that increment and decrement it.
EDIT: I have noticed that there is a copy attribute that can be applied to properties, but I have a hard time figuring it out. Are any of you guys able to explain how it works?
http://clang.llvm.org/docs/AutomaticReferenceCounting.html#property-declarations
This question already has answers here:
Am I correctly creating and passing this C array to Objective-C method and referencing it with a property?
(3 answers)
Closed 9 years ago.
Example:
unsigned char colorComps[] = {2, 3, 22, 55, 9, 1};
Passing this to an Objective-C method which references it with a property. It needs to be copied to heap memory first. But is it fine to let the method do this step or must I copy it to heap before passing it to the method, for safety?
In pretty much every C API I've used, the convention is that the called function is responsible for copying data if needed.
This makes sense, as the called function knows how long the data will be needed, whereas the caller doesn't. Since we generally use C for performance reasons, this also avoids unnecessary memory allocation and copying.
On that note, unless you've got performance reasons for using a C array, just use an NSArray of NSNumbers. Much simpler.
The exact same rules as with pass an array to a C function apply. There is no special handling in Objective-C regarding C arrays. Except that you can't declare a property with a C array type. For workarounds see this question and this question. In this case, your object (which wants to expose the array) should allocate the memory, copy the array and release it when appropriate. It's a bad idea to allocate it "outside" but then release it "inside".
Unless you really need a C array (for example, because you've got a third party library that wants it as argument and you'd need to construct it all the time) you should stick with Objective-C objects (NSNumbers in NSArrays). Especially since the syntax is now pretty straight forward:
NSArray *myArray = #[ #(1), #(42), #(543) ];
Using C arrays just "because they're faster" would be pre-mature optimization unless you have actually measured that an NSArray/NSNumber solution is a bottleneck for you. I'm doing multimedia processing on iOS and I've never had to switch from an NSArray to a C array for performance reasons.
I believe you're asking about my comment on your previous question, so let me explain.
If you simply take whatever array you receive and keep it as-is, you have no control over it; you're leaving the integrity of your code entirely to the calling function. You may accidentally forget to pass in a copy, or you pass in a string literal*, and then you have a potentially difficult-to-find bug. By using a property and setting the ivar to an array that you created, you are in control of it. You know precisely its desired lifetime, and you know it's safe (indeed, required) to free it in dealloc.
Note that this is the reason why block properties should always be declared copy. If you just keep the block around as you received it, it will be invalid and lead to problems later on unless it was already copied to the heap at some point. But you don't normally copy a block when you are passing it to a function, the function you call is responsible for making sure it's safe to keep around.
*: Yes, unlikely the way you're using it, but under different circumstances it could be a concern.
I have just started using Objective C and although I am doing okay with the pace and learning curve (I have no C background) - I don't understand one concept which is also part of C++ - Pointers!
OK - I understand that pointers point to the physical location of the actual variable rather then the value for the variable itself. When on earth can that come in handy?
Also, when to use them and when not to?
I have Googled enough but every guide I come across seems to assume that I am a PhD in rocket science.
Can someone please explain this with a simple example?
Although they are C pointers of course, I strongly suggest to understand them als references to objects.
You either create an object or receive it from somewhere and store a reference to the object in a varialbe.
When you hand the reference to the object to some function or method then this method can access the very object that you handed over. It does not nesessarily have to work with a copy of the data. If it makes changes to the ojects' properties (as far as allowed by means of the poperty declaration and stuff) then the very object is changed that your reference is referring to.
You can of course copy it and continue working with that copy when ever you think it is suitable. In that case the original object remains unchanged.
When you really come into a situation where you have to work with c-style pointers then you better step back and understand C. I donnot think it is wise understanding c-style pointers while coming from an Objecive-C background. Clear your mind and learn C from scratch and after that make use of the new know how in that very very rare situations where you have to deal with these basic data types in Objective-C projects.
One of the main reasons that pointers are used is to save memory. For example if you are passing an array to a function, it would be better to send the address in memory to the function rather than sending the values.
If you go on to do c or other lower level languages, then you will see that arrays and pointers are almost interchangeable. (C-style arrays, not NSMutableArrays in objc or vectors in c++ or lists in c# etc)
Here is a simple reason:
Imagine you have a really big object. - When you pass it to a function do you really want to copy & duplicate the entire object? - This would take a lot of CPU and memory.
By using pointers you do not have to copy the original object every time you pass it around. (Ofcourse the flipside is that if you change the object in the function it will change the original object as well).
May be my question is stupid. But i would like to get it cleared. We know that functions are loaded in memory only once and when you create new objects, only instance variables gets created, functions are never created. My question is, say suppose there is server and all clients access a method named createCustomer(). Say suppose all clients do something which fired createCustomer on server. So, if the method is in middle of execution and new client fires it. Will the new request be put on wait? or new request also will start executing the method? How does it all get managed when there is only one copy of function in memory? No book mentions answers to this type of questions. So i am posting here where i am bound to get answers :).
Functions are code which is then executed in a memory context. The code can be run many times in parallel (literally in parallel on a multi-processor machine), but each of those calls will execute in a different memory context (from the point of view of local variables and such). At a low level this works because the functions will reference local variables as offsets into memory on something called a "stack" which is pointed to by a processor register called the "stack pointer" (or in some interpreted languages, an analog of that register at a higher level), and the value of this register will be different for different calls to the function. So the x local variable in one call to function foo is in a different location in memory than the x local variable in another call to foo, regardless of whether those calls happen simultaneously.
Instance variables are different, they're referenced via a reference (pointer) to the memory allocated to the instance of an object. Two running copies of the same function might access the same instance variable at exactly the same time; similarly, two different functions might do so. This is why we get into "threading" or concurrency issues, synchronization, locks, race conditions, etc. But it's also one reason things can be highly efficient.
It's called "multi-threading". If each request has its own thread, and the object contains mutable data, each client will have the opportunity to modify the state of the object as they see fit. If the person who wrote the object isn't mindful of thread safety you could end up with an object that's in an inconsistent state between requests.
This is a basic threading issue, you can look it up at http://en.wikipedia.org/wiki/Thread_(computer_science).
Instead of thinking in terms of code that is executed, try to think of memory context of a thread that is changed. It does not matter where and what the actual code happens to be, and if it is the same code or a duplicate or something else.
Basically, it can happen that the function is called while it was already called earlier. The two calls are independent and may even happen to run in parallel (on a multicore machine). The way to achieve this independence is by using different stacks and virtual address spaces for each thread.
There are ways to synchronize calls, so additional callers have to wait until the first call finishes. This is also explained in the above link.