casting that's a lot of extra typing :-)

[G G]

casting:

double ( a_value ) or (double) a_value

vs.

static_cast<double>( a_value ) /* c++ 11 + */

[Alf P. Steinbach]

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]

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]

C++-style casts are superfluous child-proof locks in most cases.
And in many cases they're even syntactic sugar.

[Melzzzzz]

no that's 98
>
>
>
>


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Melzzzzz]

On 2019-07-01, Bonita Montero <Bonita....@gmail.com> wrote:
> C++-style casts are superfluous child-proof locks in most cases.
> And in many cases they're even syntactic sugar.

No.

[Bonita Montero]

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

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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[G G]

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]

There is a difference between static_cast and reinterpret_cast. No?

[G G]

Oh yeah the smile. I’m a happy to actually be learning

[Bonita Montero]

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

Bonita Montero <Bonita....@gmail.com> 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]

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

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

[Bart]

A hex editor? What luxury!

I used LED lights to show binary contents of memory locations, and an
earth lead to touch 8 metal contacts to set individual bits (couldn't
afford so many push-buttons) to program in binary machine code.

(This was actually quite true.)

[Bonita Montero]

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

No, they rarely make things more readable or maintainable.

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

C++-style casts are mostly an idea for compulsive developers;
and compulsiveness is an occupational illness of may developers.

[Ben Bacarisse]

Bart <b...@freeuk.com> writes:

> On 02/07/2019 09:14, Juha Nieminen wrote:
>> Bonita Montero <Bonita....@gmail.com> 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.
>>
>
> A hex editor? What luxury!
>
> I used LED lights to show binary contents of memory locations,

<accent location=northern>
LED lights? Luxury! Bloody luxury! When I were a lad we had to lick
terminals on 't delay lines wi' our tongues to read memory.
</accent>

--
Ben.

[Christian Gollwitzer]

Am 02.07.19 um 15:35 schrieb Ben Bacarisse:

> terminals on 't delay ines wi' our tongues to read memory.
> </accent>


https://xkcd.com/378/

[James Kuyper]

On Tuesday, July 2, 2019 at 9:35:21 AM UTC-4, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
...

> > A hex editor? What luxury!
> >
> > I used LED lights to show binary contents of memory locations,
>
> <accent location=northern>
> LED lights? Luxury! Bloody luxury! When I were a lad we had to lick
> terminals on 't delay lines wi' our tongues to read memory.
> </accent>

How far north? Greenlandic? :-)
"Shadwell hated all Southerners, and by inference, was standing at the
north pole." ("Good Omens" - Terry Pratchet).

[G G]

James:

Hahahahaha, that was funny. “...Standing at the North Pole...”. ...hated all southerners ...

Cause I had to read that twice .

There is humor in this group. :- )

[James Kuyper]

It can be hard to be sure on usenet whether or not a comment is intended
to be sarcastic unless it's specifically labelled as such - your wording
gives me some doubt about it. If that wasn't sarcastic, I strongly
recommend reading anything by Terry Pratchet - there's lots more where
that came from, and that's far from being the funniest line he's written.

[Melzzzzz]

Not true.

[Bonita Montero]

>>>> 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.

> Not true.

No, true. ;-)

[Vir Campestris]

On 02/07/2019 18:06, James Kuyper wrote:
> It can be hard to be sure on usenet whether or not a comment is intended
> to be sarcastic unless it's specifically labelled as such - your wording
> gives me some doubt about it. If that wasn't sarcastic, I strongly
> recommend reading anything by Terry Pratchet - there's lots more where
> that came from, and that's far from being the funniest line he's written.

Pratchett is always worth a read. You'll even notice he understands
computer people - if you read about the clacks.

Andy
--
Who doesn't go past core store and dip switches - and that was only once...

[G G]

> It can be hard to be sure on usenet whether or not a comment is intended
> to be sarcastic unless it's specifically labelled as such - your wording
> gives me some doubt about it. If that wasn't sarcastic, I strongly
> recommend reading anything by Terry Pratchet - there's lots more where
> that came from, and that's far from being the funniest line he's written.

James:

no i thought that was funny... really!

i will look up Terry Pratchet.

