Is there any real benefits of using static_cast instead of C-style cast
operation? It seems to me that it doesn't do much except of introducing
restriction on casting const expressions into non-const. (well it also
doesn't allow to cast to the virtual base class...)
Regards.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Yes, there are many real benefits to using the C++-style casts than the
normal C style casts. The only thing is, the benefits (of most of the
casts) are decreased power in casting rather than increased, thus if
you wanted casts that allow more, wild, casts than the C-style casts,
you won't see the benefits in the C++ casts.
For example, using ordinary C-style casts, this block of code is legal
int *pi;
int i = (int)pi;
Whereas, using the static_cast, C++-style cast, it now becomes illegal,
more than likely erroring out with a message stating that a
reinterpret_cast is needed to make it legal.
The C++ casts allow for much safer casting than ordinary C style casts
do and that is where their virtue comes from. To restate it in other
terms, the C++ casts don't allow the range of casts that C casts do,
thus they help greatly in preventing accidental misuses of casts.
One of the other virtues to using them are their ugliness. Yes, I know
that most people (especially those with a C background) hate typing a
few extra keystrokes to achieve the same result, thus they stick to the
C style casts. But, in actuality, many casts used in C++ are not
needed, that is, they could be taked out with the implementation of
more thought-out code, thus using the C++ casts makes you think twice
about casting between different types and make you think if there is
some other way that you could achieve the same thing without using
them.
Also, in the same realm as the ugliness, they make it much easier to
perform a search of your code for any and all casts if at any time that
you need to, rather than being forced to search for type names or (ugh)
parenthesis.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
On 11 Mar 2005 21:08:18 -0500, "Vlad" wrote:
>Is there any real benefits of using static_cast instead of C-style cast
>operation?
The static_cast and associated operators are easier to see exactly where a
change occurrs by enclosing an expression in parenthesis. While this isn't
better, it improves readability slightly - especially with inexperienced
programmers.
For example:
int i = (int)5.3 * 6;
int j = static_cast(5.3) * 6;
>It seems to me that it doesn't do much except of introducing
>restriction on casting const expressions into non-const. (well it also
>doesn't allow to cast to the virtual base class...)
static_cast isn't meant to do that. You have to use one of dynamic_cast,
reinterpret_cast, or const_cast depending on the requirement. In some
cases, you need to define the casting operator so that the compiler will
know how to do it.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Vlad" writes:
> Is there any real benefits of using static_cast instead of C-style cast
> operation? It seems to me that it doesn't do much except of introducing
> restriction on casting const expressions into non-const. (well it also
> doesn't allow to cast to the virtual base class...)
A C style cast can mean static_cast, const_cast, dynamic_cast,
reinterpret_cast, a combination thereof or something not expressable
by the C++ cast operators.
Using C++ cast operators therefore expresses the programmer's intent
better than writing a C style cast.
In my experience, casts often are where bugs are; making them stand
out by using C++ cast operators thus helps fixing errors.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Vlad wrote:
> Is there any real benefits of using static_cast instead of C-style cast
> operation? It seems to me that it doesn't do much except of introducing
> restriction on casting const expressions into non-const. (well it also
> doesn't allow to cast to the virtual base class...)
I'd throw in that you also can't remove a volatile from an expression.
However, if you accept const correctness as useful, not being able to
accidentally cast it away with static_cast is a real benefit.
Uli
--
Questions ?
see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first !
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Vlad" skrev i meddelandet
news:1f4059b7274bac76408d699e7fe8914e@localhost.talkaboutprogramming.com...
> Is there any real benefits of using static_cast instead of C-style
> cast
> operation? It seems to me that it doesn't do much except of
> introducing
> restriction on casting const expressions into non-const. (well it also
> doesn't allow to cast to the virtual base class...)
One benefit is that it looks ugly, so you tend to avoid casting.
Another is that it is limited, so you can avoid unintentional casts,
like those offered by const_cast and reinterpret_cast.
This is all very much intentional!
The C++ way is to use converting constructors when you really want to
construct one type from another.
Bo Persson
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Bo Persson wrote:
> This is all very much intentional!
What do you mean with this sentence?
> The C++ way is to use converting constructors when you really want to
> construct one type from another.
Why should that be better? How do casts work in detail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Michael Etscheid" skrev i meddelandet
news:d0uuup$2uc$04$1@news.t-online.com...
> Bo Persson wrote:
>> This is all very much intentional!
>
> What do you mean with this sentence?
That the C++ committee had the intention of making casts look ugly and
be somewhat hard to use. The idea being that you should avoid using them
whenever possible.
>
>> The C++ way is to use converting constructors when you really want to
>> construct one type from another.
>
> Why should that be better? How do casts work in detail?
C style casts work by telling the compiler - do whatever necessary to
convert this value to that, possibly totally unrelated, other type. I
know what I'm doing, trust me! Honest, Gov.
Compiler says: Yeah, sure - it's your funeral!
Bo Persson
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Bo Persson schrieb:
> C style casts work by telling the compiler - do whatever necessary to
> convert this value to that, possibly totally unrelated, other type. I
> know what I'm doing, trust me! Honest, Gov.
>
> Compiler says: Yeah, sure - it's your funeral!
But how do C++ casts work?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Vlad wrote:
> Is there any real benefits of using static_cast instead of
> C-style cast operation? It seems to me that it doesn't do much
> except of introducing restriction on casting const expressions
> into non-const. (well it also doesn't allow to cast to the
> virtual base class...)
It prevents you from accidentally doing any number of things you
didn't want to do. I remember in one of my earliest C++
applications, there was a lot of casting up and down the
hierarchy. We rearranged the hierarchy, and some of those C
style casts changed from being static_cast (strictly up or down)
to being reinterpret_cast (sideways). We had a devil of a time
getting it all straightened out.
I still use the C style casts (or function style casts) when
what I want is a new object: A(1), for example, but also
double(i). Whenever there are alternative interpretations as to
what the conversion might mean (pointers or references),
however, I use only the new style casts.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]