sadko4u wrote:tramp wrote:Only use reinterpret_cast if what you're doing really is changing the interpretation of some bits in the machine.
Sure, that's why I think that
reinterpret_cast is more usable to assume chunk of memory to be array of floats rather than
static_cast.
In general, you should always prefer static_cast for casts that should be safe. If you accidentally try doing a cast that isn't well-defined, then the compiler will report an error.
That's right and true for some objects with some hierarchy but not for low-level programming where each chunk of memory should be straightforward interpreted as some collection of objects of some data type.
sadko4u wrote:Here's some explanation:
Unlike static_cast, but like const_cast, the reinterpret_cast expression does not compile to any CPU instructions. It is purely a compiler directive which instructs the compiler to treat the sequence of bits (object representation) of expression as if it had the type new_type.
Well, let's check this explanation:
Let's take a little, basic test program:
Code: Select all
int main()
{
float buf[10] = {1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0};
float f = 0;
float *ptr = static_cast<float*>(buf);
//float *ptr = reinterpret_cast<float*>(buf);
for (int i = 0; i<10; ++i) {
f = ptr[i] ;
}
return 0;
}
and let's build verbose assembler code from it:
Code: Select all
c++ -S -fverbose-asm -g -O2 cast_test.cpp -o static_cast_test.s
now comment out the static_cast, UN-commend the reinterpret_cast and build the assembly:
Code: Select all
c++ -S -fverbose-asm -g -O2 cast_test.cpp -o reinterpret_cast_test.s
Now, let's check the diff:
Code: Select all
diff -Nur static_cast_test.s reinterpret_cast_test.s
turns out:
Code: Select all
--- static_cast_test.s 2016-12-04 04:33:06.850996404 +0100
+++ reinterpret_cast_test.s 2016-12-04 04:33:34.378996375 +0100
@@ -3,8 +3,8 @@
# compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p3, MPC version 1.0.2
# GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
# options passed: -imultiarch x86_64-linux-gnu -D_GNU_SOURCE cast_test.cpp
-# -mtune=generic -march=x86-64 -auxbase-strip static_cast_test.s -g -O2
-# -fverbose-asm
+# -mtune=generic -march=x86-64 -auxbase-strip reinterpret_cast_test.s -g
+# -O2 -fverbose-asm
# options enabled: -faggressive-loop-optimizations
# -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg
# -fcaller-saves -fcombine-stack-adjustments -fcommon -fcompare-elim
As you can see, the only difference here is the name of the file produced, as we produce verbose assembler code. Lets check the same again with plain assembler.
Code: Select all
c++ -S cast_test.cpp -o static_cast_test.s
switch comment and
Code: Select all
c++ -S cast_test.cpp -o reinterpret_cast_test.s
do the diff
Code: Select all
diff -Nur static_cast_test.s reinterpret_cast_test.s
outputs:
Conclusion , the only "advantage" you've when using reinterpret_cast in this case, is, ta, ta,tata, right, you've turn of the compiler type check, there is no difference in runtime behave. As the static_cast is, same as the reinterpret_cast, a pure compiler directive.
The using of a reinterpret_cast on a foreign function call, is in general no good idea, as you cant grant the result for the future.
On the road again.