It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
With last version of iOS Apple has implemented Automatic Reference Counting for Objective-C, but I don't understand as works.
Automatic reference counting inserts retain and release messages into your code for you at compile-time, following the normal conventions. So it's exactly as if you did the memory management yourself manually, except that the compiler is smart enough to be able to write that bit for you, and much less likely to make a mistake.
So it's not garbage collection, it's more like a (very simple) form of static analysis. And you still get overwhelmingly deterministic memory management and little overall change in runtime costs, as per the caveats raised by Catfish_Man below.
Automatic Reference Counting implements automatic memory management for Objective-C objects and blocks, freeing the programmer from the need explicitly insert retains and releases. It does not provide a cycle collector; users must explicitly manage lifetime instead.
Read this spec - Automatic Reference Counting
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I have this project that has functions to load different chapters of a book. (Ex. loadChapter1)
My thinking was that I will call the functions to load up every chapter when the app launches. But by the time I am done with the program, there would be a huge amount of chapters. It's only loading up lots of NSStrings.
Would that make the program slow to initialize or even crash the program?
My functions are declared in AppDelegate.h using ( -(void)loadChapter1 ). The way I call it in AppDelegate.m is using [self loadChapter1].
If this is not a good way, this there any other way to do this?
You're better off trying something, seeing if it works well, then making changes (and possibly asking questions here) if it doesn't rather than asking a question like this at the outset. For performance questions in particular, the accepted wisdom is that you shouldn't worry too much about performance (memory and CPU usage) while initially writing a program, but rather should do performance optimizations as needed after you've got the program working.
That said, my first approach to this would be to load each chapter as it's requested. So, don't load all the chapters in the book every time the app launches. Rather, load a chapter when the user turns the page to that chapter or selects it in the table of contents (or whatever applies to your app). That way, you don't waste time and memory loading chapters that before they're actually going to be used.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I recently was asked this question in an interview and would like to hear the answer from you people.
I discussed about code resuability and security that can be achieved by encapsulation and inheritance but the interviewer did not seem satisfied.
He insisted on how exactly an application user is benefited by using applications developed on the principles of oop.
Depends. Purists (and morons) will apply abstraction to every possible bit of code they generate or come across. This is completely unnecessary in something as simple as a direct, simple MySQL call from within a tiny bit of PHP, to log site accesses, for instance.
However, generally OOP can save you plenty of cycles if applied systematically to big data involving lots of information shuffling, like sorting hundreds of rows of data on every page access. It's a matter of when to use OOP and when to just write procedural code. OOP takes time and effort and is maintainable by experienced programmers, but you need to ask yourself if it is worth all that extra hassle on a tiny snippet of code that does one thing internally.
There are plenty of good articles out there (http://berryllium.nl/2011/02/getters-and-setters-evil-or-necessary-evil/) that help you to understand WHY OOP is sometimes unnecessary and in fact harmful.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Namaste! How often do you, experienced guys using generic pointers in daily routine and what's the common purpose for generic pointers in cocoa-touch development?
EDIT
A variable declared as a pointer to void is a generic pointer.
There's such thing. It may be set to an address of any variable type. I just want to know how the people use this kind of pointers in real life coding.
P.S Thank you for down voting.
There are fewer and fewer cases where void* is appropriate in ObjC. They're still used for some things like context pointers for KVO, but with the addition of ARC they're a pain to use even for that. Basically, if you need to ask when you would use a void*, you probably shouldn't use a void*. They're a little more common in the callbacks of Core frameworks, again usually for context pointers.
But to the question, "How often do you... [use void*] ... in daily routine," the answer is "very seldom, and as little as possible."
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I would like to know, why is so important to write interface and implementation for every calss in Objective C. In other langauge this technique is only optional.
In Objective-C, writing an interface is also optional (so is declaring methods), although the compiler will likely warn you. Writing the interface permits somebody else to reuse the binary form of your code without having to recompile it; this way you can also hide the implementation details/the code from the one who reuses your class. Also, if only you use your own class, the compiler may need some information at compile time (although Objective-C is a dynamic language) about the classes you write -- in this case you can't include the whole implementation file as it would result in duplicating your entire class, redulting in a linker error. Same reason why there are header files for any C library out there.
Interface describes how other classes and their instances will interact with your class and its instances. You could just create implementation, but that would kind of defeat the purpose of OOP.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
Hi there: I was looking at a few videos, etc and I just cant help but wonder why Pex usage seems to be so low?
Are there any problems that are not obvious, or is it just a licence issue?
It's a very new tool and to work really well you need to use Code Contracts as well. It also catches a lot of issues like possible integer overflows that a lot of developers think they can just ignore. Pex is amazing and will take off eventually but it has a learning curve so it's going to take some time to percolate through the .Net ecosystem.
I've used it on a few new development projects and it has saved me two major bugs (not caught by normal unit tests) that would have taken at least a week to track down and fix normally plus a few smaller issues so I'm a big proponent of Pex. That said it takes a lot of work to get it producing good results on an existing code base of any size so how cost effective it is will need to be determined on a project by project basis.