> On 19 Mar 2018, at 06:19, amon <[email protected]> wrote: > > I hate to keep pointing it out, but the off the shelf embedded > system we are using is an ARM processor running a circa 2012 > Ubuntu release. They have not changed it in years. We use a > vanilla gcc tool chain. I will do the test compile tomorrow > at work but I very much doubt @autoreleasepool{} exists.
I'm posting from a different email address since it seems that, for some reason, you aren't getting nay of my emails ... maybe using this one will help. Use the CREATE_AUTORELEASE_POOL() macro to create an autorelease pool. Use the DESTROY() macro to get rid of the pool you created. Bracket any code which creates lots of autoreleased objects between calls to these two macros ... and you have great control over memory management. That will work perfectly on your old system. > Actually I posted that tidbit because it looks to me like the > API violates the intent of the the NS foundation kit standards > as I understand them. It was my impression that every Class > should be instantiable via: > > [[Foo alloc] initMyDesignatedInitializer: vals] > > NSHost lacks any reasonable -init: methods. I think it's fair to say that's the correct way of writing classes which are intended to be subclassed. However, not all classes are intended to be readily subclassed. NSHost behaves unusually because it is designed as a cache of network information. When you create an NSHost instance it does expensive DNS lookups which can slow your program, and the class is designed to make it harder for you to write inefficient code. Apple has even deprecated the cache control methods (presumably they have decided that giving developers control over caching is a bad idea), but GNUstep policy is to carry on supporting methods indefinitely even if Apple removes them from their systems. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
