static_cast better than C cast ?

[Vincent RICHOMME]

Is there any reason to use static_cast instead of old C syntax ?

Let's say I declare

GLfloat test = static_cast<GLfloat>(x);

or

GLfloat test = (GLfloat) x;
once compiled is the code different ?

[Victor Bazarov]

Vincent RICHOMME wrote:

Is there any reason to use static_cast instead of old C syntax ?

Let's say I declare

GLfloat test = static_cast<GLfloat>(x);

or

GLfloat test = (GLfloat) x;
once compiled is the code different ?

Depends on the relationship between GLfloat and the type of 'x'.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Alf P. Steinbach]

* Vincent RICHOMME:

Is there any reason to use static_cast instead of old C syntax ?

Let's say I declare

GLfloat test = static_cast<GLfloat>(x);

or

GLfloat test = (GLfloat) x;

once compiled is the code different ?

Wrong question. :-)

However, Victor already answered that.

Right question 1: what kinds of errors do static_cast help identify
(i.e. what code will not compile)?

Answer: all kinds of casts that are not static casts, namely reinterpret
casts, const casts and casting to inaccessible base.

Right question 2: what does static_cast communicate to the reader of the
code?

Answer: that you're intending to cast between related types, namely that
the types are assumed to be related in one of the ways supported by
static_cast, and also that you're competent enough to know the
difference (which is very important when maintaining code and making
decisions about what to investigate, i.e is that dubious construct most
probably intentional, a bug, or just arbitrary meaningless stuff?).

Right question 3: what other advantages are there?

Answer: for example, it's much easier to search for static_cast than to
search for a C style cast or a C++ "pseudo constructor call" cast.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[red floyd]

Victor Bazarov wrote:

Vincent RICHOMME wrote:

>Is there any reason to use static_cast instead of old C syntax ?

Let's say I declare

GLfloat test = static_cast<GLfloat>(x);

or

GLfloat test = (GLfloat) x;
once compiled is the code different ?

Depends on the relationship between GLfloat and the type of 'x'.

I couldn't find a FAQ on C++ style casts vs. C style casts.

In general, you should *prefer* static_cast instead of C casts.
They're easier to find, they're safer, etc...

[red floyd]

Vincent RICHOMME wrote:

Is there any reason to use static_cast instead of old C syntax ?

Let's say I declare

GLfloat test = static_cast<GLfloat>(x);

or

GLfloat test = (GLfloat) x;

I couldn't find a FAQ on C++ style casts vs. C style casts (but it
should be one).

In general, you should *prefer* static_cast instead of C casts.
They're easier to find, they're safer, etc...

[faceman28208]

On May 2, 2:13 pm, Vincent RICHOMME <[e-mail]:

Is there any reason to use static_cast instead of old C syntax ?

Let me give a contrarian view. When the C++ standard came out, I
became a loyal user of the new style casts.

However, over the years I have reverted to the olde style (with the
exception of dynamic_cast). The reason is because most of the time I
am using casts is for calls to libraries. I find that

(void*) &x

is clearer than the multiple casts required with the new format:

reinterprest_cast<void*>(const_cast><int*>(&x)) ;

I find the that the latter is less clear than the former. For
consistency, I just use the former all the time. If I did a lot of
searching for casts, I might consider the the new style to be and
advantage. Since I don't, I have come to regard the new style casts as
being primarily an academic distinction.

once compiled is the code different ?

No way to tell but probably not.

[Victor Bazarov]

fa**********@yahoo.com wrote:

On May 2, 2:13 pm, Vincent RICHOMME <[e-mail]:

>Is there any reason to use static_cast instead of old C syntax ?

Let me give a contrarian view. When the C++ standard came out, I
became a loyal user of the new style casts.

However, over the years I have reverted to the olde style (with the
exception of dynamic_cast). The reason is because most of the time I
am using casts is for calls to libraries. I find that

(void*) &x

is clearer than the multiple casts required with the new format:

reinterprest_cast<void*>(const_cast><int*>(&x)) ;

Replace 'void' with 'char' and I'll believe it.

I find the that the latter is less clear than the former. [..]

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[mlimber]

On May 2, 2:49 pm, [e-mail] wrote:

Let me give a contrarian view. When the C++ standard came out, I
became a loyal user of the new style casts.

However, over the years I have reverted to the olde style (with the
exception of dynamic_cast). The reason is because most of the time I
am using casts is for calls to libraries. I find that

(void*) &x

is clearer than the multiple casts required with the new format:

reinterprest_cast<void*>(const_cast><int*>(&x)) ;

You don't need two casts here. Since any non-const pointer can be
implicitly converted to a void*, the const_cast will suffice. The
advantage of using const_cast over a C-style cast is that it makes
clear precisely why you are casting away (although it is a tad less
helpful when casting away volatile -- cv_cast, anyone?).

I find the that the latter is less clear than the former. For
consistency, I just use the former all the time. If I did a lot of
searching for casts, I might consider the the new style to be and
advantage. Since I don't, I have come to regard the new style casts as
being primarily an academic distinction.

I don't think it's academic. The new style casts are safer than the
other at no run-time cost to you (except with dynamic_cast, of
course). Casts should generally be avoided, but when they're needed
(as in a call to an olde-style library), they make the reason for the
cast clearer. See Alf's post above, and see the Creator's FAQ:

http://www.research.att.com/~bs/bs_f...ml#static-cast

Cheers! --M

[Vincent RICHOMME]

Victor Bazarov a écrit :

Vincent RICHOMME wrote:

>Is there any reason to use static_cast instead of old C syntax ?

Let's say I declare

GLfloat test = static_cast<GLfloat>(x);

or

GLfloat test = (GLfloat) x;
once compiled is the code different ?

Depends on the relationship between GLfloat and the type of 'x'.

V

x is a int and GLFloat is a float

[James Kanze]

On May 2, 8:33 pm, red floyd <[e-mail]:

Victor Bazarov wrote:

Vincent RICHOMME wrote:

Is there any reason to use static_cast instead of old C syntax ?

Let's say I declare

GLfloat test = static_cast<GLfloat>(x);

or

GLfloat test = (GLfloat) x;

once compiled is the code different ?

Depends on the relationship between GLfloat and the type of 'x'.

I couldn't find a FAQ on C++ style casts vs. C style casts.

In general, you should *prefer* static_cast instead of C casts.
They're easier to find, they're safer, etc...

For pointers or references, I agree; I wouldn't let code through
code review that used a C style cast for a pointer or a
reference. For other things, it's less obvious. A lot of
people use function style casts for class types, e.g.:
"MyClass( x )"---unless the type conversion has exactly one
argument, its the only style of cast which is legal. And I (and
others I've worked with) have nothing against the C style casts
for arithmetic types, particularly for widening casts (e.g.
(double)someInt or (unsigned long)someShort).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]