No.
Assuming the property you describe is declared something like this:
@property (strong, atomic) NSMutableArray * myArray;
Then what's atomic is getting and setting the entire array. That is
[project setMyArray:[[NSMutableArray alloc] init]]; would be atomic.
Once a caller obtains the array
Spin locks are useful in certain situations.
First of all, on a single-processor system, it's never a good idea to use a
spin lock because all it will do is burn up the waiting thread's scheduling
quantum while preventing a thread that's holding the lock from getting
scheduled so that it can compl
Brian
On Thu, Mar 8, 2012 at 12:14 PM, Charles Srstka wrote:
> On Mar 8, 2012, at 1:19 PM, Brian Lambert wrote:
>
> In many simple scenarios, especially when contention is very low,
> @synchronized will be the best choice because it's trivial to get right and
> high-performa
wrote:
> On Mar 8, 2012, at 2:51 PM, Brian Lambert wrote:
>
> > I should have said, "relatively". As in, good enough for many scenarios
> where it will be used infrequently and keeping the code simple makes sense.
> >
> > Of course, you're right, Charles.
&g
The short answer is that:
1) Given our current languages and tools, parallel programming is hard.
2) For the moment, it is generally the case that one thread is enough to
keep a UI updated and responding to events, thus avoiding #1.
3) When one thread isn't enough to keep a UI updated and respondi
Scott, it's not that any one thing is hard to get correct. Arrogantly
calling someone stupid, as you've done here, doesn't help. It's
the subtlety of getting *everything* correct. A GUI system, and the
programs that are layered on top of it, embody a great deal of complexity.
Allowing multiple
"Ouch. If you think that's a problem, then trust me, you would really make
a mess with multiple UI threads."
That isn't calling someone stupid? Really?
Ah, OK. My inference processor must be in error.
On Wed, Mar 14, 2012 at 9:14 AM, Scott Ribe wrote:
> On Mar 14, 2
I’ve been developing iOS applications full-time for about 6 months now and
I love it. I feel pretty strong on the platform now.
I have a lingering question about something that’s really been bugging the
heck out of me, though, that I thought I would ask the list and get some
feedback on.
It seems
I'd like an argument, please.
Regarding this:
In the chapter called "Defining a Class", not only is declaring
an ivar in the .m file covered, but doing it in the .h file is downright
discouraged (rightly so). In practice, this feature of Objective-C...
I can't stand thus sort of subt
about my implementation of Foo. I'm just trying to
ensure that my *intent* for my class is well-understood to other
programmers who will work on Foo in the future.
On Mon, Mar 19, 2012 at 12:27 PM, Brian Lambert wrote:
> I'd like an argument, please.
>
> Regarding this:
>
Hi Alex,
Regarding you having to "repair" code where "UI elements that have been
hardcoded in place with the approach of: Just define the CGRect and we're
all good." I think you're seeing things as being "gross" when they are not.
"Just define the CGRect and we're all good" is what IB does. A X
ilder. Anything you
can do in Interface Builder you can do in code, and vice versa, and
sometimes one is better than the other.
There's a conservation of complexity.
On Mon, Mar 19, 2012 at 1:46 PM, glenn andreas wrote:
>
> On Mar 19, 2012, at 3:22 PM, Brian Lambert wrote:
>
d then at
> runtime, a 1.x multiplier might be applied to the plane that the controls
> are drawn upon. But, I never had the time to rip through it all and get to
> the bottom of it all.
>
> So, sweet. Thanks a bunch.
>
>
>
> On Mar 19, 2012, at 4:22 PM, Brian Lambert wrot
;mode" feature could be used for the German layout, too.
:-)
I think this would be insanely cool. It would allow one to build ONE XIB
with N modes for iPhone Portrait, iPhone Landscape, iPad Portrait, iPad
Landscape, LTR, RTL, and so on, all sharing a base set of controls, views,
and connectio
*Hey!
I'm part of a team starting a new company called Directr. We're
turning **personal
moviemaking upside down by allowing **anyone to create beautiful, short,
shareable movies **in just a few minutes.*
*
*
*Starting today, we’re giving our friends a sneak peek into what **we’re
working on and a
Please accept my apologies for this mistake. I didn't intend to send my
last message to this list!
Brian
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators
16 matches
Mail list logo
