Something like this will avoid the creation of a temporary variable

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 :)

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;orSomeType* 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.

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.

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.