It works in debug.

It also works in release, EXCEPT when full program optimization is enabled.

It is supposed to render chunks of tiles (theres a grid of them. The grid can be resized, causing them to be reallocated and some of the old ones assigned to the corresponding new ones in the newly allocated grid)

Now, when the full program optimization is on, the program compiles and works, but some of the chunks have messed up texcoords / vertex positions (there usually seems to be a pattern. Eg. all the texture coords in a chunk are offset or each tile misses the other triangle of the quad. usually the whole chunk is missing, and if there is a pattern its usually not the whole chunk, part of it is missing.)

I suspect this might have something to do with my questionable way of implementing assignment/copy construction.

I get the following warnings (level 4):

warning C4239: nonstandard extension used : 'argument' : conversion from 'a::b::blah' to 'a::b::blah &'

warning C4512: 'a::b::bleh' : assignment operator could not be generated

Basically i have a bunch of classes that contain resources of some kind (handles to opengl stuff, indices to pools...)

And since i want to move these objects from the old grid to the resized new grid, i do something like A=B (or A=T() for other stuff)

The resources are destroyed in the destructor generally, so to prevent that i do:

Class(Class& other)
{
*this=other;
}

operator=(Class& other)
{
swap(m_that, other.m_that)
return *this;
}
 

Can this cause such behaviour (is it undefined behaviour to modify the argument to operator= or copy constructor?) when full program optimization is on (MSVC++ 2010, building 32 bit)?

Any other possible reasons for such behaviour i should check?

Is the way i move resources upon assignment from one object to another undefined behaviour and is there a more correct way to do this (I asked about this some time ago, i believe i could do this with move semantics somehow, but this seemed to work too so i didnt care)?

Things i tried:

-Throw some #pragma pack(1) around to make sure the arrays of structs i pass to opengl arent messed up (i did change the calculation of stride so it shouldnt break even if there was/is padding)

-Tried stepping through the highly optimized release build. My window object was ok before passing a reference to a function and after it was full of garbage. Not sure if it was actually full of garbage or if i shouldnt step through optimized code xP

-Tried googling

-Tried getting rid of the warnings about not being able to generate assignment operators (i had a reference member in a bunch of classes, changed to pointers)

-Some other i cannot remember probably

thanks

edit: attached png of what it looks like (screen should be full of tiles)

edit: solved, adding move ctor and assignment operators and doing all moving of resources with std::move fixed it.

But if i take it by const reference, how do i prevent the original object from deleting the resource upon destruction?

But if i take it by const reference, how do i prevent the original object from deleting the resource upon destruction?

By using a shared_ptr to that resource.

It might be good if you would show some more of your code for some more specific help. Also make sure you know about, or learn, the rule of three. And for bonus points, this site has an excellent selection of articles about the nuances of C++: http://www.gotw.ca/gotw/

Moved all of my resource owning classes to use move semantics, prevented use of copy ctor and assignment operators (should probably implement those so they actually copy the resource for the few classes where it makes sense...) and used a lot of std::move, and it finally works properly with whole program optimization too.