views:

178

answers:

3

Just curious if this is the way to do this, just want to make sure its not leaking, although I would think I am only modifying the string contents.

NSMutableString *newPath = [[NSMutableString alloc] init];

for(fileName in [manager enumeratorAtPath:rootPath]){
    if ([[fileName pathExtension] isEqual:@"exr"]) {
        [fileArray addObject:fileName];

        // THIS BIT 
        [newPath setString:rootPath];
        [newPath appendString:@"/"];
        [newPath appendString:fileName];
        // HERE
        attrDir = [manager attributesOfItemAtPath:newPath error:&myError];

        fileSize = [attrDir objectForKey: @"NSFileSize"];
        NSLog(@"File: /%@ Size: %@", fileName, fileSize);
    }
}
[newPath release];

gary

+7  A: 

This looks fine leak-wise. If you're running Xcode 3.2 you can Build->Build & Analyzer to get Clang to check this sort of thing.

Remember you only have to release things you alloc, new, copy or retain.

Consider using stringByAppendingPathComponent, rather than hardcoding the @"/" path separator. NSString has a number of methods like this specifically for working with paths.

NSString* fullPath = [rootPath stringByAppendingPathComponent:fileName];
nall
Hmm I tried adding [newPath stringByAppendingPathComponent:@"/"]; to test adding a "/" to the end, but I can't seem to get it working ...
fuzzygoat
stringByAppendingPathComponent avoids you having to know about the delimiter. I've updated the answer to reflect the usage.
nall
thank you, so how does it know what to add?
fuzzygoat
which delimiter to add? that's operating system dependent. which path component to add? you'd have to supply that. it's whatever would go "after" the path delimiter.
nall
go it, thank you
fuzzygoat
+1  A: 

There's nothing wrong with it, although it could be better to use initWithFormat and release:

NSString *newPath = [[NSString alloc] initWithFormat:@"%@/%@",rootPath,fileName];

// do your thing

[newPath release];
Philippe Leybaert
Not mentioned but important: That would go inside the loop.
Chuck
Thank you, coming from procedural programming I am always a little cautious of declaring variables on demand (i.e. not at the start of a block) I guess I just need to be a little more flexible with a more open view with regards to Objective-C
fuzzygoat
In fact, there are very good reasons for declaring variables in the most enclosing scope possible (i.e. closest to where they are used).
nall
You really should use the path specific methods on `NSString` to work with paths. Otherwise you can get into trouble if directories have, or do not have, trailing `'/'`, and some other corner cases. Look at the documentation for `NSString` and the methods under the _"Working With Paths"_ task group. As a bonus you get to write less code.
PeyloW
+1  A: 

There is absolutely nothing wrong with your code, it is correct memory management.

But it can be done with even less code and memory management needed:

for(fileName in [manager enumeratorAtPath:rootPath]){
  if ([[fileName pathExtension] isEqualToString:@"exr"]) {
    [fileArray addObject:fileName];

    NSString* newPath = [rootPath stringByAppendingPathComponent:fileName];
    attrDir = [manager attributesOfItemAtPath:newPath error:&myError];

    fileSize = [attrDir objectForKey: @"NSFileSize"];
    NSLog(@"File: /%@ Size: %@", fileName, fileSize);
  }
}
PeyloW
Thank you, much appreciated.
fuzzygoat