Share this post

Link to post

Share on other sites

You're telling the function you're calling that your pointer points to memory that has enough room to store a double, but the actual memory is only big enough for a float.

Getting zero back is the least of what could go wrong - you are corrupting the stack. The additional 32 bits of the double are being written to whatever comes after the space reserved for your float. Most likely problem is that you'll overwrite a different local variable in your function, but you could also overwrite the saved frame pointer or return address.

On x64, RBP and the return address are 64-bit and you'll overwrite half of them with part of your double.On x86, EBP and the return address are 32-bit and you'll completely overwrite them with the second half of y.

In your calling function, your local variables that you take the address of must be doubles. You can cast them to float *after* you get them back.

If your function has other local variables besides just x and y, they will be somewhere on the stack as well, and could be getting overwritten instead of rBP/retAddr.

(edited like 50 times: ASCII art is a pain)
Edited March 17, 2016 by Nypyren

Share this post

Link to post

Share on other sites

You're telling the function you're calling that your pointer points to memory that has enough room to store a double, but the actual memory is only big enough for a float.

Getting zero back is the least of what could go wrong - you are corrupting the stack. The additional 32 bits of the double are being written to whatever comes after the space reserved for your float. Most likely problem is that you'll overwrite a different local variable in your function, but you could also overwrite the saved frame pointer or return address.

On x64, RBP and the return address are 64-bit and you'll overwrite half of them with part of your double.
On x86, EBP and the return address are 32-bit and you'll completely overwrite them with the second half of y.

In your calling function, your local variables that you take the address of must be doubles. You can cast them to float *after* you get them back.

(edited like 50 times: ASCII art is a pain)

hahaha :D Nice ASCII art skills

Awesome explanation. thank you !

That sucks. I was hoping there would be a way to directly cast them to float without having to create a new double variable then cast it to a float. ooh well.

Speaking of double and float. float is still faster than double on the CPU correct? Having my Vector2 class be a double rather than a float would slow performance down. Is that still the case in 2016?

Edited March 17, 2016 by FantasyVII

0

Share this post

Link to post

Share on other sites

Having my Vector2 class be a double rather than a float would slow performance down. Is that still the case in 2016?

I'm not sure if this is the case but is there a reason you need them to be doubles? That's fairly overkill. You could also consider making your Vector class to be a template class and then you can use either doubles or floats as needed.

2

Share this post

Link to post

Share on other sites

Having my Vector2 class be a double rather than a float would slow performance down. Is that still the case in 2016?

I'm not sure if this is the case but is there a reason you need them to be doubles? That's fairly overkill. You could also consider making your Vector class to be a template class and then you can use either doubles or floats as needed.

I agree, I feel double is overkill. That why I'm trying to cast it to float. GLFW library only gives double. I don't have a choice in the matter.

Share this post

Link to post

Share on other sites

The most significant performance hit for using doubles will probably come from the CPU cache misses and memory bandwidth caused by them taking up twice as much memory.

In addition SSE instructions can handle four floats at a time, but only two doubles at a time. So for code which uses them the performance hit can be significant.

For basic operations on values in registers, floats aren't significantly faster than doubles. For some more complex operations (like division) doubles will be slower than floats, as they have more precision, but overall you probably won't notice much difference.

Share this post

Link to post

Share on other sites

The most significant performance hit for using doubles will probably come from the CPU cache misses and memory bandwidth caused by them taking up twice as much memory.

In addition SSE instructions can handle four floats at a time, but only two doubles at a time. So for code which uses them the performance hit can be significant.

For basic operations on values in registers, floats aren't significantly faster than doubles. For some more complex operations (like division) doubles will be slower than floats, as they have more precision, but overall you probably won't notice much difference.