quote:Original post by sjelkjd
Ok then, so a question: which is better style?
int i=float(f);
or int i=static_cast<float>(f);
Mind if I add some more?
....
OR
int i = (float)f;
is the assembly output the same for all?
do you use static_cast or C-style cast?
Mind if I add some more?
....
OR
int i = (float)f;
is the assembly output the same for all?
My 2 cents -- of course you''re avoiding casts as frequently as possible - but where their essential and clutter up code you can just stick a macro definition in misc.h or something like that. ie:
//misc.h
#define RCAST(p) (reinterpret_cast)p
#define CCAST(p) (static_cast)p
#define BLCAST(p) (broken_leg_cast)p
//misc.h
#define RCAST(p) (reinterpret_cast)p
#define CCAST(p) (static_cast)p
#define BLCAST(p) (broken_leg_cast)p
Author
I have been thinking this over, and here is what I will do in the future.
I will use the new dynamic_cast, reinterpret_case and const_cast as recommended in the standard since they are rare and needs special attention (dynamic_cast even does something useful).
I will use the C-style case instead of static_cast. I think static_cast just messes up the code and makes it inconsistant with function-style casts and user defined conversions. And it won''t protect you anyway since the user cannot be prevented from using C-style casts.
If the C++ standard commiteee wants to get rid of C-style casts they should remove it completely - possibly only when a certain compiler option is given. The current state of affairs is not satisfying.
I will use the new dynamic_cast, reinterpret_case and const_cast as recommended in the standard since they are rare and needs special attention (dynamic_cast even does something useful).
I will use the C-style case instead of static_cast. I think static_cast just messes up the code and makes it inconsistant with function-style casts and user defined conversions. And it won''t protect you anyway since the user cannot be prevented from using C-style casts.
If the C++ standard commiteee wants to get rid of C-style casts they should remove it completely - possibly only when a certain compiler option is given. The current state of affairs is not satisfying.
Just an interesting note, here''s a little trick I learned to convert one pointer to another, without using c-style casts, or new-style casts:
Yah, it''s just a loophole in the language, and it''s probably not very tasteful, but interesting none the less.
// say we have a new thread, and we want to convert the LPVOID parm to a pointer to some class, say CFooDWORD WINAPI ThreadProc(LPVOID pContext){ union { LPVOID pVoid; CFoo* pFoo; } uCaster; uCaster.pVoid = pContext; // you can now make calls on uCaster.pFoo CFoo* pObj = uCaster.pFoo; pObj->SomeMethod(); // or just uCaster.pFoo->SomeMethod();} Yah, it''s just a loophole in the language, and it''s probably not very tasteful, but interesting none the less.
Another, equivalent hack would be to memcpy the pointers themselves(specifying 4 bytes for length if you''re on a 32 bit architecture).
WHat is the advantage over simply casting it, though?
____________________________________________________________
Direct3D vs. OpenGL
WHat is the advantage over simply casting it, though?
____________________________________________________________
Direct3D vs. OpenGL
I just found out something interesting...
doesn''t compile on g++, and I never knew why. So I was reading Effective STL and it turns out that my statement gets parsed as a function call. So something like this:
gets parsed as a declaration for a function i, that takes an int and returns an int.
Just another point for the *_cast form of things.
vector<int> v(istream_iterator<int>(cin),istream_iterator<int>()); int i(int(f)); gets parsed as a declaration for a function i, that takes an int and returns an int.
Just another point for the *_cast form of things.
quote:Original post by Promit
WHat is the advantage over simply casting it, though?
Obvious: casting wouldn''t be nearly so silly.
In C++ the following is legal:
float* fp;
fp = new float(2);
on the second line a constructor is being called, there are no casts. I assume the same is true for the following:
float f;
f = float(2);
thus what looks like a functional style cast is instead a constructor. Technically, functional-style casts are not part of the C++ language.
float* fp;
fp = new float(2);
on the second line a constructor is being called, there are no casts. I assume the same is true for the following:
float f;
f = float(2);
thus what looks like a functional style cast is instead a constructor. Technically, functional-style casts are not part of the C++ language.
quote:Original post by Anonymous Poster
In C++ the following is legal:
float* fp;
fp = new float(2);
on the second line a constructor is being called, there are no casts.
Sigh... why is it that for any topic on these forums that does not have a self-evident answer (and even for many that do), we just end up going round and round in circles? Let me reiterate: a constructor call such as the above is also known as a function-style cast (particularly in cases where it seems semantically logical to regard it as a cast). In the case of built-in types, a function-style cast T(e) is equivalent to (T)e. IOW, it is a cast, but has constructor syntax.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
