iOS unexpected behavior array

[grandM]

Hi, I think I'm stumbling with my objective-c knowledge causing me some problems. I solved it already but I would like to know why it went wrong

   func deleteGalleryItem(galleryItem: GalleryItem) {


        self.galleryItemsArray.removeAtIndex(galleryItem.indexInTheArray)


        for index in galleryItem.indexInTheArray..<self.count() {

            var item = self.itemAtIndex(index)! asGalleryItem

            item.indexInTheArray = index
            self.galleryItemsArray[index] = item

        }


    }

In my original code I did not have the line

self.galleryItemsArray[index] = item

. After a lot of cursing I found out that the galleryItems in the array weren't replaced with the new values. Is this because of swift? I seem to remember that in objective-c the elements were pointers hence the last line wasn't needed?

 

[grandM]

I think I found it. GalleryItem was defined as a Structure. Structures are passed by value. Consequently I could not change the value of a GalleryItem as a copy was made, and not a reference. Changing GalleryItem to a class solved it too.

self.galleryItemsArray.removeAtIndex(galleryItem.indexInTheArray)
for index in galleryItem.indexInTheArray..<self.count() {

            self.itemAtIndex(index)!.indexInTheArray = index
}

The only question remaining is what is better : a struct or a class performance wise?

 

[Mascots]

I think I found it. GalleryItem was defined as a Structure. Structures are passed by value. Consequently I could not change the value of a GalleryItem as a copy was made, and not a reference. Changing GalleryItem to a class solved it too.

self.galleryItemsArray.removeAtIndex(galleryItem.indexInTheArray)
for index in galleryItem.indexInTheArray..<self.count() {

            self.itemAtIndex(index)!.indexInTheArray = index
}

The only question remaining is what is better : a struct or a class performance wise?

Well, the side effect you experienced is one of the reasons I use a struct for portable data or advanced option sets - sometimes there's no need to keep a single object but instead pass around mutated objects. It also simplifies memory usage in that effect. The performance is really just based on how you use each type.

You also lose other things, like inheritance, with structs to make up for the way they function. I'd check this out.

 

[grandM]

Well, the side effect you experienced is one of the reasons I use a struct for portable data or advanced option sets - sometimes there's no need to keep a single object but instead pass around mutated objects. It also simplifies memory usage in that effect. The performance is really just based on how you use each type.

You also lose other things, like inheritance, with structs to make up for the way they function. I'd check this out.

Is not memory usage better with Classes?

 

[AxoNeuron]

Whether structs or arrays are faster is really dependent on how you are using them, your compiler, etc. at least in C++. I've never done any testing of this question in Swift.

 

[grandM]

Whether structs or arrays are faster is really dependent on how you are using them, your compiler, etc. at least in C++. I've never done any testing of this question in Swift.

I'm getting the impression classes react faster.

 

[AxoNeuron]

I'm getting the impression classes react faster.

In most languages classes are just implemented as structs so they should be pretty much identical.

 

[Mascots]

Is not memory usage better with Classes?

It depends, sometimes a small short duplicated struct set is smaller (and faster) than initiating an entire class and passing around references. If you have an identical object as a struct and class, the struct will be the one that generally performs better because it lacks class attributes. However, if you start passing that struct around, it would consume more memory than the original class did, and instead of adding references to a single bite of memory, you could potentially be duplicating the memory of struct hazardously.

That also means that changes you make on new structs won't be reflected in the older versions, while a class's changes would be since you're simply passing around pointer to that one set of data.

Basically, it's not an "either or", it's a "what do you need to happen". If all else fails, I would suggest using a class since the performance hit between the two is minimal, especially if you're using a class for data that could be better suited for a struct rather than the inverse which can cause problems (as you saw).