Showing entries tagged "objectivec". Full blog index
Back in the mists of time, before Friday Q&A was a thing, I posted some articles running performance tests on common operations and discussing the results. The most recent one was from 2008, running on 10.5 and the original iPhone OS, and it's long past time to do an update.
are an interesting technology used to increase performance and reduce memory usage. As of OS X 10.10,
got the tagged pointer treatment, and today I'm going to take a look at how it works, a topic suggested by Ken Ferry.
The Objective-C runtime is at the heart of much Mac and iOS code. At the heart of the runtime is the
objc_msgSend function, and the heart of that is the method cache. Today I'm going to explore how Apple manages resizing and deallocating method cache memory in a thread safe manner without impacting performance, using a technique you probably won't find in textbooks discussing thread safety.
Reader Tomas Bouda asks: what's the deal with the
NSObject protocol? There are two
NSObjects in Cocoa, a class and a protocol. Why both? What purpose do they serve? In today's article, I'll explore the answer to this question.
Our long effort to rebuild Cocoa piece by piece continues. For today, reader Nate Heagy has suggested building
Asserts are a powerful tool for building quality code, but they're often poorly understood. Today, I want to discuss the various options for writing asserts in Cocoa apps and the best ways to use them, a topic suggested by reader Ed Wynne.
Reader Anja Skrba from Webhostinggeeks.com
has translated my Objective-C Literals
article into Serbo-Croatian. It's always fun to see translations of my writing, even when I can't understand them at all. If you do understand Serbo-Croatian, or know someone who does, check it out. The Serbo-Croatian version of Objective-C Literals is available on Webhostinggeeks.com
Last time on Friday Q&A
, I began the reimplementation of parts of
. In that article, I discussed the basic theory, the architecture calling conventions, and presented the assembly language glue code needed for the implementation. Today, I present the Objective-C part of
It's time for another trip into the nether regions of the soul. Reader Robby Walker suggested an article about
NSInvocation, and I have obliged, implementing it from scratch for your amusement. Today I'll start on a guided tour down the hall of horrors that is
MAInvocation, my reimplementation of the
NSInvocation API. It's a big project, so today I'm going to focus on the basic principles and the assembly language glue code, with the rest of the implementation to follow.
, I showed how to build the basic functionality of
. I left out key-value coding, because the implementation of
is complex enough to need its own article. This is that article.
NSObject class lies at the root of (almost) all classes we build and use as part of Cocoa programming. What does it actually do, though, and how does it do it? Today, I'm going to rebuild
NSObject from scratch, as suggested by friend of the blog and occasional guest author Gwynne Raskind.
Objective-C is a powerful and extremely useful language, but it's also a bit dangerous. For today's article, my colleague Chris Denter suggested that I talk about pitfalls in Objective-C and Cocoa, inspired by Cay S. Horstmann's article on C++ pitfalls
objc_msgSend function underlies everything we do in Objective-C. Gwynne Raskind, reader and occasional Friday Q&A guest contributor, suggested that I talk about how
objc_msgSend works on the inside. What better way to understand how something works than to build it from scratch? Let's build
on Friday Q&A, I discussed a hypothetical implementation of the
class. Starting on Mac OS X 10.7 and iOS 5,
uses a new runtime facility called tagged pointers to increase speed and reduce memory usage, the inner workings of which I want to examine today.
NSNumber is a deceptively simple class with some interesting implementation details. In today's edition of Friday Q&A, I'll explore how to build a class that works like
NSNumber, a topic suggested by Jay Tamboli.
Welcome back! After a brief hiatus for WWDC, it's time for another wacky adventure. Today's topic is the new object literals syntax being introduced into Objective-C, which was suggested by reader Frank McAuley.
, I discussed the basics of PLWeakCompatibility in terms of the motivation, the basic hooks used to get the compiler to call our code when handling
variables, and calling through to the original implementations where available. Today, I'm going to discuss the implementation of the zeroing weak reference facility that gets used when the runtime doesn't supply its own
A few weeks ago, I introduced
. This is a small library that can be dropped into an app to enable use of the
qualifier on OSes that don't support it. ARC is officially supported on Mac OS X 10.6 and iOS 4, but
is only available on 10.7 and iOS 5.
adds support for
on those older OSes when using ARC. Today I'm going to discuss how
works on the inside.
As a way of atoning for the lack of a Friday Q&A today, I'm pleased to introduce PLWeakCompatibility
. Do you like ARC? Do you need to support older OS releases? Do you wish you could use
variables on those older OSes? If so, then I have good news for you! PLWeakCompatibility is the solution you've been looking for.
Last time on Friday Q&A
, we discussed how to implement
. Today, I'll repeat the same exercise with
and build an implementation of it from scratch.
Collection classes are ubiquitous in Cocoa apps, but also fairly opaque. Today, at the suggestion of Matthew Elton, I'm going to take a look at how
NSMutableArray works behind the scenes by building a replacement for it from scratch.
Every once in a while, when writing threaded code, you may find yourself wanting to acquire two different locks in a critical section. Normally one should resist such perversions, but sometimes they just end up being necessary, or too tempting. Holding multiple locks at the same time immediately raises the specter of deadlock: if two threads acquire the same locks in a different order, they can end up waiting on each other forever.
We've spent the last few weeks talking about disassembling executables and how to read the result. Today, I want to wrap up that discussion with a look at a powerful third-party disassembly tool called Hopper.
Gwynne finishes off her series on analyzing assembly code with a look at ARM assembly, for all of your iOS needs. Gwynne will be contributing the occasional article in the future as well as a guest author, without my introductions. Watch the Author field at the top of the post to see who's writing what. Without further ado, let's take a look at ARM.
Today I have the pleasure to present the followup to last week's guest post. Gwynne Raskind
returns to complete her in-depth analysis of the assembly code generated by a small sample program.
As a small change of pace, today's post is written by guest author Gwynne Raskind
. My last post touched a bit on disassembling object files, and Gwynne wanted to dive deeply into just how to read the output in detail. Without further ado, I present her wonderful in-depth look at reading
Being able to see all stages of your work can be immensely helpful when debugging a problem. Although you can get a lot done only looking at the source code and the app's behavior, some problems benefit immensely from being able to inspect the preprocessed source code, the assembly output from the compiler, or the final binary. It can also be handy to inspect other people's binaries. Today, I want to talk about various tools you can use to inspect binaries, both your own and other people's, a topic suggested by Carlton Gibson.
Last time, I talked about my crazy hack that misuses the Objective-C message forwarding machinery to do block proxying
. This allows writing code that interposes in front of an arbitrary block to intercept its arguments, manipulate its return value, etc. Today, I want to present an exanmple of using this hack which almost verges on the practical. Specifically, I'm going to discuss how to use it to build a generalized block memoization facility.
Here at Friday Q&A, I pride myself on occasionally taking my readers to places where normal people dare not tread. Today is one of those days. This is not a reader suggested topic, but today I want to talk about a fun hack I came up with that allows proxying block invocations in much the way that one can proxy Objective-C messages.
Since the moment Apple announced it, readers have asked me to write about Automatic Reference Counting, or ARC. Today is the day. I'll talk about Apple's new memory management system, how it works, and how to get the most out of it.
The inevitable rotation of the Earth means that it's once again time for another Friday Q&A. For today's edition, Jose Vazquez suggested that I discuss namespaced constants and functions in C.
You're happily writing code one day, click Build, and suddenly the dreaded warning appears:
warning: no '-fooMessage' method found (Messages without a matching method signature will be assumed to return 'id' and accept '...' as arguments.) You double-check your code and your method name is correct, so you shrug and move on. A few hours later, your program starts misbehaving strangely. What's going on? Today, I'll explore the mysterious world of Objective-C method signature mismatches, a topic suggested by an anonymous reader.
Blocks are perhaps the most significant new language feature introduced by Apple in years, and I've written a lot about them before. The new C++ standard, C++0x, introduces lambdas, a similar feature. Today, I want to discuss the two features and how they are alike and how they differ, a topic suggested by David Dunham.
Greetings, salutations, and welcome to another edition of Friday Q&A, the Fridayest source of information on the internet. This week, friend of the blog Jose Vazquez had the idea of discussing miscellaneous compile-time tips and tricks in C/Objective-C, like useful preprocessor techniques and compile-time asserts.
Merry holidays, happy winter, and a joyous Friday Q&A to you all. Camille Troillard suggested that I discuss how to create custom object memory allocators in Objective-C, and today I'm going to walk through how to accomplish this and why you might want to.
It's once again time for a brand new edition of Friday Q&A. This week, I'm going to talk about accessors, and how to properly deal with memory management and thread safety when creating them, a topic suggested by Daniel Jalkut
It's time for another edition of Friday Q&A. In the last Friday Q&A
, I discussed how to create classes at runtime in Objective-C. Today, I'm going to discuss how to actually make practical use of this technique.
Friday Q&A is back! I had some very important slacking to take care of for the past couple of months, but now I'm ready to resume business as usual. For this return to Friday Q&A, I'm going to talk about how to create Objective-C classes at runtime, a topic suggested by Kevin Avila. This topic is meaty enough that this will be a two-parter; today's post will talk about the basics of how to create classes at runtime, and then the next one will discuss uses for such classes and how to take advantage of them.
Welcome back to another word-laden edition of Friday Q&A. About a year ago, I wrote a post on defensive programming
. That post covered defensive programming in a general sense, and Scott Gould has requested that I write one specific to various standard Cocoa practices, which is what I will be talking about today.
Welcome back to another frightening edition of Friday Q&A. This time around, friend and local OS X coder Jose Vazquez
has suggested that I discuss how to implement
in Objective-C classes.
I'm extremely excited to announce a new library for Cocoa and Cocoa Touch development:
. In short, it's a library which allows zeroing weak references to be used in retain/release Cocoa code. This has all sorts of uses and should make retain/release coding less painful. While I discussed this in detail in my Friday Q&A post this week
, I also want to make a separate announcement for people who don't want to read through all of the horrible details.
It's that time of the biweek again. For this week's Friday Q&A, Mike Shields has suggested that I talk about weak references in Objective-C, and specifically zeroing weak references. I've gone a bit further and actually implemented a class that provides zeroing weak references in Objective-C using manual memory management.
Welcome back to a late edition of Friday Q&A. WWDC pushed the schedule back one week, but it's finally time for another one. This week, I'm going to discuss the implementation of equality and hashing in Cocoa, a topic suggested by Steven Degutis.
Last week I discussed the various options available in Objective-C for enumerating over a collection
This week I'm going to finish up the discussion of enumeration with a guide on how to implement Fast Enumeration in your own program.
A couple of months ago I wrote about using Continuation Passing Style
in Objective-C as an alternative technique for returning errors from methods. The major downside to that technique is that it integrates poorly with Cocoa, since Cocoa isn't written to use CPS. Jordan Breeding has spent the intervening time building up an impressive CPS adapter library
which allows converting any Cocoa
call into CPS style with virtually no work. Source code and extensive examples are available, and I encourage you to check it out
Welcome back to another edition of Friday Q&A. Preston Sumner has suggested that I talk about different ways of enumerating over collections in Cocoa, and how to implement Fast Enumeration. This will be a two part series: this week I will look at the different enumeration techniques and their pros and cons, and then next week I will take you through implementing Fast Enumeration on a custom object.
The Earth has moved 6.9 degrees around the Sun since my last post, which means it's time for another edition of Friday Q&A. This 6.9-degree segment, Guy English has suggested that I talk about the use of continuation passing style to simplify error returns in Objective-C code.
It's that time of the week again. For this week's Friday Q&A Mike Shields has suggested that I talk about method replacement and method swizzling in Objective-C.
It's Black Friday, and that means it's time for another Friday Q&A. Today I'm going to talk about the use of accessors in Objective-C init/dealloc methods, a topic suggested by Jon Trainer
It's another Friday and time for another Friday Q&A. This week, fellow Amoeba Jeff Johnson suggested talking about using Cocoa from the command line using Python and PyObjC.
It's time for another Friday Q&A. I hope everyone who had a chance to go to C4 had a good time and is back home safe and sound. This week I'm going to discuss singletons, both how to make them and when to use them, as suggested by Jon Trainer.
Welcome back to another cromulent Friday Q&A. After taking a few weeks off I intend to resume the regular schedule. We'll see how far that intention takes me, but I'm hopeful. This week I'm going to take Daniel Jalkut's suggestion to discuss class loading and initialization in Objective-C.
Welcome back to another exciting Friday Q&A. This week I'm going to continue the series on the Objective-C runtime. Yuji Tachikawa suggested talking about how
@dynamic properties work in CoreData and I'm going to take that and expand it to talk about message forwarding in general.
Welcome back to another Friday Q&A. This week I'd like to take Joshua Pennington's idea and elaborate on a particular facet last week's topic of the Objective-C runtime, namely messaging. How does messaging work, and what exactly does it do? Read on!
Welcome back to another Friday Q&A, on another Friday the 13th. This week I'm going to take Oliver Mooney's suggestion and talk about the Objective-C runtime, how it works, and what it can do for you.
One of the longest ongoing controversies in the Cocoa community is how to write your init methods. More specifically, how to properly call your superclass's initializer. In the hopes of putting this controversy to rest, I want to walk through the right way to write an initializer and exactly why this is the right way.
I finally got a chance to run my performance comparison code on an iPhone, so we can see just how much horsepower this little device has. I still am not able to load my own code onto the device myself, so I want to thank an anonymous benefactor for adapting my code to the new environment and gathering the results for me.
By popular demand, I have re-run my Performance Comparisons of Common Operations on the same hardware but running Leopard.
Leopard's been out for a while now and brings with it a lot of interesting new tools for the Mac programmer. I've had the chance to work with some of them and want to offer my opinion on how they've worked out.
We all know that premature optimization is the root of all evil. But a recent conversation brought to mind that we often don't really know the runtime costs of the code we write. While we should be writing foremost for correctness and clarity, having an idea of these speeds is good, especially when we get it into our heads that some operation is much more costly than it really is. With that in mind, I compiled a list of common Cocoa operations and how much time they require at runtime.
I just hit a subtle but commonly known bug for the first time. I thought I'd share my fun with the world.
Everybody reading this blog should know about autorelease pools and how they work in Cocoa. As everybody knows, every time you go through the event loop, Cocoa blows away the old pool and makes a new one for you, so that all of your autoreleased objects go away and your new ones go into a fresh pool. That way you never build up more objects than get produced during a single event loop cycle.
Using Evil for Good
at 2006-07-14 00:00
People who know me as a programmer probably know that I am a great hater of C++. As someone who does a lot of Cocoa, this extends naturally into hating Objective-C++. But I made good use of Objective-C++ in ChemicalBurn
and I thought I'd share.
Autorelease is Fast
at 2006-06-07 00:00
If you've done much Cocoa programming, you've probably run into a situation where you needed to create a local autorelease pool because of some sort of loop. And you've probably run into advice telling you not to create and destroy the pool for every iteration, because that would be slow. I never believed that it could be significant, and I finally took the time to test it today. What's the verdict? Just as I thought, making autorelease pools is really fast.