Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 19 Mar 2018, at 06:19, amon <amon@vnl.com> 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.