@Krangogram :) Yeah, just that if I say "I'll check that tomorrow" and I can't I prefer to announce it rather than just hope the other forgets about it :P
And I'll confirm what Tyyppi_77 said. By using objects like that (without the proper handling of copy and move), you're messing up the references your user data is using.
As a side note, this line is causing a memory leak.
6 hours later…
user92578
8:36 AM
@Krangogram I would kindly suggest digging up some writeups or tutorials about C++'s value semantics, moves, copies, std::vector etc. to understand what is happening, why its happening, and how to properly fix it and how to avoid the issues in the future
I've got it working using unique_ptr now for the Blocks vector. And I removed my declaration of the move constructor. Right now it works, but no im second-guessing where else I should use the unique_ptr. For now I am just doing it in all my vectors that are collections of pointers... (I won't waste any more of your time asking about this issue. Just giving a final update here ) .....Ooh what fun!! :D
user92578
Basically using unique_ptr avoids the issue of complex memory ownership
user92578
So you don't have to implement move or copy constructors
user92578
You can also just use std::vector<Block>, but then you need a correctly implemented move constructor
user92578
A good rule of thumb is that you should never ever need to use new
user92578
The bad side of using std::vector<std::unique_ptr<T>> is that you lose cache efficiency since the memory allocated isn't continuous, so proper move semantics is a better option
yeah, gotta balance the risk of messing up the move semantics and the benefit of having cache efficiency. Depending on the size of the vector this may or may not be relevant.
@Krangogram also, I don't think you're wasting anyone's time. Those who help here are volunteering their time because they like to help.
