🚀 go-pugleaf

alice yang (aliceyang@worldnet.att.net) wrote:
: C++ Guru
:  Would you help me to understand the importance of using "static-cast"?

I responded to this via e-mail.  Much the same as Kanze.  I also had a
problem coming up with an example of static_cast.  The following prompted
some concern that it could be infered that static_cast is useless.

> "when do I HAVE to use static_cast explicity".  It seems that c cast
> can do the same thing anyway (as far as static-cast is concerned)

I also read James Kanze post to your question.  Seems that we agree mostly
except that he prefers the C style since it clears ambiguities while I
prefer the C++ functional style because it looks like an explicit
constructor call.  We all know that that can not be done, but effectively
that is what happens.  The technical rules are:
float(intThing) ==> (float)intThing ==> static_cast<float>(intThing) ==>
create an unnamed temporary float constructed by a standard conversion
from int.  Wow!  By the way, it is an rvalue; so, this is not legal:

float floatThing = float(intThing) *= anotherThing;

However, had it been a class item rather than a built-in and *= were a
member function, the above would be legal.  Non-const member functions
may be used with rvalues.

I did think of an example where I would use static_cast; however, James
would not need to.

long double ld = static_cast<long double>(intThing);

The C++ functional form of cast can not be used except with simple type
identifiers.  Since I prefer function style casts, I always made a bunch
of typedefs to allow their use.

typedef long double longDouble;
long double ld = longDouble(intThing);

I think that I will shift from that to static_cast when my compilers all
catch up to the new rules.  Only one of my four compilers currently
support the new casts.

One word of caution.  In the above formal rules, the step from C style
cast to new style cast has three possibilities.  The compiler must decide
which is appropriate.  I generally do not trust compilers and prefer to
be explicit.  Here is a nasty example.

Thing fun (const Thing& t) {
	return Thing(t) += 10;
	}

The class Thing has a constructor which takes an int.  Since t is of type
thing, the cast calls for use of the copy constructor.  The class does have
a member +=.  I said:

	return static_cast<Thing>(t) += /* implicit */ static_cast<Thing>(10);

The compiler heard:

	return const_cast<Thing>(t) += /* implicit */ static_cast<Thing>(10);

Boy was that a shock.  All of my const parameters got modified and gave
total garbage for results.  The down side is that the compiler did not
support the new casts so that I could not be explicit.  The real problem
was that the compiler did not generate a copy constructor so it could
not use a static_cast.  The rules say that there is always a copy
constructor.  Some people, including compiler writers, think that
declaring any constructor cancels both the generated default and
copy constructors.  Any constructor, including the copy constructor,
cancels the default constructor; however, there must always be a
copy constructor.  There can be two but never none.  I solved my
problem by declaring the copy constructor.

With compilers racing to catch the moving C++ standard, bugs like this
will be around for a while.  If your compiler supports the new style
casts, I would strongly recomend using them in place of C style or C++
functional style.  An explicit conversion/copy constructor call sure looks
nicer, but static_cast reminds us of what we are really doing.

John
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]