Re: GNUstep and valgrind

[Fred Kiefer]

> Am 19.03.2018 um 07:19 schrieb amon <amon@vnl.com>:
> 
> 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 will find a work around, and yes, I am indeed that anal. And
> I am in aerospace. But I repeat myself...
> 
> 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. Not my call if
> that is the way folks want it, but it would not be my way
> of doing it.

Actually this is not a standard or at least one with quite a few exceptions. 
When ever it is reasonable that the class should be managing its instances 
itself, you may find that the alloc/init pattern isn’t used. Or even if it is 
used something different happens in the background. This occurs for example for 
subclass clusters, where the main class hides a bunch of implementations in 
different subclasses or, as with NSHost, cases where the class caches 
instances. This does not violate your possibilities as a developer and doing it 
via factory methods is a lot cleaner than the other possibility that gets used 
too, overriding the alloc method internally.