---
title: WWDC2000 Session 124
framework: wwdc
role: article
path: wwdc/wwdc2000-124
---

# WWDC2000 Session 124

## Transcript

Kind: captions Language: en we're going to start by talking about CF role in Mac OS 10 as a whole then we're going to look at some of the concert there and finally in this talk will be introducing the basic CF type so when I talk about core foundation this is the big take-home point core foundation is the lingua franca in Mac OS 10 well what does that mean a lingua franca is a medium of communication between people of different different languages so what are the different languages on Mac OS 10 carbon and coco coir foundation is a substrate layer that lives beneath both carbon and Coco so it provides the common language by which those two environments speak to one another as such it bridges the basic types between both stacks and provides those common services that both stacks need to share things like the pasteboard the event model so just as an example here you see the carbon types on the right and the cocoa types on the left corefoundation acts to convert to and fun to and from the types on either side hopefully you've seen this diagram by now this is the basic architecture on Mac OS 10 I want to point out the core services layer that lives below the application services the graphical services like quartz and OpenGL and QuickTime but above Darwin the operating system that layer is where we live we provide the common services needed by everything above us that does not depend on graphics so if you look inside the core services layer you'll see a number of the non graphical managers you're familiar with things like the file managers memory manager resource manager and in with all of those is core foundation in fact core foundation were you to look inside the core services code lies below almost all of those there we go so what is CF it's a non graphical substrate library available to both carbon and cocoa in fact it's even below classic it is written in you're see because that is the common language beneath all of those layers and it's designed around some basic object-oriented paradigm so CF provides two basic things to the system the first one is some basic types by which all of the different substrates can speak so that's things like strings arrays and dictionaries and then we combine them together in an abstraction that we call property list the other thing it provides is the non graphical services that every application needs so that's local ations the localization support user preferences as I said also the pasteboard and the run loop in this talk we're going to focus on the basic data types there's a follow-on to this talk immediately after lunch in the same room where we'll be talking about the second half of that stack the not the app services so where is CF available on Mac OS 10 this core foundation is available as its own library on eight and nine it ships as part of carbon live now there's a there are some pieces of core foundations that are only available on 10 those centres around the mock specific pieces which obviously do not apply on eight and nine finally a subset of core foundation is available inside of Darwin so if you're interested you can check out the Darwin source code and see what we're doing right so I know that it's a developer when I go and approach a stack one of the first things I I don't want to hear is by the way this is this other large API I have to learn so if you don't want to learn CF relax you don't really have to you're missing out but you don't have to carbon and cocoa are both complete ap is on to themselves you can write entirely to those api's if you wish and core foundation will silently help out underneath the stats providing smooth communication however this is what you're going to miss if you yourself need to need to write code that bridges between carbon and cocoa applications for instance if you're writing a low-level library that several several different applications are going to use you should be using CF to convert the types to and from internationalization support is wired into core foundation it's one of the easiest places to get it from there's a rich simple set of data types around those internationalized strings inside of core foundation that's what we're going to focus on here today and there is some new functionality which you can only get by talking to the core foundation stack so what is that new functionality property lists is a big one and that's the one we'll talk about today there's also an an XML parser inside of course foundation it's not the only XML parser on the system but it's the only one in C and it's nice and low level for your use user preferences there's a unified user preferences model inside of course foundation it will save you from having to invent your own preferences file format and doing your own work of reading and writing to file finally and perhaps most importantly the bundle and plug-in model that surrounds the entire app packaging scheme on Mac OS 10 is centered in core foundation so if you want to pull apart the pieces of that app packaging format you should be talking to core foundation ok so now I'm going to move on to talk about the basic concepts and paradigms inside of core foundation I'm going to spend a moment on the general philosophy of the library then I'm going to talk about how we managed to get some object orientation inside of what is a purely see light on C library and finally I'm going to look at the memory management scheme that we use the general philosophy of core foundation is to be lean and mean we are just barely above the operating system layer performance and efficiency is perhaps our primary goal for that reason we have exported a minimal API and tried to make it as powerful and extensible as possible so you will not find a lot of convenience functions to do simple operations you will find some complex powerful functional API where you may have to you may have to do some configuration of the arguments going in finally there is no safety net in course foundation we follow the same philosophy as the C language if you tell us to do something we're going to do it no questions asked so if you hand us a bad pointer we're going to try and access it to try and ease the road a little bit we do provide a debug library and that debug library is available so that as you code you can run against it and it will catch a number of common errors and that way you can help you can start to debug your program so object orientation inside of course foundation focuses on CF types and we try to make this as available as possible in the maiming inside of course foundation so each type is going is opaque and represents a pseudo class and each such type is going to be named CF and then the class name ref the related functions which are acting as methods on the class will always be prefixed with the name of the class CS class name and then in action describing what the function does related constants also are prefixed with the class name k CS class and then a descriptor so for example if we look at CF strings the type of CF string ref an example of a function would be CF string append and an example of the constant would be KCF string encoding ascii furthermore inside the functions the first argument is always the type instance what you would consider the receiver if you were writing in a true object-oriented language then there's one important exception to that and that's creators and we'll get to those in a minute we use common verbs to have common meanings throughout the throughout the API so that CF array get array add is going to work the same way as CF dictionary add finally when we are passing information back to you we will always put those out parameters the ones that are going to be passed by reference at the very end there are a small number of polymorphic functions inside of CF this is the entire list this these functions can be used with any CF type regardless of class so I equality and hashing so you have to equal um c of hash that's what allows us to add at add objects into collections and retrieve them out of it there's a little bit of interest introspection CF get type ID will return the type ID of the class CF copy description will provide a string description of the object this is for debugging purposes only these are not intended to show to the user in fact it will frequently have the hex address of the of the object embedded in them and finally memory memory management we use a reference counting memory management scheme so CF retain gains a reference CF release releases it CF def retain count is intended for debugging purposes only so you can track how the reference counting goes through an object's lifetime and then CF get allocator allows you to discover how the object was allocated so as I just said CF types of reference counted retained to get to take a reference release to release it anytime you have a reference counting screen you have this common problem of who gets who has the reference when an object is returned by a function here are the rules very very simple if the function you called includes the word get you did not get a reference the object you called retains the reference so if you intend to keep that object you'd better retain it yourself functions that include the words copy or create on the other hand give you a reference and when you are done with that object you must release it or else you will have a leak there is something important to keep in mind here we are simply using copy and create as as a way of telling you the developer whether or not you've got a reference there may be some optimizations going on the back particularly in the case of immutable objects so even though you've received a reference copy may not actually do any copy memory copying and likewise create may not do any allocation CF is simply being more efficient and it shouldn't matter to you allocators an alligator there is a type for at CF allocator ref an alligator encapsulate an allocation scheme it you call an alligator to allocate memory to release it to reallocate it and so on and every create function so every function that could create a CF object takes an alligator as first argument and uses that alligator to create the memory necessary normally you're going to want to pass KCF allocator to default which asks CF to use whatever the current default allocator is there's one we have one that we installed by default if you want to you can install your own to do custom memory management that's all I'm going to say on the basic structure of CF or the basic concepts and now I'm going to move on to talk about some of the basic types inside of core foundations we're going to start with CF string because that's probably the most basic of the types the one that you're most likely to be using then we're going to talk briefly about CF array and CF dictionary which are two of our collection types once we're done with that we'll look at how collections and mutability work together inside this library and finally we're going to see how all of that comes together to form property list conceptually a CF string is simply an array of Unicode characters the goal in creating a CF type whereas I show here we're trying to get strength to a new level of abstraction we're trying to solve the 8-bit ASCII problem if we can do that then internationalization becomes easy because the basic type throughout the entire system will support Unicode characters because we're at such a low level we've worked hard to assure performance so even though conceptually you're looking at an array of Unicode characters it may not internally be stored that way in particular you're not always going to be storing two bytes per character and as we move forward CF strings are becoming the way to communicate strings in all of the public api's CF string maintains a very rich functionality set there are a number of different creation functions depending on where you may have gotten the your string data from whether it's coming from a carbon stack or or cocoa or you just read it out of a file there's a lot of support for encoding conversions from CF strings to whatever encoding you need to use we will do comparisons find searches there are some more complex operations like exploding a string into its component pieces or combining the component pieces back again and there's even some printf style formatting and parsing available so let's look at some of the API for creation and access I give an example of a couple of the basic creation methods here CF create with characters allows you to take an array of Unicode characters and create a string out of it pretty straightforward if on the other hand you're coming from a Pascal string for instance you would use the second function CF string create with Pascal strength there are several other similar kinds of functions for the other types CF string create with file system representations you have screen create from data where you provide an encoding and so on for basic access you use the next two functions CF string get length return to the current length of the string CF string get character at index returns the character at the given index if you want more efficient processing you can get a bunch a range of characters at once using CF string get characters and if if you have a CF string and find that you need a Pascal string or some other type to communicate with another API you can get it with CF string get Pascal string only the last line there shows you how you create a constant CF string CF sir all caps and then the string within quotes will produce a constant CF string for your youth mutating some CF strings are mutable we'll talk more about that in a bit if you have immutable strings here are the basic functions you'll use CF string append append appends another string onto the bass string CF string replaced replaces a range of characters inside the current string with another string CF string insert performs a straight-up insertion and CF string trim is added here is an example of more complex functionality available CF string trim will take a trim string and compare it to the beginning and the end of the given string and strip it off however many times it may appear now I said that CF strings are becoming the way by which strings are communicated throughout the api's so here's an example of this if you look inside the carbon toolbox and some old API you may be familiar with set W title and get W title which set and get the title of a window after the introduction of core foundation the API below it has been introduced set window title with CF string copy window title as CF string which allows you to set the window title in a richer Unicode ready manner okay another basic type types inside of CF is CF data see if data is simply a way to get an object representation around an array of bytes it's more versatile than using a simple void store avoid star or a struct pointer because it's opaque and because it encapsulates the notion of length and there are a couple very basic accessors CF data get length and CF data get byte pointer I'm going to move on now to talk about collections there are a number of different collections inside of core foundation and by a collection I simply implement object which can hold other pointers and most of the time you're going to be holding other objects CF array and dictionary are by far the most common of the collections you would be using and array as you would expect holds an ordered list of values and a dictionary holds out values as key value pairs you give me the key i'll give you the value there and there are a number of left common collections also on the system set bad bag bitch vector binary heap tree are just a few of them there are actually several others as well so let's look at CF array a couple creation method CFRA create creates an immutable array you give me an array of values and the number there and i'll create an array around it CF array create mutable creates a mutable array and you will tell us the capacity and the callbacks we'll talk about that in a moment once you've got an array the basic API is the F array get count to find out how many objects are in the array and then CF array get value at index which will give you the value at the given index mutation CFRA insert value at index is is the most common mechanism CS dictionary you'll notice the naming between CF dictionary and CF array is very consistent CF dictionary create creates an immutable dictionary CF dictionary create mutable creates a mutable one CF dictionary getcount gives you the number of key value pairs currently stored in the dictionary get value you provide the key will give you the value back associated with that key and set value allows you to associate a value with a given key so now that we've looked at those basic api's let's talk about collections in more general terms all of our collections contain pointer sized values as I said most of the time you're going to be storing other objects but not always so how do you configure the behavior differently depending on what's being stored well that's what the callbacks are all about you pass the callbacks one to create when the collection is first created and the callbacks tell the object what to do as objects are being added and removed from the collection collections can also be created created either mutable or immutable and we'll go into into both callbacks and mutability and greater detail okay so as I said callbacks determine what the array or the dictionary is going to do as values are added or removed ninety percent of the time you're going to be storing other CF objects inside of the collection when that happens use the default callbacks we provide so for example KCF type array callbacks is the set of callbacks you use for an array that's going to store CF types as you would expect as objects are added to an array this set of callbacks will retain the objects on the way in release them on the way out of the remaining ten percent of the time nine percent of that is going to your collections are probably going to hold pointers that you just want to manage yourself you would rather the collection does not do any management for you when that's the case simply pass null at that point CFR ACF dictionary all the collections will simply take their hands off you give them you give it a pointer value it will hold the pointer value but it won't do anything with it once in a blue moon you will be trying you will be using CF array or CF dictionary to store a special data structure that has its own memory management scheme this is the point at which you're going to be writing your own call back you will have to add functions that define how the object is retained on the way into the collection how it should be released on the way out and then you will pass those callbacks to CF array or whatever collection you're using moving on to the mutability there are three kinds of mutability in the system an immutable object as you would expect you can change neither the content nor the size once the object has been created the data is going to remain constant until the object is destroyed a fixed size collection you can change the contents all you want as long as you do not exceed the given capacity and a fully mutable collection you can change the content and the size not all of the collections support all of the kinds of mutability both array and dictionary do when you're in doubt check the documentation the documentation clearly marked what kinds of mutability are supported by which collections and also I wanted to mention here although CF string and CF data are not themselves collections of other objects conceptually a string of the collection of characters and data is cool is a collection of bytes and therefore we use these mutability principles for both CF string and CF data as well and they also support all three types of mutability so the way it works is this when you call CF string creates the CF array create whatever you're going to get back a fully immutable object when you call CF array create mutable you will get back a mutable object if the specified capacity is greater than 0 that will be taken as the maximum capacity for your collection so CFRA create create mutable with a capacity of 10 produces an array that can never hold more than 10 objects on the other hand if you pass a capacity of 0 we will create a fully mutable object for you and the array or string or dictionary will automatically grow as new objects are added in so for example CF array create it's going to produce an immutable array you just provide the the objects that are going in and the number of them and there you go CS dictionary create mutable passing a capacity of 10 creates a mutable dictionary that can never contain more than 10 key value pairs CF string create mutable passing a capacity of 0 produces a fully fully mutable string of unlimited length and as strings and characters are added to the to this string it will grow to accommodate them so how does this all come together well given these basic pieces of strings datas arrays and dictionaries you can actually build up some very complex trees of objects you can also we also support several other types but string data array and dictionary form the core of them there are a couple restrictions first of all it has to be a true tree no loop so arrays can't include themselves dictionaries can't include or it can't include themselves secondly the keys of the dictionaries must always be strings and we create an abstraction on top of such a structure and call it a CF property list ref so why are property lists useful they're useful because we make them persistent they have a simple flattened XML representation and you can easily convert to and from that flattened XML representation expresses the data and the rich tree structure now we do not handle the file access part of this as a rule core foundation does not touch the file system so it's up to you to read and write the data to and from whatever file you're taking it from so why are the properties why does this make property list useful it's useful because property lists are very easy to program they're small they're very very flexible you know just if you need a new if you need to represent new data just hack another object onto the end of the array or create a new string and as I said they're persistent the API for persistency is very straightforward so if you ever find yourself needing a small flexible data format of some time try out CF property list see if it'll manage your needs the one caveat here is property lists are not useful as a general database it does not scale well and that's because XML is a serialized data representation so there's no ability to scan into the middle and locate an object out of the middle so for example if you look in Mac OS 10 where we use property lists ourselves you'll find them in small configuration files all over the place we use them to configure applications and provide much of the information that find your needs for instance when viewing an app package plugins use configuration files to announce their API as well as announcing how they fulfill the API there are a number of small system eunuch see kind of parameter configuration files that are that have been migrated to property lists we also use them for the user preferences on the system user preferences the classic example of where we don't know what information what information a given application needs to store but we do know that it's likely to be small and we do know that our types are likely to accommodate them the pasteboards property list provides a good flexible medium for communication on the pasteboard we use it there as well and this last point is one of my favorites so you need to deliver an application yesterday you might well prototype using property lists as your datastore that will at least save you the burden of figuring out how you're going to what your final data format is and we found it remarkably flexible for doing quick prototyping in fact the the original HTML rendering engine in the cocoa framework used properly lists entirely for its backing store so I mentioned there were some other property list types these are very simple object wrappers that you would rarely use except that you need to store a particular kind of value in a property list the three most common are listed here CF date wraps asst wraps a date or time CF number and CF boolean wrap simple numeric values and again we're not suggesting that you use this in place of a raw integer or a raw boolean rather when you find you need to store such a value in a property list these rappers are available to do that ok debugging and getting help I mentioned earlier that there is a debug library available inside of course foundation what the debug library adds is a number of extra assertions argument checking that kind of thing and what happens is as soon as one of those assertions finds an invalid argument it's going to log an error and abort your program that's going to make it much easier to isolate the problem find the change get a good back trace and we found that many of the most common programming errors in we see with core foundation can be caught this way so please run against the debug library as you develop core foundation code I've also put a list here of the most common errors in programming with core foundation passing null is CF type there's a classic one null is not a CF type it is not a valid argument to any of them any of the pseudo methods inside of core foundation another common error is releasing the return value of a get function you call CF array get value you never got a reference to the word the function includes the word get but you release it anyway well sooner or later that array is going to be destroyed or someone else is going to remove that value from the array at that point the array will release the object itself boom memory Smasher the other half of that equation is failing to retain the value that came back from a get function so once again you get a value out of CF array using CFRA get value you intend to keep that value pass the lifetime of the array you need to retain it if you do not when the array disappears so does your object okay so there you are in a debugging session you've got a CF type you don't know what it is and you're trying to figure out what's gone wrong you see us get type ID to determine the class of the object you've got you can compare that with CF typename get type ID so see a string get type ID returns the type ID for all strings yes array get type ID returns the type ID for all arrays CF show will print out any CF object to the console or wherever standard out happens to be in gdb you can invoke CF show directly from within a break point very useful for looking at what exactly has gotten into your string if you would rather get that that information into memory UCF copy description it will give you exactly the same output but stored in a CF string so you can if you want right it's a file look at it later whatever tracking memory problems that occur in the system CF get retain counts will always return the current reference count of an object you can use that to make sure that the reference count is incrementing or decrementing as you expect you can install a custom default allocator and use that to locate leaks and memory corruption and finally if you look on a vp for system there's an application in system developer applications called object Alec you can view you can run your program under object Alec and it will show you some of the CF types as they are allocated and destroyed all of the common ones are there if you have string or a dictionary all that kind of stuff finally there's a fair bit of documentation online you can find it in system developer documentation core foundation on the dt for CD it's also available on the web at developer.apple.com tech pubs core foundation there is some example code inside of system developer examples core foundation and the release notes are available in system developer documentation release notes corefoundation HTML you