Mac OS X v10.6 provides support for block objects in C, C++, and Objective-C. Huh? Isn't this a feature of a compiler, not an OS?
OS X includes its own compilers.
API changes in Snow Leopard
11–19 of 19 posts
Re: API changes in Snow Leopard
#12Mac OS X v10.6 provides support for block objects in C, C++, and Objective-C. Huh? Isn't this a feature of a compiler, not an OS?
This is one reason why I like the old NeXT term "system software" in favor of "OS". (The former is all inclusive.)
Blocks are a language feature, and do need compiler support. The version of the compiler that you need to use them in GCD comes with v10.6 system software.
Re: API changes in Snow Leopard
#13Mac OS X v10.6 provides support for block objects in C, C++, and Objective-C. Huh? Isn't this a feature of a compiler, not an OS?
I'm not sure why you got down voted to 0 for asking a legitimate question. The block objects are part of Grand Central Dispatch. A programmer tags an isolated unit of work as a block. The OS then takes these blocks and schedules them into execution queues. While the compiler adds support for defining the blocks themselves, OS X 10.6 provides purpose to these blocks. Just like you can have a VM which supports threads…
It also needs the instantiation support at the VM/runtime level, which is separate from the services the OS itself provides.
So blocks need to be supported at the compiler level, in the Objective-C runtime and in OS-wide processes (which would be Grand Central itself).
Re: API changes in Snow Leopard
#14The first thing I wanted to see as a Smalltalker was how much they've baked Blocks into the libraries. I know Cocoa has always had very long method names, but some of these names are wild: - #enumerateObjectsUsingBlock: is #do: - #objectsPassingTest: or #indexesOfObjectsPassingTest: are #select: And so on. Here's what I'm looking at: http://developer.apple.com/mac/library/documentation/Cocoa/R...
It's nice they retrofit blocks into the lib though, I didn't think they were going to add them beyond GCD.
Re: API changes in Snow Leopard
#15Mac OS X v10.6 provides support for block objects in C, C++, and Objective-C. Huh? Isn't this a feature of a compiler, not an OS?
It involves compiler and runtime changes, although they have been backported to the iPhone and 10.5:
Re: API changes in Snow Leopard
#16I don't know if someone else care, but I find it annoying that the "blocks" proprietary extension to C/C++ is conflicting with C++/CLI syntax for managed pointers.
Is it proprietary? I thought it was open-sourced, and submitted to the standards body?
("citation needed", I haven't checked this)
Re: API changes in Snow Leopard
#17I don't know if someone else care, but I find it annoying that the "blocks" proprietary extension to C/C++ is conflicting with C++/CLI syntax for managed pointers.
Isn't the CLI syntax for managed pointers itself a proprietary extension to C/C++?
C++/CLI was originally developed by Microsoft and then standardized by ECMA.
OpenCL was originally developed by Apple and then formalized by the Khronos Working Group.
So, it kind of depends on your definition of proprietary.
Re: API changes in Snow Leopard
#18The first thing I wanted to see as a Smalltalker was how much they've baked Blocks into the libraries. I know Cocoa has always had very long method names, but some of these names are wild: - #enumerateObjectsUsingBlock: is #do: - #objectsPassingTest: or #indexesOfObjectsPassingTest: are #select: And so on. Here's what I'm looking at: http://developer.apple.com/mac/library/documentation/Cocoa/R...
The names make perfect sense within the context of the language. Just because you add a new feature to a language doesn't mean you should arbitrarily adopt the naming conventions of its implementation in another language.
Re: API changes in Snow Leopard
#19The first thing I wanted to see as a Smalltalker was how much they've baked Blocks into the libraries. I know Cocoa has always had very long method names, but some of these names are wild: - #enumerateObjectsUsingBlock: is #do: - #objectsPassingTest: or #indexesOfObjectsPassingTest: are #select: And so on. Here's what I'm looking at: http://developer.apple.com/mac/library/documentation/Cocoa/R...
I call it "ctrl+space semantically-aware word completion" and "self-documenting function names."
Nothing unusual in multi-year multi-programmer software.
As much as I like succinct function names, in my experience they don't work when there's more than one hacker involved. A strategy I have followed is to make long names for the top-level, interface-like functions, and succinct ones for all the internals; i.e. put the verbosity where others need to look up code to use it as a library, where "library" is understood as an individual/indepenent component of a larger software project.