[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep and valgrind
From: |
Richard Frith-Macdonald |
Subject: |
Re: GNUstep and valgrind |
Date: |
Mon, 19 Mar 2018 08:14:53 +0000 |
> 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.
- Re: GNUstep and valgrind, (continued)
- Re: GNUstep and valgrind, amon, 2018/03/16
- Re: GNUstep and valgrind, amon, 2018/03/17
- Re: GNUstep and valgrind, Ivan Vučica, 2018/03/17
- Re: GNUstep and valgrind, amon, 2018/03/17
- Re: GNUstep and valgrind, Fred Kiefer, 2018/03/18
- Re: GNUstep and valgrind, Richard Frith-Macdonald, 2018/03/18
- Re: GNUstep and valgrind, amon, 2018/03/19
- Re: GNUstep and valgrind, Fred Kiefer, 2018/03/19
- Re: GNUstep and valgrind,
Richard Frith-Macdonald <=
- Re: GNUstep and valgrind, amon, 2018/03/20
- Re: GNUstep and valgrind, amon, 2018/03/20
- Re: GNUstep and valgrind, H. Nikolaus Schaller, 2018/03/20
- Re: GNUstep and valgrind, Andreas Fink, 2018/03/20
- Re: GNUstep and valgrind, H. Nikolaus Schaller, 2018/03/20
- Re: GNUstep and valgrind, Andreas Fink, 2018/03/20
- Re: GNUstep and valgrind, H. Nikolaus Schaller, 2018/03/20
- Re: GNUstep and valgrind, Andreas Fink, 2018/03/20
- Re: GNUstep and valgrind, David Chisnall, 2018/03/20
- Re: GNUstep and valgrind, Wolfgang Lux, 2018/03/20