• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Looping worker threads - NSString vs sprintf
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Looping worker threads - NSString vs sprintf


  • Subject: Re: Looping worker threads - NSString vs sprintf
  • From: Rainer Brockerhoff <email@hidden>
  • Date: Thu, 2 Aug 2001 11:27:38 -0300

First, my apologies to all for forgetting to fix the subject line in my previous message...

At 12:12 +0200 on 02/08/2001, Ondra Cada wrote:
> >>>>>> Rainer Brockerhoff (RB) wrote at Wed, 1 Aug 2001 21:09:12 -0300:
>RB> Hmmm... excuse me, but I can't quite understand why.
>RB>
>RB> If I need a 1 or 2K buffer for a couple of lines to get some result from
>RB> a Carbon call, why shouldn't I malloc it before the call, copy the
>RB> buffer's contents to some object, and then free it again?
>
>Perhaps it got a bit torn of the context here. The reason is to be able to
>autorelease it, so as it does not leak when an exception occurs -- like this:
>
>...
>void *buffer=malloc(XXX);
>... some code which uses buffer ...
>free(buffer);
>...
>
>This way if "some code" happens to trigger an exception, the buffer will leak.


You're right, but...

Must be my C++ background. If I use exceptions at all in a program, I will always free everything I've allocated explicitly in the exception handler. In all of the dozen or so cases where I've used malloc, the "some code" always was a Carbon call to the File Manager, which never generates exceptions AFAIK.



>RB> How would this "wrapping into an object" look like? And then I'd have to
>RB> get a C pointer to its contents, anyway...
>
>Firstly, you can do the same without any effort using NSMutableData.
>Instead, I'll show a trivial implementation of your own object here, to
>elucidate better the point:
>...[long example cut]

Thanks a lot, Ondra. This certainly makes your point for the general case. I'll use when and if it will come up.


>now the list returned me my previous message, and it looked like this:
>
> >>>>>> Ondra Cada (OC) wrote at Thu, 2 Aug 2001 12:12:57 +0200:
>OC> -init {
>OC> NSLog(@"436a27b0 allocated",self);
>OC> return [super init];
>OC> }
>OC> -(void)dealloc {
>OC> NSLog(@"399 freed",self);
>OC> [super dealloc];
>OC> }
>
>Wow?!? Seems somebody on the way _interpreted_ the message just like it was
>a printf-format string :-O :-O :-O

It must be on your side, my private copy of your message looked just the same... must be some automatic side-effect of your NeXT-mailer. Perhaps this illustrates my fear of overly automatic/helpful software ;-)


--
Rainer Brockerhoff <email@hidden>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://www.brockerhoff.net/ (updated July 2000)


References: 
 >Re: cocoa-dev digest, Vol 1 #345 - 15 msgs (From: Rainer Brockerhoff <email@hidden>)

  • Prev by Date: Major Bug in Cocoa (With sample Code!!)
  • Next by Date: file parsing
  • Previous by thread: Re: cocoa-dev digest, Vol 1 #345 - 15 msgs
  • Next by thread: Re: cocoa-dev digest, Vol 1 #348 - 17 msgs
  • Index(es):
    • Date
    • Thread