Re: Thread safety/freindlyness vs. performance (Was: Modest string handling optimisations)

[Markus Hitter]

Am 26.08.2004 um 12:01 schrieb Richard Frith-Macdonald:

> I'm not 100% sure ... there are some methods (eg. 
> stringByExpandingTildeInPath)
> which are specifically documented as returning the receiver, so either 
> we go against
> the MacOS-X documented behaviors in these cases, or we don't have a 
> consistent
> policy :-(

According to your interpretation, Apple's docs don't match behaviour on 
OS X, however.

In pseudo-code and according to what I picked up in discussions, the 
correct behaviour whould be:

- - - - - - -
if (containsTilde) {
    return [NSString stringWithFormat: ... ];
} else {
    if ([self isMutable]) {
        return [NSString stringWithString:self];
    } else {
        // compatible to OS X, safe and performs better
        return [[self retain] autorelease];
        // or
        // mathces OS X exactly
        return [[self copy] autorelease];
    }
}
- - - - - - -

A testcase, including testing the mutability of the result:

- - - - - - -
#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
  NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
  NSString *noTildePath = [NSString stringWithString:@"/usr/include"];
  NSString *tildePath = [NSString stringWithString:@"~mah/"];
  NSMutableString *noTildeMutablePath = [NSString 
stringWithString:@"/usr/include"];
  NSMutableString *tildeMutablePath = [NSString 
stringWithString:@"~mah"];

  NSLog(@"\nnoTildePath: %@ (%p)\n          -> %@ (%p)",
        noTildePath,
        noTildePath,
        [noTildePath stringByExpandingTildeInPath],
        [noTildePath stringByExpandingTildeInPath]);
  NSLog(@"\ntildePath: %@ (%p)\n        -> %@ (%p)",
        tildePath,
        tildePath,
        [tildePath stringByExpandingTildeInPath],
        [tildePath stringByExpandingTildeInPath]);
  NSLog(@"\nnoTildeMutablePath: %@ (%p, %d)\n                 -> %@ 
(%p, %d)",
        noTildeMutablePath,
        noTildeMutablePath,
        [noTildeMutablePath 
respondsToSelector:@selector(appendString:)],
        [noTildeMutablePath stringByExpandingTildeInPath],
        [noTildeMutablePath stringByExpandingTildeInPath],
        [[noTildeMutablePath stringByExpandingTildeInPath] 
respondsToSelector:@selector(appendString:)]);
  NSLog(@"\ntildeMutablePath: %@ (%p, %d)\n               -> %@ (%p, 
%d)",
        tildeMutablePath,
        tildeMutablePath,
        [tildeMutablePath respondsToSelector:@selector(appendString:)],
        [tildeMutablePath stringByExpandingTildeInPath],
        [tildeMutablePath stringByExpandingTildeInPath],
        [[tildeMutablePath stringByExpandingTildeInPath] 
respondsToSelector:@selector(appendString:)]);

  [pool release];
  return 0;
}
- - - - - - -

which gives this output on my OS X box:

> 2004-08-26 15:14:14.301 bla[12520]
> noTildePath: /usr/include (0x3068e0)
>           -> /usr/include (0x306d30)
> 2004-08-26 15:14:14.309 bla[12520]
> tildePath: ~mah/ (0x306c50)
>         -> /Network/Users/mah (0x309310)
> 2004-08-26 15:14:14.310 bla[12520]
> noTildeMutablePath: /usr/include (0x306c90, 1)
>                  -> /usr/include (0x309360, 0)
> 2004-08-26 15:14:14.310 bla[12520]
> tildeMutablePath: ~mah (0x306cb0, 1)
>                -> /Network/Users/mah (0x309530, 0)


One option whould be to file a bug at Apple 
<http://bugreport.apple.com/> against the behaviour. As some pointed 
out "returns the receiver" isn't a good idea in case of the receiver 
being a mutable String, however.

I think it whould be best to file a bug against Apple's 
_documentation_, then.


Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/