|
Well, we can simplify the analysis a bit. CGColorRef is a "CF" type, i.e. not an Objective-C type, and it stays a CF type everywhere in this code snippet. Therefore, ARC is not doing anything here at all. This is one of the unfortunate limitations of ARC right now. For the same reason, the property does not know that it needs to do retains and releases for the object it's holding on to; it just stashes the pointer away as a bunch of bits. This is true independent of ARC. Now, your code probably works, because this is probably the only store which ever happens to that property, so setting it to a +1 value has the rough net effect of having it retain that value. However, the color will be leaked unless -[SomeOtherObject dealloc] releases it. If you want a property of CF type to behave like a property of ObjC type, you have to give it a custom implementation to do the necessary retains and releases. Probably what you actually want here, though, is to make it a readonly property and have the object's init method set its color ivar directly.
|
#
¿
Feb 1, 2012 20:53
|
|
|
|
| # ¿ May 16, 2024 16:26 |
|
|
Carthag posted:Thanks for the input. The awakeFromNib is in another object, which has an IBOutlet pointing to someOtherObject - I don't want to put the line in init, it's meant to be possible to customize the appearance of sOO from outside. Okay. Then yeah, you should make a setter. Carthag posted:So if I make a custom getter/setter pair + take care of the ivar in [someOtherObject dealloc], do I annotate the @property declaration so ARC knows that it's fine to accept a +1 retained CF value? How would I let ARC know that it's fine? Well, it's the static analyzer that's complaining, not ARC. ARC doesn't do anything special for CGColorRef. The convention and best practice for setters is to have them expect an object at +0, which means they need to retain it themselves. Yes, that means there's an unnecessary retain and release. It also means that awakeFromNib would have it balance out its own +1 it after doing the set, which is a pain. Such is life with manual retain/release. It would've been better if the convention for setters had been +1, but then you'd have to enumerate everything that qualifies as a "setter", and it'd be a pain when working with objects that you only had at +0, and it's too late anyway. If you're sure you want to write a custom setter that expects a +1 CF value, you can give it a custom declaration with the CF_CONSUMED attribute, and that should shut the static analyzer up: code:rjmccall fucked around with this message at 23:33 on Feb 1, 2012 |
|
#
¿
Feb 1, 2012 23:29
|
|
|
Carthag posted:Just seems like there would be a real quick way to just shoot off a CGColorRef like you would an NSObject. It's something we're looking at. There are some serious language issues around it, though.
|
|
#
¿
Feb 2, 2012 01:28
|
|
|
CCCallFuncN expects the selector to take a single CCNode* argument. You're not going to get wild misbehavior on any of Apple's current platforms, but the parameter's not going to have a useful value; it's basically just going to be 8 bits out of a pointer value, and which bits you get exactly is platform-dependent.pokeyman posted:I'm curious, what does the implementation get as a parameter when you don't pass one? Or, similarly (in appearance if not explanation), why does it work to give NSTimer a selector that takes no parameters? Well, it's relatively easy to check a selector to see how many parameters it takes, but you actually don't need to in this case: as long as the calling convention isn't callee-pop (which the default CC is not, at least on any of Apple's platforms), it's always safe to pass extra arguments to a function. Well, except that it's undefined behavior and the compiler might optimize it, but (and this is not a promise) the compiler is unlikely to ever do that with ObjC message-sends. rjmccall fucked around with this message at 19:56 on Feb 3, 2012 |
|
#
¿
Feb 3, 2012 19:48
|
|
|
Xcode no longer installs anything by default in /usr, but it won't blow things away that previous installs have put there. You don't need anything in /usr at all if you work exclusively within Xcode and its build system, but if you also want to be able to (e.g.) work on open-source Unix software with a Makefile-based build system, you should install the command-line tools. Contrariwise, if you never use Xcode and its build system, you can now just install the command-line tools without needing a full Xcode package.
|
|
#
¿
Feb 22, 2012 02:30
|
|
|
Ender.uNF posted:Can you comment on Guard Malloc on the iOS 5 simulator issue I was having above? You are about the only person I know of who might have any clues. There seems to be a nasty order-of-initialization problem with running the iOS 5 simulator on Lion, and I don't see any user-level workarounds for it, sorry. Essentially, there are unmodelled dependencies between the component libraries in libSystem, and those dependencies go completely mad when the simulator shim libraries are added in. File a radar if you haven't already; it'll be duped internally, but those really do help us establish priorities. Unfortunately, there's nothing else I can do personally. ETA: also, I am going on vacation for a couple of weeks, so if you don't get any more responses from me for awhile, that's why. 
rjmccall fucked around with this message at 10:03 on Feb 22, 2012 |
|
#
¿
Feb 22, 2012 10:00
|
|
|
I can't really speak for that team, but I think this specific update just completely defeats the delta-update mechanism. The installed package has been significantly reorganized, and pretty much everything is now installed within the Xcode app bundle itself instead of in /Developer. Future updates relative to this one should still be delta updates, and indeed the delta mechanism will probably be somewhat more effective now. ETA: Oh, if it's mangling previous SDKs somehow then I really don't know. rjmccall fucked around with this message at 05:00 on Mar 9, 2012 |
|
#
¿
Mar 9, 2012 04:58
|
|
|
In case you're curious, there's a good reason why Xcode is frequently tied to the absolute latest OS release: it's a GC application. The memory model of the ObjC collector is fundamentally unsound in some serious ways — for example, only object pointers are managed by the collector, but objects can explicitly own unmanaged memory using finalizers — that make it quite easy to introduce certain classes of bugs. Worse, those bugs can be masked by compiler vagaries (if a pointer is incidentally left around as garbage on the stack, the collector conservatively considers it live) or user-code vagaries (the collector does a lot of thread-local management, and thread-local collections trigger after a certain amount of work occurs, which in practice means that there are intervals during which transient liveness bugs will reliably not cause problems until the call pattern changes just slightly). This is exacerbated by there not being very many significant GC applications in the first place, which means that if anyone's going to find those bugs, it's usually Xcode. So when Xcode X.Y requires Mac OS A.B.C, it's usually because they found yet another latent bug somewhere in the system frameworks.
rjmccall fucked around with this message at 07:13 on Mar 14, 2012 |
|
#
¿
Mar 14, 2012 07:10
|
|
|
It's a very nice, reliable utility, and a ton of effort has gone into making it robust, but still, just for sanity's sake, please do use source control and review the changes. Other than that, the tool tries to err on the side of making conservatively safe changes. That means that there are some patterns of code where're we going to give up and require manual intervention from the programmer. That should be a relatively modest amount of work, but who knows? One major caveat is that the utility can introduce retain cycles that you'll need to manually track down and eliminate. This is, of course, much more likely when you're migrating GC code, simply because it's unlikely that you worried about them when writing it. Also, the current utility is really designed for migrating manual retain/release code to ARC rather than migrating GC code. If you have the Mountain Lion seed available, that might be of interest.
|
|
#
¿
Mar 14, 2012 22:38
|
|
|
Gordon Cole posted:So the utility in Mountain Lion's Xcode is better at converting GC code? If that's the case I'll just hold off until I start working with Mountain Lion. If the current utility doesn't handle retain cycles well, that could definitely cause a lot of issues with my current code. I can't really speculate here about what might be in some future Xcode release. That said, the retain-cycles thing is more of an inherent limitation (because the migrator can't really know what you object graph looks like) and not something that future updates are likely to make substantially better.
|
|
#
¿
Mar 14, 2012 23:54
|
|
|
EDIT: Early drafts of this post were needlessly opaque; it's open to discuss since it's been open-sourced. Some future release of Clang will provide default synthesis of properties. We went around on this a lot, but we ended up settling on adding an underscore prefix to the property name as the synthesized ivar name. Yes, sadly, this is inconsistent with the standard rule for @synthesize, which is part of why we went around on it a lot; ultimately, we felt it was better to add such a mangling, even without prior public blessing, in order to eliminate the significant risk of accidental use of the ivar vs. the property. EDIT 2: Also, we don't really care about people conflicting with our ivar names, so feel free to use simple underscore prefixes. I know there's probably still some documentation out there saying otherwise, but it is stale and should be reported. rjmccall fucked around with this message at 23:42 on Mar 15, 2012 |
|
#
¿
Mar 15, 2012 23:27
|
|
|
I can assure you that some people feel very, very strongly about it.
|
|
#
¿
Mar 16, 2012 00:04
|
|
|
I believe that should actually still work via the same sort of implicitly-linked-archive magic that ARC used. The frameworks teams asked us not to use the same selectors so that they could have the leeway to change behavior for subscript expressions without changing behavior for the existing methods. Plus there is some possibility of other classes taking advantage of the syntax without wanting to declare methods they consider inappropriate.
|
|
#
¿
Mar 21, 2012 03:45
|
|
|
Toady posted:Leave it to the Objective-C mailing list to debate the innocuous existence of literal syntax. Well, you know. It may be literal syntax today, but tomorrow NSArray will be a class template and 50% of every .m file will be a long series of declarations like code:Plus these literals don't just transparently work with my pointless hand-rolled collections framework. Surely this spells doom for all of Objective-C.
|
|
#
¿
Mar 22, 2012 03:34
|
|
|
BOOL is, for stupid historical reasons, a typedef for signed char and gets @encoded as such. Try using bool (for which you'll need to #include <stdbool.h> if this isn't ObjC++).
|
|
#
¿
Apr 2, 2012 22:05
|
|
|
Well, first off, BOOL predates C99 and was historically char; unsurprisingly, there's code which manages to rely on holding other values in the type. We consider that code buggy, but it takes effort to fix these things, and you can't actually change the type anyway without breaking ABI. It doesn't help that PowerPC made _Bool 32-bits for some terrible reason. I think we've just missed the opportunity to change it on all the new architecture transitions we've done (for i386, x86-64, and ARM). It's signed char because the old Mac compilers used to treat char as signed, but GCC says it's unsigned, and it was easier to switch the typedef than to switch the Mac default to -fsigned-char and then fix all the unsigned-char assumptions in the BSD code. And changing compilers broke ABI for C++ anyway, so nobody cared about the mangling difference.
|
|
#
¿
Apr 2, 2012 23:27
|
|
|
Objective-C is a superset of whatever version of C you ask for. clang uses C99 as the default. gcc and llvm-gcc still used C89. _Bool is just the official name of the C99 bool type (they didn't want to conflict with people's various typedefs and macros, so they used an identifier in the reserved namespace). I already spelled out why Objective-C has not yet moved to making BOOL a typedef for _Bool. We actually cannot change this for existing platforms because it would break binary compatibility in a number of subtle ways.
|
|
#
¿
Apr 3, 2012 06:03
|
|
|
Instruments has some tools for tracking the retain/release calls on objects.
|
|
#
¿
Apr 13, 2012 18:30
|
|
|
It is definitely technically possible. Your app will need to emulate the requests that would be made via the normal web interface, including whatever authentication the registration site uses. This may be straightforward or an obnoxious reverse-engineering effort, depending on how the system's been engineered. You have a major advantage, though, in that web technologies are pretty hard to obfuscate. The first place to start is to capture the HTML and Javascript used by the registration page and try to understand everything it's doing and how it interacts with the server. That can be a really good lesson in and of itself. \/ Oh, and that, of course. As an unofficial client of the registration servers, the admins will have no compunctions at all about breaking you. rjmccall fucked around with this message at 07:39 on Apr 15, 2012 |
|
#
¿
Apr 15, 2012 07:37
|
|
|
Clang has recognized both of those switches for years. If you're getting warnings about it, it's probably because the flag's being passed to the wrong command (e.g. to the linker). If so, it's innocuous, and it's not a problem as long as the actual compile line has it as well. Are you adding these as CFLAGS? I'm pretty sure there's some specific option to disable thumb, and I wouldn't be surprised if your flag is getting overridden by that; the last relevant option on a line usually wins. I'd need to see an actual command line to diagnose it further.
|
|
#
¿
Apr 17, 2012 08:45
|
|
|
xgalaxy posted:Anyways. It still stands that its compiling thumb when it shouldn't. I don't know what to tell you, other than that the object file is somehow not making it into the archive. Have you tried a clean rebuild, or failing that a "hard" clean rebuild (i.e. deleting your build directory)?
|
|
#
¿
Apr 17, 2012 22:49
|
|
|
If you run that command yourself in Terminal, does it produce a thumb object file?
|
|
#
¿
Apr 18, 2012 00:49
|
|
|
xgalaxy posted:But if I look at the archive file libGG.a with otool using the command: I think otool is just confused. Looking more closely, that code is totally crazy and is almost certainly not actually thumb code. What problem are you actually having?
|
|
#
¿
Apr 18, 2012 02:44
|
|
|
xgalaxy posted:Client is using Unity3d, which is compiled arm only. The thing is, instruction formats — especially 16-bit instruction formats — are so densely encoded that pretty much any arbitrary byte sequence can be interpreted as an instruction stream. My understanding is that otool tries to distinguish them by recognizing likely ARM prologues vs. likely THUMB ones, but that's obviously a fallible heuristic. In this case, this is pretty clearly an ARM instruction sequence, because if you reinterpret it as 32-bit (little-endian) instructions, the top four bits of almost every instruction are 1110. In the ARM instruction format, the top four bits are the condition code, and 1110 means "always". I also took the time to manually decode the first instruction, and (if I got it right) it's ldr r3, [r0, #8], which is pretty plausible.
|
|
#
¿
Apr 18, 2012 05:51
|
|
|
I think that's a different instruction stream. The first instruction in the one you posted before was definitely e5903008. It's equivalent, anyway, because the value in r2 in the new stream was copied there from r0 in the first instruction, so it's apparently just a slightly different register allocation. That's not surprising, because we've rewritten the register allocator since we last updated llvm-gcc.
|
|
#
¿
Apr 18, 2012 21:15
|
|
|
Ender.uNF posted:rjmccall can confirm but I believe it just automatically makes the ivar with an underscore. You just don't have to think about it anymore. Right. If your class @interface declares a property foo that you don't explicitly define in the @implementation (whether by @synthesize, @dynamic, or just defining its methods yourself), the compiler will implicitly synthesize the property against an ivar named _foo. The default for explicit @synthesize won't change, of course. As a necessary prerequisite, the compiler now also does the C++ trick of scanning the @implementation for all its method declarations before parsing any of the method bodies, so you also no longer need to forward-declare methods that you just use in your @implementation, in case that ever affected anyone.
|
|
#
¿
Apr 19, 2012 21:29
|
|
|
It's probably easier to think of block expressions as having weird syntax, while the other two cases follow the same basic rule. What you're calling the typedef syntax is just the normal C declaration grammar, called a declarator. For example, it's how you'd declare a local variable, ivar, property, etc. of block type. The syntax for an Objective-C method parameter puts the name off by itself (for historical reasons, really, but it also looks nicer), so the type follows a grammar that's exactly like a declarator, but without a name. It's called an abstract-declarator, and it's the same grammatical production that you'd put in a cast. In a block expression, you're also writing an abstract-declarator, except (1) you're writing a function type, not a pointer-to-function type, so you don't need a second caret or the weird parentheses, and (2) you can leave bits of it out, including either or both of the return type (which gets inferred according to the return statements) and the parameters (which get inferred to be empty).
|
|
#
¿
May 6, 2012 04:59
|
|
|
Martytoof posted:I assume 4.4 will be backported to 10.7 right? RIght now it's a 10.8 only beta thing, but I can't imagine that wouldn't be the case. It is supported on Lion. In fact, if you install the DP app on a Lion box, it should run just fine there. I wasn't actually sure if I could say that publicly, but Chris Lattner verified it in the thread Hog Obituary just linked, so there you go.
|
|
#
¿
May 6, 2012 21:55
|
|
|
Ender.uNF posted:Of course not everything in C++11 is intelligent. Their lambda syntax sucks balls. I understand wanting to be able to declare whether the captured variables are by-ref or by-val but the [] should be optional and in that case capture any referenced vars and have the compiler default to by-val const. That would (IMHO) cover the 99% case without requiring you to stop and think about it. I agree that implicitly capturing values should be the default, but the language would be really hard to parse without something in front saying "hey, this is a lambda", because the next token is either a '(' or a '{', and those are pretty overloaded already. That's why block expressions start with a caret: it's totally unambiguous, since there isn't a unary caret operator. Ender.uNF posted:I think the way Apple designed Objective-C blocks is beautiful and makes way more sense - the rules are somewhat along those lines. Regular vars are copied by-val, except if qualified with __block in which case they are still stack-allocated unless you call Block_copy, then they get promoted to heap variables (Block_copy is generally required for a block to be useful outside its containing scope). Blocks were designed a bit before I got here, and there are a few aspects of the design that I'm really not satisfied with. The most important is that forcing programmers to worry about Block_copy is really unfortunate; the compiler should be allocating the block on the heap by default and treating stack-allocation as an optimization when a block provably doesn't escape (maybe the user can specifically request this optimization). The second objection is that the syntax is geared heavily towards center-embedding blocks (i.e. just writing them where you're using them), which is great for tiny blocks and really terrible for big ones; it's relatively awkward to define a block function on one line and then use it later on, and yet there are lots of use cases for doing exactly that. The third objection is that defining a recursive block (e.g. a dispatch_async block which can re-enqueue itself) is extremely awkward. The last objection is that, while implicit capture is a great default, it would be nice to be able to list the captures explicitly and maybe attribute them up (e.g. to request that a value be captured weakly). But overall I tend to agree that the block design is pretty good. Ender.uNF posted:On the other hand: about loving time with enums and that is something I'd like to see in C/Objective-C post-haste. Dumping all the enum members into the global namespace is the dumbest idea in the history of computer science, requiring everyone to essentially repeat the name of the enum in every member (except where the enum name is at the end for some enums in which case the Intellisense/hints are less than useless in showing you your options). On the one hand, I agree; on the other hand, at this point we can't fix this in the case where it really matters, namely the massive lists of enumerated constants in the system headers.
|
|
#
¿
May 6, 2012 22:32
|
|
|
Carthag posted:I guess I'll try with locks or @synchronized and see how that performs. The reason I was using concurrent operations in the first place was for performance since I'm handling on the order of 10k+ objects being parsed and put into dictionaries and it takes about 40 seconds(!) when it's not concurrent. Have you profiled? Objective-C has a lot of flaws as a "systems" language in which to do serious work on large working sets, but it's not nearly that bad; I would guess that your algorithm is doing something quadratic. For example, if you're used to an environment with an O(1) substring operation, you might be surprised to learn that taking a non-trivial substring of an NSString actually copies the underlying data.
|
|
#
¿
May 13, 2012 22:30
|
|
|
The language designers at the time were convinced that it was important for safety. That's really a misconception — it does practically nothing for safety — but it's what they honestly believed. They also believed they could make the atomicity very cheap for all the most common kinds of properties. That's actually even true for assign properties of a size and alignment that the processor guarantees atomic access for — it'll just compile to a single load or store instruction, which is safe because atomic does not makes memory ordering guarantees. Unfortunately, their strategy for doing lockless retain properties ran into the reality of people sometimes wanting to directly access backing ivars, and so the most important use case became locking.
|
|
#
¿
May 15, 2012 02:06
|
|
|
Ender.uNF posted:Any chance of a compiler flag to flip the default or is it just another of those things we'll be stuck with? One of those things, sorry. Ender.uNF posted:I'm also curious about the ivar situation because with ARC, accessing the ivar preserves the proper retain/release semantics right? So why couldn't the compiler use stuff like cmpxchg if the ivars are accessed directly? Naively I would expect the vast majority of properties to be pointers or to fit within 64 bits (eg IEEE double). Well, if it's assign, you don't even need a cmpxchg. Most processors guarantee the atomicity of loads and stores of aligned pointers (for single-instruction loads and stores, of course), and so we do that when we can. Remember, no memory ordering. Okay, what if it's retain? The problem with direct accesses to ivars is that there's a race condition when reading the ivar — you need to be sure that the pointer you read isn't released before you can retain it. To go lockless, you need some sort of protocol where the reader makes writers wait until the retain is complete. When you're communicating via the value of a single ivar, that means the ivar has to temporarily take some recognizably invalid value. That's why direct accesses are unsafe: there's a possibility they might read a completely invalid value. We could make direct accesses follow the safe protocol, but then they'd be a lot slower, and a lot of people would not welcome that sort of intrusion from their compiler (even under ARC, but especially outside it). There are still interesting cases where the compiler could try to deduce safety, but that's problematic because of reflection — which is really important because of things like KVC.
|
|
#
¿
May 15, 2012 06:02
|
|
|
Martytoof posted:Pretty newb question regarding ARC. Well, it's not implemented in terms of inserting retain/release calls into a parse tree, and there are a few situations where that wouldn't really be possible syntactically. For the most part, though, yes, we could theoretically implement an ARC-to-MRC converter — it'd just be a lot of work for something that we, frankly, don't believe is necessary and don't want to encourage.
|
|
#
¿
May 18, 2012 21:18
|
|
|
Doc Block posted:If memory serves, ARC is only supported on iOS 4.3 and up, not 4.2. Note that iOS 4.3 doesn't actually provide any sort of intrinsic runtime support for ARC. We don't support running on older OSes because we didn't want to go through the effort of qualifying it on older OSes, not because we know some reason it wouldn't work there. Personally, I haven't heard any reports from users either way.
|
|
#
¿
May 18, 2012 23:40
|
|
|
Usually the best pattern is for there to be a very clear hierarchy of ownership and a very clear stage of teardown that originates from the owner. Even putting memory safety aside, if an event is propagating up from a child, the parent immediately tearing things down is going to leave that portion of the tree in an inconsistent state when control returns to the child. Instead the parent should say "hmm, come back to me after this operation is done and I'll tear all this down", e.g. by dispatching a block to do that on the current queue.
|
|
#
¿
May 19, 2012 08:37
|
|
|
ManicJason posted:After assuring that my one strong reference was being set to nil, I went to the allocations instrument. There's a Leaks instrument that's designed exactly for this kind of bug.
|
|
#
¿
May 31, 2012 18:05
|
|
|
ManicJason posted:I didn't see anything in leaks at a glance and didn't expect to since this was a circular reference, not a leak. The object never deallocating when I freed my one strong reference was the problem. Hmm, no, you're right. You do this through Allocations — if you can find the allocation, there should be an arrow to the right of the address, and you can click through that to find the alloc/retain/release history. It doesn't seem to be any different in ARC.
|
|
#
¿
May 31, 2012 21:57
|
|
|
Zhentar posted:I'm pretty sure the answer to this is no, but is there anyway under ARC to explicitly autorelease something? Basically, I need a __bridge_retain_autorelease. (Without going into too much detail, I have a legitimate use case for something explicitly unsupported by ARC; an ARC autorelease would just let me keep the impact of the lifetime management to one line). You can make a local __autoreleasing variable and assign to it. Zhentar posted:Fake edit: could I just call objc_autorelease myself? No. If this isn't marked unavailable in ARC, it should be; also, that would cause an over-release because the autorelease will not be balanced. Zhentar posted:Real edit: great, the rewriter strips out all retains from properties, but no one told the warnings the default is strong now. So I've got many hundreds of warnings now. Awesome. Really? File a bug, please. I also strongly encourage you to try the Xcode 4.4 preview if you can.
|
|
#
¿
Jun 8, 2012 18:56
|
|
|
ManicJason posted:That and the total lack of retain/release statements in the allocations instrument is making me really hate Apple this week. Allocations is specifically designed to capture the lifetimes of objects, not their entire history. If you want that history, you should be using the Leaks instrument, which AFAICT gives you exactly the same ability to browse allocations but also captures the retain/release history of the object.
|
|
#
¿
Jun 15, 2012 19:42
|
|
|
|
| # ¿ May 16, 2024 16:26 |
|
|
If those are the 4.3.3 command-line tools, they are definitely different from the 4.5 tools.
|
|
#
¿
Jun 19, 2012 21:59
|
|