Jump to content
  • Advertisement
Sign in to follow this  
Anton Vatchenko

Fast C++ casting

This topic is 2863 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a pointer to some data that has type void*. Is there a fast way of casting this pointer to some type? Because if I try:

void* ptr;
...
SomeType* t = (SomeType*) ptr;
or
SomeType* t = static_cast<SomeType*>(ptr);

I get 2 instructions:

mov eax,dword ptr [...]
mov dword ptr [...],eax

Can it be optimized somehow that instructions of:

void someFunction(SomeType* t)
{
t->someOperation();
}

and something like:

void someFunction(void* v)
{
SomeType* t = (SomeType*) v;
t->someOperation();
}

were the same, because I created local variable just for calling someOperation.

Share this post


Link to post
Share on other sites
Advertisement
Something like this will avoid the creation of a temporary variable

void someFunction(void* v)
{
((SomeType*) v)->someOperation();
}
[\source]

Share this post


Link to post
Share on other sites
Quote:
Original post by Anton VatchenkoCan it be optimized somehow that instructions of:

void someFunction(SomeType* t)
{
t->someOperation();
}

and something like:

void someFunction(void* v)
{
SomeType* t = (SomeType*) v;
t->someOperation();
}


Don't those two functions produce the exact same code when all optimization options of your compiler are enabled?

You shouldn't really worry about stuff like this in my opinion. I'd say it's much more important to avoid stuff like casting void pointers to anything :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Anton Vatchenko
I have a pointer to some data that has type void*. Is there a fast way of casting this pointer to some type? Because if I try:

void* ptr;
...
SomeType* t = (SomeType*) ptr;
or
SomeType* t = static_cast<SomeType*>(ptr);

I get 2 instructions:

mov eax,dword ptr [...]
mov dword ptr [...],eax


Assembly and CPU do not have types. The above is part of something else, most likely a dereference of 'this' or t pointer - types do not exist in binary, nor do casts as such. The only exception is the load (and related) instructions which determine the size of data to load (operate on) in register, such as byte, word, dword and floating point operations, which must use alternate subset of operations.

What is the value of [...]? Is it the same? Then it's artifact of debug build which will not exist in release version.

And besides, the cost of OO comes from chasing pointers, not individual instructions.

Quote:
Something like this will avoid the creation of a temporary variable

For release builds, this type of optimization is completely and entirely wasted. Ever since register keyword was abandoned, compilers use graph theory and obscure mathematical techniques to find optimal arrangements of local variables. In short, C++ source code is almost completely unrelated to generated assembly in everything but the visible side effects.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
For release builds, this type of optimization is completely and entirely wasted. Ever since register keyword was abandoned, compilers use graph theory and obscure mathematical techniques to find optimal arrangements of local variables. In short, C++ source code is almost completely unrelated to generated assembly in everything but the visible side effects.


Furthermore, there are actually a vast multitude of cases (mostly involving pointers, incidentally) where creating a temporary variable is actually the more performant choice-- see the 'restrict' keyword and related.

Share this post


Link to post
Share on other sites
Talk about micro optimization!
If your what your doing is running slowly, it's probably not because of this code.
I would have to agree that you will get similar results with a good optimizing compiler.

Share this post


Link to post
Share on other sites
If performance is this important to you, it is much, much more important to first examine why there are these void*'s floating around in the first place. Why are you making life difficult for the compiler?

Also, everything Antheus said.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!