you're right.
I do make the assumption that only sane exceptions are
thrown...meaning subclasses of NSException std::exception. Certainly
any code that I control only throws proper exceptions. For C++
functions, I use exception specifiers. so, if any function throws the
wrong type of
Hi Stephen,
thank you very much for taking the time to look at the given link and writing
this very nice response to me.
Think I was little confused so I mixed a few things that simply should stay
seperate.
(Managing resources in close() has simply nothing to do GarbageCollection. Some
On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarnerb...@mac.com wrote:
On Jun 27, 2009, at 8:38 PM, Michael Ash wrote:
(And I only say almost because I can only assume there's a corner
case out there somewhere with CoreFoundation-using code, since CF
objects are also garbage collected, but I am
On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:
Thomas Davie tom.da...@gmail.com schrieb am 27.06.2009 09:56:31:
On 27 Jun 2009, at 01:27, James Gregurich wrote:
GC isn't nirvana. it does have its perils and issues, and you have
to be aware of them and code around them. You can't just
On Jun 28, 2009, at 04:39, Michael Ash wrote:
On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarnerb...@mac.com wrote:
When a CF object is created, it is CFRetain()ed and, thus, the
collector
will ignore it. If it is then managed entirely through a balanced
set of
CFRelease() and CFRetain()
On Sun, Jun 28, 2009 at 11:06 AM, Thomas Davietom.da...@gmail.com wrote:
On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:
I still have to read much more about the GC used within Objective-C /
Cocoa so I am not sure, if I am not writing some kind of bullshit from
your view:
Isn't it possible
On 28 Jun 2009, at 19:27, Stephen J. Butler wrote:
On Sun, Jun 28, 2009 at 11:06 AM, Thomas Davietom.da...@gmail.com
wrote:
On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:
I still have to read much more about the GC used within Objective-
C /
Cocoa so I am not sure, if I am not writing some
On 28 jun 2009, at 10.34, Thomas Davie wrote:
Again, IDisposable in C# has nothing to do with early
destruction/deallocation of the object. It's purpose to is perform
explicit cleanup of external resources, resources not managed by the
GC system. For example: file handles, sockets, OS system
On Sun, Jun 28, 2009 at 1:17 PM, Quincey
Morrisquinceymor...@earthlink.net wrote:
I think the answer is in Bill's entirely, above.
Without CFMakeCollectable, the final CFRetain will trigger the calling of (a
hypothetical) CFDispose with the traditional timing (i.e. immediately, we
assume,
On Jun 28, 2009, at 16:12, Michael Ash wrote:
Your way sounds sensible, but according to the docs that's not how
it is.
We'll have to wait for b.bum to adjudicate, since the docs contradict
what he said earlier:
On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarnerb...@mac.com wrote:
When a
On Jun 28, 2009, at 4:12 PM, Michael Ash wrote:
On Sun, Jun 28, 2009 at 1:17 PM, Quincey
Morrisquinceymor...@earthlink.net wrote:
I think the answer is in Bill's entirely, above.
Without CFMakeCollectable, the final CFRetain will trigger the
calling of (a
hypothetical) CFDispose with the
On Sun, Jun 28, 2009 at 7:33 PM, Peter Dunihope...@nwlink.com wrote:
Maybe I'm misreading one, or the other, or both of your messages, but it
seems to me that what Quincy wrote is in agreement with what you quoted.
In particular, my (admittedly inexperienced) understanding is that an object
On Jun 28, 2009, at 6:32 PM, Quincey Morris wrote:
On Jun 28, 2009, at 16:12, Michael Ash wrote:
Your way sounds sensible, but according to the docs that's not how
it is.
We'll have to wait for b.bum to adjudicate, since the docs
contradict what he said earlier:
bbum is currently on
On Sun, Jun 28, 2009 at 4:32 PM, Quincey
Morrisquinceymor...@earthlink.net wrote:
On Jun 28, 2009, at 16:12, Michael Ash wrote:
Your way sounds sensible, but according to the docs that's not how it is.
We'll have to wait for b.bum to adjudicate, since the docs contradict what
he said
On Jun 28, 2009, at 4:40 PM, Michael Ash wrote:
Doesn't take any experience, just a bit of reading. I'd recommend that
all participants in this thread read the Garbage Collection
Programming Guide top to bottom before continuing any further
This article:
From: James Gregurich bayoubenga...@mac.com
3) I don't allow exceptions of any kind to propagate into alien
codeparticularly the cocoa runtime.
Given that Objective-C doesn't have declared exceptions (like Java), it seems
more likely that you hope
Graham Cox graham@bigpond.com schrieb am 27.06.2009 05:13:37:
Using GC may mean you can avoid even that small degree of necessary
care, but the ownership rules are straightforward, easily learned and
committed to mind, and are hardly arcane or arbitrary - they are
simple and
Hi all!
Thomas Davie tom.da...@gmail.com schrieb am 27.06.2009 09:56:31:
On 27 Jun 2009, at 01:27, James Gregurich wrote:
GC isn't nirvana. it does have its perils and issues, and you have
to be aware of them and code around them. You can't just turn it on
and some how everything
I simply should have waited till I am much deeper
inside all this Objective-C / Cocoa stuff. Reading all the discussion about the
GC pros and cons simply made me write something, too.)
With kind regards,
Konrad
___
Cocoa-dev mailing list (Cocoa-dev
On Sun, Jun 28, 2009 at 10:50 AM, Konrad Neitzelneit...@neitzel.de wrote:
But a garbage collector must be able to detect an object which memory can /
must be released. And for all this, the system has to do some work.
I still have to read much more about the GC used within Objective-C / Cocoa
On 27 Jun 2009, at 01:27, James Gregurich wrote:
GC isn't nirvana. it does have its perils and issues, and you have
to be aware of them and code around them. You can't just turn it on
and some how everything magically works. There is no perfect
solution to memory management. I prefer a
On Jun 27, 2009, at 5:11 AM, Graham Cox wrote:
I don't really get why the memory management/ownership rules seem to
be so hard for so many people. But I accept that they are, to some.
If they are, maybe GC is a godsend to those folk, but for everyone
else, I just can't see the big deal.
On 27 Jun 2009, at 14:04, Klaus Backert wrote:
On 27. Jun 2009, at 09:54, Thomas Davie wrote:
On 27 Jun 2009, at 01:27, James Gregurich wrote:
GC isn't nirvana. it does have its perils and issues, and you
have to be aware of them and code around them. You can't just turn
it on and
On 27. Jun 2009, at 14:17, Thomas Davie wrote:
Now I'm confused, because other people said, GC frees objects
*when* nothing depends on them any more *or* at some point later in
time. By the way, it would be different, if you said if instead
of when, but then, I think, you would have no
On 27/06/2009, at 8:58 PM, WT wrote:
I don't think they are hard to understand, or even apply, at all. I
just extrapolated - and, admittedly, did so without having the
benefit of experience - that on very large problems, they would
almost always cause a maintenance nightmare. Your
On Sat, Jun 27, 2009 at 8:17 AM, Thomas Davietom.da...@gmail.com wrote:
If you're worried about running
out of space because the collector is lazy, then all you need to know is
that as soon as you get to the oh shit, no memory stage, the collector
runs and frees some more up (unless there
On Jun 27, 2009, at 9:22 AM, WT wrote:
I'm curious now... Is that an in principle statement, or has it
happened to a project that you know of? If the latter, can you
elaborate a little on the nature of the project, as in what it was
about it that outran the gc?
This is well covered in the
There has been enough signal in this thread that I haven't asked for
it to be ended, but it is rapidly spiraling the bowl. Specifically,
the last dozen or so messages -- mine included -- have been a rehash
of the same points. I like GC / I don't like GC / GC is non-
deterministic / Non-GC
On Jun 27, 2009, at 4:09 PM, Michael Ash wrote:
It's *hard* to outrun it and run out of memory, but
it can be done.
I'm curious now... Is that an in principle statement, or has it
happened to a project that you know of? If the latter, can you
elaborate a little on the nature of the
1) I have convenience macros that @catch and throw NSExceptions for
the legacy 32 bit environment. I don't allow legacy objc exceptions to
propagate out of code blocks.
2) I don't use @synchronize. I use boost::thread::mutex so that I have
one consistent, standard locking API throughout
Bill,
If you guys are going to some day make that statement the law, then
please keep in mind that whatever you do has to operate with cross
platform C++ code using standard memory management techniques. Many of
us have to deal with other unix systems and Windows. We need this
stuff to
On Sat, Jun 27, 2009 at 1:57 PM, James Gregurichbayoubenga...@mac.com wrote:
Bill,
If you guys are going to some day make that statement the law, then please
keep in mind that whatever you do has to operate with cross platform C++
code using standard memory management techniques. Many of us
On Jun 27, 2009, at 9:28 AM, Bill Bumgarner wrote:
- GC applications are less crash prone than non-GC applications
(yes, really -- Xcode's crash frequency has dropped significantly in
the move from non-GC to GC, for example).
One con of adopting GC on Leopard is that your app is quite
On Jun 27, 2009, at 4:45 PM, Jeff Johnson wrote:
One con of adopting GC on Leopard is that your app is quite likely
to spam the console log profusely, making a small but technically-
minded and vocal minority of your users very angry with you. rdar://problem/6301496
, dupe of
On Jun 27, 2009, at 6:05 PM, Nick Zitzmann wrote:
That, and 64-bit GC apps allocate a whopping 32 GB of VM on startup
on Leopard, which might scare a few people that (1) watch Activity
Monitor like a hawk, and (2) think that VM == swap. Most people
won't notice, though.
It actually isn't
On Jun 27, 2009, at 5:45 PM, Jeff Johnson wrote:
One con of adopting GC on Leopard is that your app is quite likely
to spam the console log profusely, making a small but technically-
minded and vocal minority of your users very angry with you. rdar://problem/6301496
, dupe of
James Gregurich wrote:
1) I have convenience macros that @catch and throw NSExceptions for
the legacy 32 bit environment. I don't allow legacy objc exceptions
to propagate out of code blocks.
2) I don't use @synchronize. I use boost::thread::mutex so that I
have one consistent, standard
I figured the details out and taught my staff to use the techniques.
it isn't that hard. I learned what I needed to know from the objc 2.0
manual and a little bit of trial and error.
The critical thing to watch are the exceptions since those are
incompatible in legacy mode. You just have
On Sat, Jun 27, 2009 at 4:57 PM, James Gregurichbayoubenga...@mac.com wrote:
Bill,
If you guys are going to some day make that statement the law, then please
keep in mind that whatever you do has to operate with cross platform C++
code using standard memory management techniques. Many of us
On Sat, Jun 27, 2009 at 7:27 PM, Bill Bumgarnerb...@mac.com wrote:
On Jun 27, 2009, at 6:05 PM, Nick Zitzmann wrote:
That, and 64-bit GC apps allocate a whopping 32 GB of VM on startup on
Leopard, which might scare a few people that (1) watch Activity Monitor like
a hawk, and (2) think that
On Jun 27, 2009, at 8:38 PM, Michael Ash wrote:
(And I only say almost because I can only assume there's a corner
case out there somewhere with CoreFoundation-using code, since CF
objects are also garbage collected, but I am not actually aware of
any.)
When a CF object is created, it is
On 28/06/2009, at 8:45 AM, Jeff Johnson wrote:
One con of adopting GC on Leopard is that your app is quite likely
to spam the console log profusely, making a small but technically-
minded and vocal minority of your users very angry with you. rdar://problem/6301496
, dupe of
From: James Gregurich bayoubenga...@mac.com
I have read up on GC, and I don't like the idea of introducing
non-deterministic behavior into my code base.
I would question the assertion that GC introduces non-deterministic behavior,
unless you consider the
Everyone knows there's no garbage collection on the iPhone because the
Waste Management Union #601 local convinced the nationwide union to
protest their low wages by striking. They apparently didn't want to
add one more garbage route to their workload with no increase in pay.
I doubt
If my resource is handed off to some external subsystem for release and I can't
DETERMINE the order of the releases with respect to each other and other
components of my code, then I would call that non-deterministic and undesirable.
feel free to disagree. the purpose of my message was to
On Jun 26, 2009, at 1:31 PM, James Gregurich wrote:
If my resource is handed off to some external subsystem for release
and I can't DETERMINE the order of the releases with respect to each
other and other components of my code, then I would call that non-
deterministic and undesirable.
As
sure. if I'm sharing ownership of an object with the OS or some library, then
I'm granting that code the option to keep the object around a long as it needs
it. You're right. I can't predict exactly when the object might go away. If
something isn't going away, it is because some system is
On Fri, Jun 26, 2009 at 2:31 PM, James Gregurichbayoubenga...@mac.com wrote:
If my resource is handed off to some external subsystem for release and I
can't DETERMINE the order of the releases with respect to each other and
other components of my code, then I would call that
the previous response to Bill is relevant to this response.
ok. What percentage of cocoa classes will exhibit the behavior you describe?
I've never seen an objc class that mysteriously hangs around beyond the
destruction of its dependencies (including any autorelease pools that contain
it).
On Fri, Jun 26, 2009 at 4:27 PM, James Gregurichbayoubenga...@mac.com wrote:
ok. What percentage of cocoa classes will exhibit the behavior you describe?
I've never seen an objc class that mysteriously hangs around beyond the
destruction of its dependencies (including any autorelease pools
On Friday, June 26, 2009, at 07:27PM, James Gregurich bayoubenga...@mac.com
wrote:
I've never seen an objc class that mysteriously hangs around beyond the
destruction of its dependencies (including any autorelease pools that contain
it). I wouldn't be shocked if there were somemaybe some
On Jun 26, 2009, at 5:41 PM, Kyle Sluder wrote:
you're unprepared for the reality of modern
software development
What? GC has been around for 25+ years hardly a modern concept.
Garbage collection was invented byJohn McCarthy around 1959 to solve
the problems of manual memory
On Friday, June 26, 2009, at 04:41PM, Kyle Sluder kyle.slu...@gmail.com
wrote:
100% might. Maybe 0% today, and then tomorrow Apple might release an
update that causes all objects to hang around forever. You don't
know, and you shouldn't care.
I don't. in practice its not particularly
On Fri, Jun 26, 2009 at 5:40 PM, David Blantonaired...@tularosa.net wrote:
What? GC has been around for 25+ years hardly a modern concept.
Garbage collection was invented byJohn McCarthy around 1959 to solve the
problems of manual memory management in Lisp.
Perhaps you missed my direct
sorry. I don't do strawman arguments. a strawman agument would be comparing
garbage collectors to MMUs and task schedulers. You guys are getting downright
silly trying to be clever with the sarcasm. I don't feel like playing that
game. I'll leave that to you twenty-somethings who have the
On Fri, Jun 26, 2009 at 5:40 PM, James Gregurichbayoubenga...@mac.com wrote:
I really don't get this whole line of reasoning. I don't get why the fact
that a system keeps an NSFont around justifies me adding a whole new system
to scan memory and look for pointers to determine which ones need
Forgive me for the intrusion, for
a) I am not what one would consider an experienced Cocoa developer,
b) I have not used GC in Cocoa projects yet,
c) my experience with GCs is limited to Java, and
d) I have read most, but not all, the posts in this thread.
Having disclaimed myself, this is what
much better response. thanks.
The sarcastic stuff gets old.
On Friday, June 26, 2009, at 05:54PM, Kyle Sluder kyle.slu...@gmail.com
wrote:
That wasn't where I was going with that. I was making two distinct
points: 1) You can't depend on any Cocoa object actually getting
released at any
On Friday, June 26, 2009, at 09:20PM, WT jrca...@gmail.com wrote:
It seems
to me that micro-managing memory can get out-of-hand rather easily on
large projects. By adopting a GC approach, I'd be relinquishing some
control, yes, but I'd be gaining the peace of mind of not having to
debug a
On Jun 27, 2009, at 3:30 AM, Andy Lee wrote:
On Friday, June 26, 2009, at 09:20PM, WT jrca...@gmail.com wrote:
It seems
to me that micro-managing memory can get out-of-hand rather easily on
large projects. By adopting a GC approach, I'd be relinquishing some
control, yes, but I'd be gaining
On Fri, Jun 26, 2009 at 6:21 PM, James Gregurichbayoubenga...@mac.com wrote:
That wasn't where I was going with that. I was making two distinct
points: 1) You can't depend on any Cocoa object actually getting
released at any time.
I certainly can the vast majority of the time.
You can also
On Fri, Jun 26, 2009 at 8:40 PM, James Gregurichbayoubenga...@mac.com wrote:
On Friday, June 26, 2009, at 04:41PM, Kyle Sluder kyle.slu...@gmail.com
wrote:
100% might. Maybe 0% today, and then tomorrow Apple might release an
update that causes all objects to hang around forever. You don't
On Fri, Jun 26, 2009 at 8:54 PM, Kyle Sluderkyle.slu...@gmail.com wrote:
Closures are notoriously hard to implement without some form of
automatic memory management. Forgetting everything announced and
unannounced about upcoming features of ObjC, we have a small version
of this issue right
Oh my hell, List Mom, please put a stop to this. The poor horse was
beaten to death long ago.
Thanks
On Jun 26, 2009, at 7:56 PM, Michael Ash michael@gmail.com wrote:
On Fri, Jun 26, 2009 at 8:40 PM, James
Gregurichbayoubenga...@mac.com wrote:
On Friday, June 26, 2009, at 04:41PM,
On Friday, June 26, 2009, at 06:39PM, Kyle Sluder kyle.slu...@gmail.com
wrote:
On Fri, Jun 26, 2009 at 6:21 PM, James Gregurichbayoubenga...@mac.com wrote:
That wasn't where I was going with that. I was making two distinct
points: 1) You can't depend on any Cocoa object actually getting
I actually don;t agree that the system keeping NSFonts around to use them is
non-deterministic. The system will get rid of them when it is done with them.
that is a perfectly predictable activity. Maybe I don't know what all the
machinery is doing or what all the input is that goes into the
On Fri, Jun 26, 2009 at 7:37 PM, James Gregurichbayoubenga...@mac.com wrote:
I actually don;t agree that the system keeping NSFonts around to use them is
non-deterministic. The system will get rid of them when it is done with them.
that is a perfectly predictable activity. Maybe I don't know
On 27/06/2009, at 11:20 AM, WT wrote:
2) Stick to retain/release and have to maintain a potentially
extremely complicated object graph, with potentially large and
interlocking retain cycles?
In practice this isn't the bogeyman that people (particularly newbies)
tend to assume. I'd say
On Fri, Jun 26, 2009 at 10:24 PM, James Gregurichbayoubenga...@mac.com wrote:
hehe. oh yes they do. You can put any TYPE you want in shared_ptr. If you
want to put a posix file descriptor in it, just use close() as the custom
deleter. works great. In fact, I guard SQLite db handles with
On Jun 24, 2009, at 9:15 PM, Jeff Laing wrote:
1. If your objects use (scarce) resources that are not themselves
subject to GC (file handles, network connections, whatever), you'd be
[snip]
2. If you expect objects to be returned to the free memory pool the
instant that those objects aren't
On Thu, Jun 25, 2009 at 3:54 AM, Peter Dunihope...@nwlink.com wrote:
In a GC system, the fact that an object hasn't been collected yet doesn't
interfere with future allocations. All it means is that the GC hasn't
gotten around to collecting the object yet. If and when a new object is
On Thu, Jun 25, 2009 at 10:37 AM, Michael Ashmichael@gmail.com wrote:
That may be the theory, Apple's ObjC collector does *not* trigger on
allocation errors (at least not reliably or sufficiently, and as such
it is possible to outrun the collector by creating a large number of
objects in a
On Jun 25, 2009, at 9:50 AM, Michael Ash wrote:
Oh, forgot to mention, in case any Apple peoples are reading this and
interested in it (although I imagine that any who care already know),
this is filed as rdar://5563149 which is still open as of this
writing.
It'll be returned to you shortly
On Jun 25, 2009, at 7:37 AM, Michael Ash wrote:
That may be the theory, Apple's ObjC collector does *not* trigger on
allocation errors (at least not reliably or sufficiently, and as such
it is possible to outrun the collector by creating a large number of
objects in a tight loop.
Well, as far
On Jun 24, 2009, at 8:11 PM, Kyle Sluder wrote:
On Wed, Jun 24, 2009 at 7:55 PM, Peter Ammonpam...@apple.com wrote:
Microsoft even says that all objects must be robust against being
Dispose()d
multiple times, which smacks of sloppiness. If your program
disposes of an
object twice, then it
On Jun 24, 2009, at 22:49 , Greg Titus wrote:
...whereas this part talks specifically about the collector. Is
there a downside in SnowLeopard to CFRetain/CFRelease when not
using the collector?
There's no _new_ downside to CFRetain/CFRelease. It's just the
existing downside
On Jun 25, 2009, at 0:54 , Peter Duniho wrote:
Furthermore, it is more typical that there _is_ space already
available on the heap to satisfy an allocation request, and in a
typical GC system allocations are much faster than for the alloc/
free paradigm. I admit, I don't know the
On Jun 25, 2009, at 11:41 AM, Peter Duniho wrote:
Well, as far as I'm concerned that's a bug then, and a somewhat
silly one at that. There should be no reason they couldn't easily
address that scenario, simply by using the thread attempting to do
the allocation to run the collection code
On Thu, Jun 25, 2009 at 11:39 AM, Peter Ammonpam...@apple.com wrote:
Are you saying that it's not sloppy to close a file twice, unlock a lock
twice, etc.?
It sounds to me like you were originally referring to language
implementation sloppiness, which has nothing to do with closing a file
twice,
On Jun 25, 2009, at 12:11 PM, Kyle Sluder wrote:
On Thu, Jun 25, 2009 at 11:39 AM, Peter Ammonpam...@apple.com wrote:
Are you saying that it's not sloppy to close a file twice, unlock a
lock
twice, etc.?
It sounds to me like you were originally referring to language
implementation
On Jun 25, 2009, at 12:11 PM, Kyle Sluder wrote:
[...] .NET users often call Dispose()
explicitly, because it is useful in situations other than inside using
blocks.
Though, to be clear (lest the tendency to want to put down the other
be allowed to go too far)...
The requirement in .NET
On Jun 25, 2009, at 3:14 PM, Peter Ammon wrote:
In any case, it's been my experience that GC makes memory management
much easier, but precious resource management somewhat harder. It's
harder because GC forces more of a divorce between the management of
memory and precious resources, and
On Jun 25, 2009, at 1:16 PM, Peter Duniho wrote:
On Jun 25, 2009, at 12:11 PM, Kyle Sluder wrote:
[...] .NET users often call Dispose()
explicitly, because it is useful in situations other than inside
using
blocks.
Though, to be clear (lest the tendency to want to put down the other
On Jun 25, 2009, at 1:42 PM, Bill Bumgarner wrote:
On Jun 25, 2009, at 3:14 PM, Peter Ammon wrote:
In any case, it's been my experience that GC makes memory
management much easier, but precious resource management somewhat
harder. It's harder because GC forces more of a divorce between
From: Bill Bumgarner b...@mac.com
..
Bill I don't know if this was discussed before, but could you discuss the
lack of GC on the iPhone?
Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
On Jun 25, 2009, at 7:58 PM, Chris Idou wrote:
Bill I don't know if this was discussed before, but could you
discuss the lack of GC on the iPhone?
Not enough hours in the day to get everything done
(No, I can't speculate about things that don't exist).
b.bum
On Jun 25, 2009, at 9:20 PM, Rob Keniger wrote:
In single-core systems, even on the Mac, performance of Garbage
Collected code is very poor because the collector has to share CPU
time with the main thread. When Xcode 3 (a GC app) was first
released in the Leopard betas there were still
On 26/06/2009, at 10:58 AM, Chris Idou wrote:
Bill I don't know if this was discussed before, but could you
discuss the lack of GC on the iPhone?
I suspect it is for performance reasons. The Objective-C garbage
collector is designed to run in a separate thread on the Mac, which
: GC pros and cons
On 26/06/2009, at 10:58 AM, Chris Idou wrote:
Bill I don't know if this was discussed before, but could you discuss the
lack of GC on the iPhone?
I suspect it is for performance reasons. The Objective-C garbage collector is
designed to run in a separate thread on the Mac
On Thu, Jun 25, 2009 at 4:14 PM, Peter Ammonpam...@apple.com wrote:
2) Require that malloc be robust against multiple free()s on the same
pointer
The second solution is a lot easier to implement.
Can you elaborate on this? Thinking about how to accomplish this, it
seems like an extremely
On Jun 25, 2009, at 8:19 PM, Chris Idou wrote:
I still use XCode in one location where I work on a core-solo Mini.
Performance is good. No problems at all, no pauses.
Interesting. I found the Xcode editor to be unusably slow on a
PowerBook G4 when Leopard was released; in fact, contrary
, the iPhone does not have virtual memory, so its not an issue
there.
From: Adam R. Maxwell amaxw...@mac.com
To: cocoa-dev Dev cocoa-dev@lists.apple.com
Sent: Friday, 26 June, 2009 1:32:51 PM
Subject: Re: GC pros and cons
On Jun 25, 2009, at 8:19 PM, Chris Idou wrote
On Jun 25, 2009, at 10:32 PM, Adam R. Maxwell wrote:
Interesting. I found the Xcode editor to be unusably slow on a
PowerBook G4 when Leopard was released; in fact, contrary to Bill's
statement, I found that it grew worse in the last few months of
Leopard seeding. I'm still sore about
I'll speak up and throw a wrinkle into this discussion. I found it
useful and may some others will also.
I have read up on GC, and I don't like the idea of introducing non-
deterministic behavior into my code base. However, it is true that
manually retaining and releasing pointers is
On Fri, Jun 26, 2009 at 12:06 AM, James Gregurichbayoubenga...@mac.com wrote:
I also take advantage of references in C++ to pass objc objects around
without having to do null checks all over the place to keep code resilent.
-(void) passMyObject: (NSObject) theObj
{
NSLog(@%@, theObj);
consistently using the technique pushes the null check to one or two
placessuch as when the pointer is alloc'ed.
regardless of whether messaging nil is a problem or not, if nil isn't
a a valid state for a variable, I check it and throw an exception as a
matter of defensive
On Jun 24, 2009, at 09:14, Philip Aker wrote:
Like Gwynne, I'm comfortable with the traditional reap what you
sow philosophy. This has benefits in that the basic policy spills
over into other areas of programming and gradually, one learns as a
matter of habit, to account for things all
On Jun 24, 2009, at 12:51 PM, Quincey Morris wrote:
In a nutshell, for folks like me who regularly use CFCreate …
CFRelease in loops, what are the benefits of GC?
If CFCreate/CFRelease is precisely what you want to do, there are no
benefits from GC, because the garbage collector isn't
On Jun 24, 2009, at 09:14, Philip Aker wrote:
Like Gwynne, I'm comfortable with the traditional reap what you sow
philosophy. This has benefits in that the basic policy spills over into
other areas of programming and gradually, one
learns as a matter of habit, to account for things all
I think it depends what language you weaned yourself on. If you've used Lisp
or some other
functional language, manual reclamation is an unthinkable monstrosity. If you
weaned yourself
on C or similar languages, manual reclamation seems like the default state of
play.
Its also going to
1 - 100 of 109 matches
Mail list logo
