Your are calling the base constructor from the constructor of the derived class, which is actually the right way to initialize base class members through a derived class. But where do you pass the arguments? Your derived class constructor has empty parantheses…
Here’s some useful info:
vector<ofImage*> &imageRef = *imagesSection;
imageRef[currentIndex]->drawSubsection(x, y, w, h, x, y);
you could simply write:
(*imagesSection)[currentIndex]->drawSubsection(x, y, w, h, x, y);
I wasn’t expecting to declare a lot of the stuff again. So all in all I haven’t really saved much code than if they had been separate classes for this particular use but now I can add on some other things to my derived class.
Hi jvcleave, as it is explained in the Stack Overflow thread, this happens rather because of a peculiarity of c_str() and how it is implemented in libc++ as opposed to libstdc++. Generally you shouldn’t use the result of c_str() after the belonging string object was modified in some way.
See also: http://www.cplusplus.com/reference/string/string/c_str/
Note that there is a big difference between
a) pointers (or references or iterators) to members of a vector,
b) pointers that are vector members
c) pointers inside a vector member which point to something outside the vector
d) pointers inside a vector member which point to dynamically allocated memory inside the member.
a) will definitely get invalidated after a reallocation of the vector, since all the members are moved (or copied) to a new place in memory, changing their addresses.
b) will never be affected by reallocation, because the pointer is always copied, therefore keeping its content and still pointing to the same object.
c) same as b)
d) they will be invalidated by reallocation if the member is copied, because a properly written copy constructor will perform ‘deep copies’ on arrays, meaning that a new array is dynamically allocated (new address!) and the content is copied from the source array. Since the array has now a new location, all previous pointers to it are now invalid!
If the member is moved, however, everything is still valid, because a proper move constructor will copy only the pointer from the source and and then setting the source’s pointer to NULL.
So objects as vector members are never affected by vector reallocation as long as they are moved. The problem is: the STL containers (like <vector>) only move members if their move constructors are noexcept! This is not the case for any openFrameworks containers like ofPixels or ofImage, as I’ve just noticed. I’ll post a new issue on github to discuss this further.
in that case what’s becoming invalidated is the first vector. the vector of objects, not the vector of pointers. you are getting addresses to objects in a vector and those pointers become invalid because the original objects move in memory. you’d have the same problem no matter which structure you use for the second vector.
the easiest solution is to completely fill the first vector first and only then start to fill the second.
deque can also move in memory, it doesn’ t happen so often but it’s not completely safe. list won’t invalidate it’s iterators when you add or even insert.
thanks @Christof and @arturo ( I’ve read your article a few times over the years )
My code wasn’t exactly like the StackOverflow link but it was all I could find that closely resembled it. I’ll try and dig mine up again.
It didn’t make much sense to me as I have used vectors of pointers forever but I had also never seen the Iterator invalidity paragraph either. Both pretty much scared me into looking for something else. It seems the biggest drawback of non-vector containers is that they typically don’t guarantee continuous memory. I was much better with that as opposed to having a pointer pulled out from under me