i've been watching amazon prime stuff lately, and have found
Canadian tv very funny, the last few days. so i was in the comedic
mindset when i read it i guess. comedies like : amazon: corner gas,
youtube: little mosque on the prairie ,
bbc: yes minister and yes prime minister.

who knew canada could tell a good joke (just kidding about
canada telling a good joke)

those shows have me laughing out loud.

yes i enjoyed the joke. no sarcasm here.

[Chris M. Thomasson]

The Woz! :^)

[Chris M. Thomasson]

LOL! :^D

[Mike Terry]

On 02/07/2019 23:50, G G wrote:
>
>> It can be hard to be sure on usenet whether or not a comment is intended
>> to be sarcastic unless it's specifically labelled as such - your wording
>> gives me some doubt about it. If that wasn't sarcastic, I strongly
>> recommend reading anything by Terry Pratchet - there's lots more where
>> that came from, and that's far from being the funniest line he's written.
>
> James:
>
> no i thought that was funny... really!
>
> i will look up Terry Pratchet.
>
> i've been watching amazon prime stuff lately, and have found
> Canadian tv very funny, the last few days. so i was in the comedic
> mindset when i read it i guess. comedies like : amazon: corner gas,
> youtube: little mosque on the prairie ,
> bbc: yes minister and yes prime minister.
>

..and in case you didn't recognise where Ben's strange northern accent
came from, you could check out e.g.

https://www.youtube.com/watch?v=VKHFZBUTA4k


Regards
Mike.

[Juha Nieminen]

Yes, they have. Especially when used aliased or custom types,
a static_cast will make sure you don't accidentally cast into an
incompatible type, which most often than not is a bug, which in
this case would be caught as early as possible in the development
process, ie. when compiling.

They also make it visually easier to see where explicit casts are
being done, because they don't look like normal function calls.

[Bonita Montero]

> Yes, they have. Especially when used aliased or custom types,
> a static_cast will make sure you don't accidentally cast into an

> incompatible type, ...

I've never seen such bugs with C-style casting.
This kind of child-proof lock in C++ is simply useles.

[Manfred]

On 7/5/2019 9:52 AM, Bonita Montero wrote:
>> Yes, they have. Especially when used aliased or custom types,
>> a static_cast will make sure you don't accidentally cast into an
>> incompatible type, ...
>
> I've never seen such bugs with C-style casting.

Then you don't have seen much of it.

> This kind of child-proof lock in C++ is simply useles.

Just the opposite, as many have said.

[Öö Tiib]

It is may be not worth to repeat that endlessly. Melzzzzz, Alf, Juha
and Chris have seemingly already pointed out most of the meaningful
benefits of C++ casts. Bonita has apparently none experience with
it and won't come up with anything resembling counterarguments so
... end of story. Either time will teach her or wont. Pointless
to warm it up. ;)

[Bonita Montero]

> ... Melzzzzz, Alf, Juha and Chris have seemingly already
> pointed out most of the meaningful benefits of C++ casts. ...

They pointed them out just as chid-proof locks.

[Chris M. Thomasson]

They have their place. Btw, you might get a kick out of the following scene:

Cork on the Fork in Dirty Rotten Scoundrels:

https://youtu.be/SKDX-qJaJ08

You think the C++ casts are akin to the cork on the fork?

[Öö Tiib]

> They pointed them out just as chid-proof locks.

They nowhere did it, you did.
C++ casts don't unfortunately work as child proof locks.
If there was a feature that worked like baby proof lock
and kept stupid people from using C++, then I would really
love it.

[James Kuyper]

A child-proof lock is designed to protect something from tampering by
less-sophisticated users, while retaining accessibility for more
sophisticated ones. I see no way to make an analogy connecting that
concept to the advantages of the named casts in C++. A failure to use
them when appropriate is a strong indication of inexperience with C++,
but there use itself doesn't have any consequence that varies with
experience level.

The key advantage they provide is that they make it an easily diagnosed
constraint violation to accidentally perform a different kind of
conversion than was intended. The mistakes that they help diagnose are
among the most common mistakes made when using C-style casts. Like all
such mistakes, they are made less commonly by experienced developers
than by inexperienced ones, but experience doesn't make such mistakes
impossible, merely less likely. That you claim to have never seen such
mistakes suggests a lack of experience with C-style casts.