experchange > cpp

G G (07-01-19, 01:16 AM)
casting:

double ( a_value ) or (double) a_value

vs.

static_cast<double>( a_value ) /* c++ 11 + */
Alf P. Steinbach (07-01-19, 01:38 AM)
On 01.07.2019 01:16, G G wrote:
> casting:
> double ( a_value ) or (double) a_value
> vs.
> static_cast<double>( a_value ) /* c++ 11 + */


The named casts have always been part of C++.

They're named because

* That makes the intent more clear.
* It's grep-able.
* It's more to write, which is a good thing for casts.

The two first notations, `double(x)` and `(double)x`, mean exactly the
same, but unlike the `static_cast` you don't know what that thing is
without inspecting `x`. It could be a `const_cast`, a `static_cast`, a
`reinterpret_cast` or a cast to inaccessible base, or a (restricted)
combination. When the code is maintained and `x` is changed, the unnamed
cast can drastically change meaning and introduce a bug.

Still, constructing a class type instance with one argument is
syntactically a cast of that argument, so one can't avoid the notation.
For that matter, constructing a class instance with any number of
arguments is syntactically a cast, but it gets absurd with 2 or more
arguments. I guess Stroustrup intended a kind of unification of
"conversion" expressions.

Cheers & hth.,

- Alf
Juha Nieminen (07-01-19, 09:38 AM)
G G <gdotone> wrote:
> casting:
> double ( a_value ) or (double) a_value
> vs.
> static_cast<double>( a_value ) /* c++ 11 + */


The problem with C-style casts (even with the C++ style use of
parentheses) is that, while it looks nice and neat (and almost
looks like a function call), it's way too strong and may lead
to mistakes, especially with aliased or custom types. That's
because a C style cast will cast pretty much *anything* to
pretty much anything else, no questions asked.

static_cast guards you against accidental casts between
incompatible types, which may catch programming mistakes at
the best possible stage of development.

Also, once you get used to static_cast, it actually helps reading
and understanding the code because it visually indicates where
a cast is being made, which with the "function call syntax" it may
not be as apparent (because it looks like a function call, not a
type cast).
Bonita Montero (07-01-19, 02:40 PM)
C++-style casts are superfluous child-proof locks in most cases.
And in many cases they're even syntactic sugar.
Melzzzzz (07-01-19, 02:45 PM)
On 2019-06-30, G G <gdotone> wrote:
> casting:
> double ( a_value ) or (double) a_value
> vs.
> static_cast<double>( a_value ) /* c++ 11 + */


no that's 98
Melzzzzz (07-01-19, 02:46 PM)
On 2019-07-01, Bonita Montero <Bonita.Montero> wrote:
Bonita Montero (07-01-19, 02:53 PM)
>> C++-style casts are superfluous child-proof locks in most cases.
>> And in many cases they're even syntactic sugar.


> No.


No, sure.
Jorgen Grahn (07-01-19, 03:14 PM)
On Sun, 2019-06-30, G G wrote:
> casting:
> double ( a_value ) or (double) a_value
> vs.
> static_cast<double>( a_value ) /* c++ 11 + */


Do you have a question, or do you want to make a statement about
something? And what is the smiley for -- is the whole posting a
joke?

/Jorgen
G G (07-01-19, 08:22 PM)
No, reading two books. One book spent a great bit of time describing casting using double( a_value) type the other book just said static_cast<double>(a_value) was the way to cast. I was hoping someone would explain why the change and the reason for it. Both books I think are at least c++11
Chris M. Thomasson (07-01-19, 09:53 PM)
On 7/1/2019 5:53 AM, Bonita Montero wrote:
>>> C++-style casts are superfluous child-proof locks in most cases.
>>> And in many cases they're even syntactic sugar.

>> No.

> No, sure.


There is a difference between static_cast and reinterpret_cast. No?
G G (07-01-19, 10:55 PM)
Oh yeah the smile. I’m a happy to actually be learning
Bonita Montero (07-02-19, 08:50 AM)
>>>> C++-style casts are superfluous child-proof locks in most cases.
>>>> And in many cases they're even syntactic sugar.


>>> No.


>> No, sure.


> There is a difference between static_cast and reinterpret_cast. No?


That wasn't the question. The question is if everything which can
be done with C++-style casts can be done with C-style casts - and
that's almost true.
Juha Nieminen (07-02-19, 10:14 AM)
Bonita Montero <Bonita.Montero> wrote:
> C++-style casts are superfluous child-proof locks in most cases.
> And in many cases they're even syntactic sugar.


You could say that of the entirety of C++. Just program directly
in asm.

Heck, even asm is just syntactic sugar. Just program directly in
machine code by writing the byte values into an executable file
using a hex editor.
Bonita Montero (07-02-19, 11:30 AM)
>> C++-style casts are superfluous child-proof locks in most cases.
>> And in many cases they're even syntactic sugar.


> You could say that of the entirety of C++. Just program directly
> in asm.


That's an not fitting analogy. C++-style casts just don't have an
advantage on the maintainability, deveopment-performance and ease
of writing.
Alf P. Steinbach (07-02-19, 12:20 PM)
On 02.07.2019 11:30, Bonita Montero wrote:
> That's an not fitting analogy. C++-style casts just don't have an
> advantage on the maintainability, deveopment-performance and ease
> of writing.


I hate to agree with Juha, since he has adopted the sideline hobby of
bashing me at any opportunity, but he's right.

The `++` in C++ is nearly all about imposing constraints on the code,
mostly via static typing, and the named casts help with that.

For example, `static_cast` does a static cast and no other kind of cast.

Cheers!,

- Alf