> On 20 Mar 2018, at 06:31, amon <a...@vnl.com> wrote: > > Richard: > > Thanks. I will look at that. > > And btw, to the person who suggested @autorelease... I was > certain it would not compile, but I tried it anyway. Needless > to say, it did not compile. > > I did try coding > p=[NSAutoreleasePool new]; do something; [p release]; > and in some cases it seemed to help. In others it did not. > I'll be digging deeper tomorrow and I will give the macros > you suggested a try.
The macros are just a wrapper round the code you used, intended to make it easier to port to using garbage collection (no longer supported) or ARC. So 'p=[NSAutoreleasePool new]; do something; [p release];' is fine. Where it "doesn't help" you will be experiencing cases of caching/lazy-initialisation. These are features designed to improve program performance and you should generally not worry about them. That is to say, before worrying about the internals of the library code (which is certainly largely leak free), you need to debug your own code and ensure it's not leaking things itself. Typically, if you have an event driver program the NSRunLoop implementation will create an autorelease pool before calling your event handler, and release that pool after calling your event handler. This means that, unless you create vast quantities of autoreleased objects (enough to crash your program) handling a single event, you should not be worrying about autorelease! If you aren't handling events within a callback from NSRunLoop and are using some other mechanism of your own, you should do the same thing ... create a pool before handlign each event and release it after handling the event. NB . ignore the release/drain debate ... both methods do the same thing in your environment. Your most likely cause of a problem (assuming handling each event is wrappen in pool create/release) is a retain/release error in your own code. To avoid that it's safest not to use retain/release and always use methods that return autoreleased objects. If you are writing classes, the two biggest areas for mistakes are a. assignment to instance variables (to minimise errors, use the ASSIGN macro to assign an autorelease value to a variable) b. object deallocation ... make sure that the -dealloc method releases all its instance variables (use the DESTROY macro to help You can call the GSDebugAllocationList() function (one of many diagnostic features in NSDebug.h) before and after handling an event, to see what objects have been created/destroyed and spot leaks. > If nothing else, I am getting a much better handle on how and > when memory gets sucked up. That's good knowledge to have. Most likely long term leaks are not in the library (though, since you are using a very old version there's more of a chance of it), but you might find one, and more likely you might find a case where some feature caches more data than you are happy with (if your available memory is very tight) and you might want to investigate options to overcome that. > A question on NSHost then. If NSHost essentially returns a > cache of something like what NeXT used to call Class Objects, > like the old Printer Class that always returned the same > object (A technique I still use for something btw) then that > would be less troubling. But to be clear, If I create an NSHost > for "10.0.0.1" in one place in the code, and then some entirely > other area creates one with the same IP, I presume you are > seeing that it will return a pointer to the same object? That > there will never be two NSHosts with the same IP? Correct (unless the cache is flushed ... in which case new objects after the flush will differ from old ones). _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep