• Create Account

#ActualWaterlimon

Posted 10 February 2013 - 09:45 AM

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.

#3Waterlimon

Posted 09 February 2013 - 12:32 PM

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)

#2Waterlimon

Posted 09 February 2013 - 12:19 PM

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

#1Waterlimon

Posted 09 February 2013 - 12:04 PM

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

PARTNERS