🚀 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                             ]