I'm just getting started with programming GUIs on apple (so far the framework seems fine, but I find the documentation far less informative than others...Qt, .Net, java, etc).
One of the issues I have had is understanding who owns what. For example, if I call CTLineRefCreateWithAttributedString, does the resulting CTLineRef own the attributed string? What if the attributed string is mutable, and I change it? Will this mess up the CTLineRef?
The documentation has been unenlightening.
The reference for CTLineRef provides no information on the subject: https://developer.apple.com/library/mac/#documentation/Carbon/Reference/CTLineRef/Reference/reference.html
Some examples don't release the string, which I take as an indicator that it is owned: https://developer.apple.com/library/mac/#documentation/StringsTextFonts/Conceptual/CoreText_Programming/Operations/Operations.html
Some examples do release the string, which would suggest it is not: https://developer.apple.com/library/mac/#samplecode/CoreAnimationText/Listings/VectorTextLayer_m.html
(this one isn't apple, but he seems more informed them I) http://www.cocoanetics.com/2011/01/befriending-core-text/
So is the string copied or not? If I use a CFMutableAttributedStringRef can I change that or not (I assume I would have to create a new CTLineRef afterwards)?
This is a specific example, but this is question that I have come up against in innumerable places. Any help would be very much appreciated. I feel that there must be some rules that govern these things, but I haven't the slightest idea what those rules are or where I can find them.
The governing rules that you seek are found in the Core Foundation Memory Management Guide. The main point to take away is that you actually don't need to know if the CTLineRef owns the attributed string. Any object can have multiple owners. All you need to worry about is whether or not you own string, and where the most appropriate place for you to relinquish ownership is. If you're done with it after you create the CTLineRef, then feel free to release it.
Consider the rest an implementation detail of CTLineRef. If CTLineRef is following the rules laid out in that document (which it does) and needs to keep the attributed string around, it will have retained it internally. It's also possible that it makes a copy internally (this is likely), and therefore no longer cares about the original. Maybe it sends the string to a server on Mars and queries it every time it needs it later (less likely). The important point is that, regardless of what it does, you can safely release the string if you no longer need it.
As for the mutability and copying behavior, that's a little more fuzzy. You're right that the documentation isn't explicit about the behavior. The documentation is explicit that the object is immutable. That means it's all but guaranteed that it does in fact copy the input string (or parse its contents into something else). It's commonly understood best practice that objects should always make copies of input strings for the exact reason you mention - that the implementation can't know if the supplied string is actually mutable. In order for the implementation to remain robust, it needs to make sure that its internal state can't be changed from the outside world. The only way to make that guarantee is to copy the string. This is true even of mutable classes, which CTLineRef is not.