🚀 go-pugleaf

In article <30F54E6D.B4@worldnet.att.net> alice yang
<aliceyang@worldnet.att.net> writes:

|>  Would you help me to understand the importance of using "static-cast"?

|> In the book, it states, "this cast construct is a better alternative than
|> its c counterpart only becasue it is easier to locate a c++ cast construct
|> in a source file"

|> So, does that mean the following is exactly the same?

|> float fnumber;
|> int   inumber;

|> fnumber=(float)inumber;
|> fnumber=<static_cast>inumber; /same as the first one??/

If you get the syntax right, yes:

	fnumber = static_cast< float >( inumber ) ;

Not all of the old style casts correspond to a static_cast, however.
For instance:

	T*          p ;
	(T1*)p              //  Use reinterpret_cast< T1* >( p )

	T const*    pc ;
	(T*)pc              //  Use const_cast< T* >( p )
	(T1*)pc           
	    //  Use reinterpret_cast< T1* >(const_cast< T* >( pc ) )

In practice, use static_cast for numeric conversions and to navigate a
hierarchy, and const_cast to cast away const.  Don't use
reinterpret_cast except in really special cases; it is almost always
wrong in application software.  (It is present because certain types
of system software, e.g. IO, cannot be written without it.)

Concerning the recommendation `in the book': I tend to use an explicit
constructor call for value conversions, since in fact, the results are
a new object:
	
	fnumber = (float)( inumber ) ;

(I systematically put the type in parentheses when there is only a
single parameter, since this avoids the ambiguity that occasionally
otherwise occurs between an explicit constructor and a declaration.
Formally, the C++ grammar says that this is an old style cast, but in
practice, it is exactly the same as an explicit constructor call.  And
I *ONLY* do this where the results are a new object; I definitly avoid
the old style casts in all othe contexts.  Come to think about it, I
don't use the new style casts that often, either.)

Since this posting is mainly concerned with style, and not
standardization issues, I've set the follow-ups to
comp.lang.c++.moderated.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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                             ]

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                             ]

Aren't the old C style casts and C++ functional style casts depricated
under the draft standard?

Jason
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

In article <314c3f47.1349350@nntp.ix.netcom.com> jdmorris@ix.netcom.com (Jason D. Morris) writes:

> Aren't the old C style casts and C++ functional style casts depricated
> under the draft standard?

No.  It's true that new-style casts (static_cast, dynamic_cast,
reinterpret_cast and const_cast) are almost always a better solution,
but old-style casts have not been deprecated.

If a feature has been deprecated, that basically means that users are
warned to stop using that feature: there is no guarantee that it will
continue to be supported.  The standardization committee chose not to
do anything so drastic in the case of casts.
-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com


[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]