This feels like a dumb question because it seems to me like my use case must be quite common.
Say I want to represent a sparse set of indexes with an NSIndexSet (which is of course what it's for). I can use -firstIndex to get the lowest one and -lastIndex for the highest, but what's the canonical way to get a single, arbitrary index in the middle, given its "index"? The docs have left me unclear.
E.g. if I have an index set with the indexes { 0, 5, 8, 10, 12, 28 }, and I want to say "give me the fourth index" and I'd expect to get back 10 (or 12 I suppose depending on whether I count the zeroth, but let's not get into that, you know what I mean).
Note that I'm not doing "enumeration" across the whole index set. At a given point in time I just want to know what the nth index in the set is by numerical order.
Maybe my data structure is wrong ("set"s aren't usually designed for such ordered access), but there seems to be no NSIndexArray to speak of.
Am I missing something obvious?
Thanks!
NSIndexSet isn't designed for that sort of access. Usually, you enumerate through the indexes in a set like so:
NSUInteger idx = [theSet indexGreaterThanOrEqualToIndex: 0];
while (idx != NSNotFound) {
// idx equals the next index in the set.
idx = [theSet indexGreaterThanIndex: idx];
}
#Richard points out this for loop is simpler:
for (NSUInteger i = [indexSet firstIndex]; i != NSNotFound; i = [indexSet indexGreaterThanIndex:i]) {
// i equals the next index in the set.
}
There's some block-based methods that are new to NSIndexSet as of Mac OS X 10.6/iOS 4.0, but I haven't reviewed them as of yet.
It should be trivial to modify the above example to keep a running count of indexes and stop when it reaches the fourth index in the set. ;)
I believe NSIndexSet stores its indexes using ranges, so there isn't necessarily a quick way to return the nth index. You could enumerate keeping a counter until your counter reaches your target index:
NSUInteger index = [indexSet firstIndex];
for (NSUInteger i = 0, target = 4; i < target; i++)
index = [indexSet indexGreaterThanIndex:index];
That should give you the 4th index. You could even add the method as a category method if you want:
- (NSUInteger)indexAtIndex:(NSUInteger)anIndex
{
if (anIndex >= [self count])
return NSNotFound;
NSUInteger index = [indexSet firstIndex];
for (NSUInteger i = 0; i < anIndex; i++)
index = [self indexGreaterThanIndex:index];
return index;
}
But, as you said, this may not be the best data structure to use so do consider that more before going with something like this.
Say I want to represent a sparse set of indexes with an NSIndexSet (which is of course what it's for).
[my emphasis]
Actually, no it's not. The documentation says this:
You should not use index sets to store an arbitrary collection of integer values because index sets store indexes as sorted ranges.
So if you are using it to store a sparse array of integers, it is quite inefficient. Also, the only way to get the nth index is to iterate from one end. You'd be better off using an array.
One more decision:
- (NSUInteger)indexAtIndex:(NSUInteger)index {
__block NSUInteger result = NSNotFound;
__block NSUInteger aCounter = 0;
[self enumerateIndexesUsingBlock:^(NSUInteger idx, BOOL * _Nonnull stop) {
if (aCounter == index) {
result = idx;
*stop = YES;
} else {
aCounter++;
}
}];
return result;
}
Related
I have an array in an old objective-C app that I am using to learn more "complicated" coding. It is back from the old days of OS X and was very much broken. I have gotten it to work (mostly)! However, the app has an NSMutableArray of images, 7 in total. I use a random number generator to insert the images on the screen, some code to allow them to fall, and then, using screen bounds, when they reach "0" on the Y axis they are removed from the array.
I initially just had:
if( currentFrame.origin.y+currentFrame.size.height <= 0 )
{
[flakesArray removeObject:myItem];
I have read when removing objects from an array it is best practice to iterate in reverse...so I have this bit of code:
for (NSInteger i = myArray.count - 1; i >= 0; i--)
{ //added for for statement
if( currentFrame.origin.y+currentFrame.size.height <= 0 )
{
[myArray removeObjectAtIndex:i];
}
Sadly both methods result in the same mutated while enumerated error. Am I missing something obvious?
If I add an NSLog statement I can get, I think, the index of the item that needs to be removed:
NSLog (#"Shazam! %ld", (long)i);
2017-01-07 14:39:42.086667 MyApp[45995:7500033] Shazam! 2
I have looked through a lot and tried several different methods including this one, which looks to be the most popular with the same error.
Thank you in advance! I will happily provide any additional information!
Adding more:
Sorry guys I am not explicitly calling NSFastEnumeration but I have this:
- (void) drawRectCocoa:(NSRect)rect
{
NSEnumerator* flakesEnum = [flakesArray objectEnumerator];
then
for( i = 0; i < numberToCreate; i++ )
{
[self newObject:self];
}
while( oneFlake = [flakesEnum nextObject] )
It is here where:
if( currentFrame.origin.y+currentFrame.size.height <= 0 )
{
NSLog (#"Shazam! %i", oneFlake);
[flakesArray removeObject:oneFlake];
}
Thank you all. I am learning a lot from this discussion!
There are two ways to go: (1) collect the objects to remove then remove them with removeObjectsInArray:.
NSMutableArray *removeThese = [NSMutableArray array];
for (id item in myArray) {
if (/* item satisfies some condition for removal */) {
[removeThese addObject:item];
}
}
// the following (and any other method that mutates the array) must be done
// *outside of* the loop that enumerates the array
[myArray removeObjectsInArray:removeThese];
Alternatively, reverseObjectEnumeration is tolerant of removes during iteration...
for (id item in [myArray reverseObjectEnumerator]) {
if (/* item satisfies some condition for removal */) {
[myArray removeObject: item];
}
}
As per the error, you may not mutate any NSMutableArray (or any NSMutable... collection) while it is being enumerated as part of any fast enumeration loop (for (... in ...) { ... }).
#danh's answer works as well, but involves allocating a new array of elements. There are two simpler and more efficient ways to filter an array:
[array filterUsingPredicate:[NSPredicate predicateWithBlock:^(id element, NSDictionary<NSString *,id> *bindings) {
// if element should stay, return YES; if it should be removed, return NO
}];
or
NSMutableIndexSet *indicesToRemove = [NSMutableIndexSet new];
for (NSUInteger i = 0; i < array.count; i += 1) {
if (/* array[i] should be removed */) {
[indicesToRemove addIndex:i];
}
}
[array removeObjectsAtIndexes:indicesToRemove];
filterUsingPredicate: will likely be slightly faster (since it uses fast enumeration itself), but depending on the specific application, removeObjectsAtIndexes: may be more flexible.
No matter what, if you're using your array inside a fast enumeration loop, you will have to perform the modification outside of the loop. You can use filterUsingPredicate: to replace the loop altogether, or you can keep the loop and keep track of the indices of the elements you want to remove for later.
I want to get the index of the current object when using fast enumeration, i.e.
for (MyClass *entry in savedArray) {
// What is the index of |entry| in |savedArray|?
}
Look at the API for NSArray and you will see the method
- (void)enumerateObjectsUsingBlock:(void (^)(id obj, NSUInteger idx, BOOL *stop))block
So give that one a try
[savedArray enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
//... Do your usual stuff here
obj // This is the current object
idx // This is the index of the current object
stop // Set this to true if you want to stop
}];
I suppose the most blunt solution to this would be to simply increment an index manually.
NSUInteger indexInSavedArray = 0;
for (MyClass *entry in savedArray) {
indexInSavedArray++;
}
Alternatively, you could just not use fast enumeration.
for (NSUInteger indexInSavedArray = 0; indexInSavedArray < savedArray.count; indexInSavedArray++) {
[savedArray objectAtIndex:indexInSavedArray];
}
This question has already been answered, but I thought I would add that counting iterations is actually the technique mentioned in the iOS Developer Library documentation:
NSArray *array = <#Get an array#>;
NSUInteger index = 0;
for (id element in array) {
NSLog(#"Element at index %u is: %#", index, element);
index++;
}
I was sure there would be a fancy trick, but I guess not. :)
If you want to access the index or return outside block here is a piece of code that can be useful. (considering the array is an array of NSString).
- (NSInteger) findElemenent:(NSString *)key inArray:(NSArray *)array
{
__block NSInteger index = -1;
[array enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
if ([obj isEqualToString:key]) {
*stop = YES;
index = idx;
}
}];
return index;
}
A simple observation: If you initialize the index to -1 and then put the ++index as the first line in the for loop, doesn't that cover all bases (provided someone doesn't slip code in front of the increment)?
I just had a pretty bad bug because I was doing this the way everyone else in here has suggested. That is, "create an index variable and increment it at the end of your loop".
I propose that this should be avoided and instead the following pattern should be followed:
int index = -1;
for (a in b) {
index++;
//Do stuff with `a`
}
The reason I recommend this odd pattern, is because if you use the continue; feature of fast enumeration, it will skip the final index++ line of code at the end of your loop, and your index count will be off! For this reason I recommend starting at -1 and incrementing before doing anything else.
As for people who said just use indexOfObject: this won't work with duplicate entries.
I have two arrays, each containing strings. The first array is a list of words, the second array contains alternatives to those words in different languages.
The arrays are matched such that the word at index n in the second array is a translation of the word at index n in the first array.
The words and their translations are displayed in a table view. The user can filter the table view by entering text in a search field. When this is done, I create a filtered array from the first array like this:
- (void)filterContentForSearchText:(NSString*)searchText
[self.filteredarray removeAllObjects];
[firstarray enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop)
{
if ([obj compare:searchText options:NSCaseInsensitiveSearch range:NSMakeRange(0, [searchText length])] == NSOrderedSame)
{
idx= [firstarray indexOfObjectIdenticalTo:obj];
NSUInteger maxindex = idx + 50;
for (idx ; (idx < [firstarray count] && idx <= maxindex && idx!= NSNotFound); idx ++)
{
[self.filteredarray addObject:[firstarray objectAtIndex: idx]];
}
*stop = YES;
}
}];
Then, when I am displaying the values in my table view, I use the following code. This is an exerpt from my cellForRowAtIndexPath method. I am trying to get the index from the original array using the object that has been added to the filtered array.
contentForThisRow = [self.filteredarray objectAtIndex:row];
NSUInteger index = [self.firstarray indexOfObjectIdenticalTo:contentForThisRow];
contentForThisRow2 = [self.secondarray objectAtIndex:index];
This works on the simulator, but on the device I will sometimes get repeats of the same entry from the second array. For example, my first array contains the word "hello" three consecutive times, at indexes x, y and z. My second array contains "hei", "heisan" and "hoppsan", which are all translations of "hello", at indexes x, y and z.
On the simulator, I get three cells, each with a different translation. On the device, I get three cells, all with "hei", the first translation. This does not happen for all repeated translations.
Why is this happening, and how can I get around it?
I think the problem is that iOS (on the device) may be using a slightly different optimisation to the emulator somewhere, either in NSString or NSArray. That is a guess.
indexOfObjectIdenticalTo: returns the index of the first object that has the same memory address as the object you are passing in. On the phone it appears to have re-used the identical string objects in your first array when building the filtered array (possibly even when building firstArray), so you are getting the same index value back each time.
A better solution would be to build your filtered array as an array of dictionaries, storing the values from the correct indexes of firstArray and secondArray at that point. You can then use these values directly when populating the cell instead of searching through both arrays again. This should also have some performance benefits.
You would achieve this using the following code. First, inside your loop when you are building the filtered array, instead of adding the object from firstarray, do this:
[self.filteredArray addObject:[NSDictionary dictionaryWithObjectsAndKeys:[firstarray objectAtIndex:idx],#"english",[secondarray objectAtIndex:idx],#"translated",nil];
Then, in your cellForRowAtIndexPath, to get your two content variables:
NSDictionary *rowData = [self.filteredarray objectAtIndex:row];
contentForThisRow = [rowData objectForKey:#"english"];
contentForThisRow2 = [rowData objectForKey:#"translated"];
An even better solution would be to hold your data like this in the first place, and not try to keep two separate arrays synchronised. I imagine if you want to add or alter anything in your two separate files you could quickly get them out of step. However, I feel I've done enough for the day...
else
contentForThisRow = [self.firstarray objectAtIndex:row];
contentForThisRow2 = [self.secondarray objectAtIndex:row];
You see anything wrong with that?
I have an array (let's call it indexArray) of indexes into another array (called sequence). I want to scan the original array, sequence, to see if the values at these indexes are duplicates. For example, if there is a value equal to sequence[indexarray[(value at index 1)]] in sequence, then I want to delete the index value from indexArray. At the end, I will have an array with only the indexes whose values are not repeated.
One way to approach it would be this:
NSCountedSet *countedSet = [NSCountedSet setWithArray:sequence];
for (NSNumber *index in indexarray) {
id object = [sequence objectAtIndex:[index integerValue]];
NSUInteger objectCount = [countedSet countForObject:object];
if (objectCount > 1) {
NSLog("%# is duplicate", object);
}
}
Performance: Compared to checking each object for duplicates manually, which has an operation time of about O(n*m), (with n, m being the arrays' sizes.) the use of an NSCountedSet brings it down to an operation time of about O(n+m).
I have an NSMutableArray with contents I want to replace with NSNull objects.
This is what I do:
NSMutableArray* nulls = [NSMutableArray array];
for (NSInteger i = 0; i < myIndexes.count; i++)
[nulls addObject:[NSNull null]];
[stageMap replaceObjectsAtIndexes:myIndexes withObjects:nulls];
How can I do this more efficiently?
Is there a way to enumerate an NSIndexSet, so I can replace the array content one by one?
Solved
Suggested method turns out to be 2x faster (avg 0.000565s vs 0.001210s):
if (myIndex.count > 0)
{
NSInteger index = [myIndex firstIndex];
for (NSInteger i = 0; i < myIndex.count; i++)
{
[stageMap replaceObjectAtIndex:index withObject:[NSNull null]];
index = [myIndex indexGreaterThanIndex:index];
}
}
You can use a for loop. Start with the first index, use indexGreaterThanIndex: to get the next index, and stop after you hit the last index.
Don't forget to account for an empty index set. Both the first and last index will be NSNotFound in that case. The easiest way is to test the index set's count; if it's zero, don't loop.
Also, what Jason Coco said about profiling. Don't worry too much about efficiency until your program works, and don't go optimizing things until you have run Shark (or Instruments, if that's your thing) and found exactly what is slow.
I realise this is a very old question but I'm posting here in case anyone else finds this question you could use:
[indexes enumerateIndexesUsingBlock:^(NSUInteger idx, BOOL *stop) {
NSLog(#"index: %d", idx);
[objectArray replaceObjectAtIndex:idx
withObject:newObject];
}];
Which is a lot more succinct.