Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #87080 > unrolled thread

why use static_cast ?

Back to article view | Back to comp.lang.c++

Contents

  why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-19 21:01 -0500
    Re: why use static_cast ? "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-19 19:40 -0700
      Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-20 00:21 -0500
        Re: why use static_cast ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-10-19 23:21 -0700
          Re: why use static_cast ? Juha Nieminen <nospam@thanks.invalid> - 2022-10-20 07:19 +0000
            Re: why use static_cast ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-10-20 00:21 -0700
        Re: why use static_cast ? Paul N <gw7rib@aol.com> - 2022-10-20 04:23 -0700
          Re: why use static_cast ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-20 14:14 +0100
          Re: why use static_cast ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-10-20 09:17 -0700
            Re: why use static_cast ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-20 09:52 -0700
              Re: why use static_cast ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-15 17:10 -0800
                Re: why use static_cast ? Juha Nieminen <nospam@thanks.invalid> - 2022-11-16 09:26 +0000
                  Re: why use static_cast ? David Brown <david.brown@hesbynett.no> - 2022-11-16 14:36 +0100
                  Re: why use static_cast ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-20 05:54 -0800
        Re: why use static_cast ? "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-20 08:11 -0700
    Re: why use static_cast ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-10-19 20:09 -0700
    Re: why use static_cast ? Juha Nieminen <nospam@thanks.invalid> - 2022-10-20 05:44 +0000
      Re: why use static_cast ? Gawr Gura <gawrgura@mail.hololive.com> - 2022-10-20 14:50 +0000
        Re: why use static_cast ? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-20 17:53 +0300
    Re: why use static_cast ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-20 08:52 +0200
      Re: why use static_cast ? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-20 17:52 +0300
    Re: why use static_cast ? scott@slp53.sl.home (Scott Lurndal) - 2022-10-20 13:55 +0000
      Re: why use static_cast ? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-20 17:55 +0300
        Re: why use static_cast ? scott@slp53.sl.home (Scott Lurndal) - 2022-10-20 15:01 +0000
          Re: why use static_cast ? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-20 18:32 +0300
            Re: why use static_cast ? scott@slp53.sl.home (Scott Lurndal) - 2022-10-20 16:07 +0000
              Re: why use static_cast ? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-20 20:14 +0300
                Re: why use static_cast ? scott@slp53.sl.home (Scott Lurndal) - 2022-10-20 17:30 +0000
                  Re: why use static_cast ? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-20 20:41 +0300
                Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-21 14:05 -0500
                  Re: why use static_cast ? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-22 00:09 +0300
                  Re: why use static_cast ? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-22 08:47 +0300
                    Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-22 15:03 -0500
                      Re: why use static_cast ? Muttley@dastardlyhq.com - 2022-10-23 07:35 +0000
                        Re: why use static_cast ? JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-10-23 15:28 +0300
                        Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-23 14:13 -0500
                      Re: why use static_cast ? Manfred <noname@add.invalid> - 2022-10-23 20:27 +0200
                      Re: why use static_cast ? Michael S <already5chosen@yahoo.com> - 2022-10-23 15:04 -0700
                        Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-23 23:14 -0500
            Re: why use static_cast ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-21 17:21 +0200
        Re: why use static_cast ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-21 17:24 +0200
      Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-20 13:21 -0500
        Re: why use static_cast ? Manfred <noname@add.invalid> - 2022-10-21 05:52 +0200
          Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-21 13:59 -0500
            Re: why use static_cast ? Bo Persson <bo@bo-persson.se> - 2022-10-22 18:31 +0200
              Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-22 15:05 -0500
              Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-22 17:34 -0500
          Re: why use static_cast ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-02 17:54 -0700
            Re: why use static_cast ? Öö Tiib <ootiib@hot.ee> - 2022-11-03 08:51 -0700
              Re: why use static_cast ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-15 16:19 -0800
                Re: why use static_cast ? Öö Tiib <ootiib@hot.ee> - 2022-11-15 23:02 -0800
                  Re: why use static_cast ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-20 05:59 -0800
                    Re: why use static_cast ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-11-20 15:05 +0100
                      Re: why use static_cast ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-20 07:22 -0800
                        Re: why use static_cast ? Öö Tiib <ootiib@hot.ee> - 2022-11-20 08:40 -0800
                          Re: why use static_cast ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 20:43 -0800
      Re: why use static_cast ? Juha Nieminen <nospam@thanks.invalid> - 2022-11-04 07:27 +0000
        Re: why use static_cast ? scott@slp53.sl.home (Scott Lurndal) - 2022-11-04 13:47 +0000
          Re: why use static_cast ? Vir Campestris <vir.campestris@invalid.invalid> - 2022-11-05 21:34 +0000
          Re: why use static_cast ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-06 03:25 -0500
          Re: why use static_cast ? Paavo Helde <eesnimi@osa.pri.ee> - 2022-11-06 17:34 +0200
            Re: why use static_cast ? Juha Nieminen <nospam@thanks.invalid> - 2022-11-07 07:13 +0000
        Re: why use static_cast ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-04 09:09 -0700
    Re: why use static_cast ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-20 13:21 -0500

Page 1 of 4  [1] 2 3 4  Next page →

#87080 — why use static_cast ?

I put the following cast into my code and one of my programmers wants me 
to use static cast.  Why ?
    https://en.cppreference.com/w/cpp/language/static_cast

    longint nfac [8];
    fem::str <8> * nfac_str = (fem::str <8> *) nfac;

fem::str <8> is an 8 character object that acts like a Fortran 
character*8.  longint is a long long.

Thanks,
Lynn

[toc] | [next] | [standalone]

#87081

On Wednesday, October 19, 2022 at 10:01:35 PM UTC-4, Lynn McGuire wrote:

> I put the following cast into my code and one of my programmers wants me 
> to use static cast. 

I'm pretty sure static_cast would give an invalid type conversion error.

> longint nfac [8]; 
> fem::str <8> * nfac_str = (fem::str <8> *) nfac; 
> 
> fem::str <8> is an 8 character object that acts like a Fortran 
> character*8. longint is a long long. 
> 
I think that's undefined behaviour.

Daniel

[toc] | [prev] | [next] | [standalone]

#87083

On 10/19/2022 9:40 PM, daniel...@gmail.com wrote:
> On Wednesday, October 19, 2022 at 10:01:35 PM UTC-4, Lynn McGuire wrote:
> 
>> I put the following cast into my code and one of my programmers wants me
>> to use static cast.
> 
> I'm pretty sure static_cast would give an invalid type conversion error.
> 
>> longint nfac [8];
>> fem::str <8> * nfac_str = (fem::str <8> *) nfac;
>>
>> fem::str <8> is an 8 character object that acts like a Fortran
>> character*8. longint is a long long.
>>
> I think that's undefined behaviour.
> 
> Daniel

Why ?  They are both pointers to 8 byte objects.  I am just declaring 
that I want to use the same address as a 8 byte character string (no 
null !) or a long long integer.

Thanks,
Lynn

[toc] | [prev] | [next] | [standalone]

#87086

On 10/19/2022 10:21 PM, Lynn McGuire wrote:
> 
> Why ?  They are both pointers to 8 byte objects.  I am just declaring 
> that I want to use the same address as a 8 byte character string (no 
> null !) or a long long integer.
> 

You can't, neither in C nor in C++. An object (lvalue) of type `T` can 
only be accessed as an object (lvalue) of type `T` (with few 
exceptions). This is well known as the "strict aliasing" rule.

-- 
Best regards,
Andrey.

[toc] | [prev] | [next] | [standalone]

#87088

Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> On 10/19/2022 10:21 PM, Lynn McGuire wrote:
>> 
>> Why ?  They are both pointers to 8 byte objects.  I am just declaring 
>> that I want to use the same address as a 8 byte character string (no 
>> null !) or a long long integer.
>> 
> 
> You can't, neither in C nor in C++. An object (lvalue) of type `T` can 
> only be accessed as an object (lvalue) of type `T` (with few 
> exceptions). This is well known as the "strict aliasing" rule.

AFAIK any value of any type can always be safely read with an (unsigned)
char pointer (as long as you remain within the limits of the type size).

If if weren't, it would be impossible to eg. create your own version
of memcmp().

[toc] | [prev] | [next] | [standalone]

#87089

On 10/20/2022 12:19 AM, Juha Nieminen wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 10/19/2022 10:21 PM, Lynn McGuire wrote:
>>>
>>> Why ?  They are both pointers to 8 byte objects.  I am just declaring
>>> that I want to use the same address as a 8 byte character string (no
>>> null !) or a long long integer.
>>>
>>
>> You can't, neither in C nor in C++. An object (lvalue) of type `T` can
>> only be accessed as an object (lvalue) of type `T` (with few
>> exceptions). This is well known as the "strict aliasing" rule.
> 
> AFAIK any value of any type can always be safely read with an (unsigned)
> char pointer (as long as you remain within the limits of the type size).
> 
> If if weren't, it would be impossible to eg. create your own version
> of memcmp().

That is one of the exceptions.

-- 
Best regards,
Andrey.

[toc] | [prev] | [next] | [standalone]

#87090

On Thursday, October 20, 2022 at 6:21:25 AM UTC+1, Lynn McGuire wrote:
> They are both pointers to 8 byte objects. I am just declaring 
> that I want to use the same address as a 8 byte character string (no 
> null !) or a long long integer. 

Isn't that exactly what a union is for? Though if you are hoping to put in values of one type and read them out as values of the other then you would need to check that this is actually defined in your implementation.

[toc] | [prev] | [next] | [standalone]

#87091

Paul N <gw7rib@aol.com> writes:

> On Thursday, October 20, 2022 at 6:21:25 AM UTC+1, Lynn McGuire wrote:
>> They are both pointers to 8 byte objects. I am just declaring 
>> that I want to use the same address as a 8 byte character string (no 
>> null !) or a long long integer. 
>
> Isn't that exactly what a union is for?

I'd say the main purpose is to save space by storing objects of
different types in the space required by the largest.  This inevitably
raises the question accessing an object in a union that was no the last
object stored in a union -- so called type punning.

This is defined /in C/, though the result is obviously not defined by
the C standard which only says that the bytes are interpreted as an
object of the type used for access.

However it's undefined in C++.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#87103

On 10/20/2022 4:23 AM, Paul N wrote:
> On Thursday, October 20, 2022 at 6:21:25 AM UTC+1, Lynn McGuire wrote:
>> They are both pointers to 8 byte objects. I am just declaring
>> that I want to use the same address as a 8 byte character string (no
>> null !) or a long long integer.
> 
> Isn't that exactly what a union is for? Though if you are hoping to put in values of one type and read them out as values of the other then you would need to check that this is actually defined in your implementation.

"Exactly what a union is for"?

It is true that unions have been used for type punning from time to 
time, but this is not "what a union is for". Union is a 
memory-time-sharing feature that exists for reducing memory usage. You 
don't normally "put in values of one type and read them out as values of 
the other". That's not exactly what union is for.

-- 
Best regards,
Andrey.

[toc] | [prev] | [next] | [standalone]

#87104

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 10/20/2022 4:23 AM, Paul N wrote:
>> On Thursday, October 20, 2022 at 6:21:25 AM UTC+1, Lynn McGuire wrote:
>>> They are both pointers to 8 byte objects. I am just declaring
>>> that I want to use the same address as a 8 byte character string (no
>>> null !) or a long long integer.
>> Isn't that exactly what a union is for? Though if you are hoping to
>> put in values of one type and read them out as values of the other
>> then you would need to check that this is actually defined in your
>> implementation.
>
> "Exactly what a union is for"?
>
> It is true that unions have been used for type punning from time to
> time, but this is not "what a union is for". Union is a 
> memory-time-sharing feature that exists for reducing memory usage. You
> don't normally "put in values of one type and read them out as values
> of the other". That's not exactly what union is for.

Agreed.

K&R1 (1978) introduces unions in section 6.8.  It discusses holding
objects of different types at different times; it says nothing about
type punning.  (The version of C discussed in the 1975 manual didn't
have unions.)

Of course programmers, being programmers, do not tend to restrict
themselves to the original intent of any feature.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#87408

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>
>> On 10/20/2022 4:23 AM, Paul N wrote:
>>
>>> On Thursday, October 20, 2022 at 6:21:25 AM UTC+1, Lynn McGuire wrote:
>>>
>>>> They are both pointers to 8 byte objects.  I am just declaring
>>>> that I want to use the same address as a 8 byte character string
>>>> (no null !) or a long long integer.
>>>
>>> Isn't that exactly what a union is for?  Though if you are hoping
>>> to put in values of one type and read them out as values of the
>>> other then you would need to check that this is actually defined
>>> in your implementation.
>>
>> "Exactly what a union is for"?
>>
>> It is true that unions have been used for type punning from time to
>> time, but this is not "what a union is for".  Union is a
>> memory-time-sharing feature that exists for reducing memory usage.
>> You don't normally "put in values of one type and read them out as
>> values of the other".  That's not exactly what union is for.
>
> Agreed.
>
> K&R1 (1978) introduces unions in section 6.8.  It discusses holding
> objects of different types at different times;  it says nothing
> about type punning.  (The version of C discussed in the 1975 manual
> didn't have unions.)

Even so, clearly it was expected that unions would be used for
type punning, and that type punning would work the same way it
works now, even during the early days of C between K&R1 and when
the original ANSI C committee was formed.  Evidence for this
assertion may be found in the C Rationale document, which says
nothing about using unions for type punning.  The lack of any
mention in the Rationale document means it must have been common
practice in the early days, otherwise it would have been new
behavior and surely would have been discussed and debated and
written up in the Rationale document.  Because it wasn't, unions
obviously were being used that way all along.

[toc] | [prev] | [next] | [standalone]

#87410

Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Even so, clearly it was expected that unions would be used for
> type punning,

I'm not sure it's that evident.

'union' in C sounds a lot more like a space optimization. A way to
reuse the same memory location to store different types. Like a tuple
which can only hold one value at a time (and the main impetus in this
existing is to save valuable memory, if you indeed only need one type
of value for that object at a time).

I don't see how it's so obvious that 'union' was designed from the
get-go with the intent of using it for type punning. Could just as
well be an unintended or semi-intended "side effect" (which may be
platform-specific, ie. not guaranteed to work if the target platform
doesn't support such a thing).

[toc] | [prev] | [next] | [standalone]

#87414

On 16/11/2022 10:26, Juha Nieminen wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Even so, clearly it was expected that unions would be used for
>> type punning,
> 
> I'm not sure it's that evident.
> 
> 'union' in C sounds a lot more like a space optimization. A way to
> reuse the same memory location to store different types. Like a tuple
> which can only hold one value at a time (and the main impetus in this
> existing is to save valuable memory, if you indeed only need one type
> of value for that object at a time).
> 
> I don't see how it's so obvious that 'union' was designed from the
> get-go with the intent of using it for type punning. Could just as
> well be an unintended or semi-intended "side effect" (which may be
> platform-specific, ie. not guaranteed to work if the target platform
> doesn't support such a thing).

It's worth noting that in C++, unions specifically cannot be used for 
type-punning.  If type-punning were considered a major use of unions at 
the time C++ was being standardised, I think it is reasonable to suppose 
C++ would have allowed it (perhaps with restrictions to POD types) 
rather than clearly disallowing it.  I realise that reasoning is weak - 
but no weaker than Tim's reasoning that C supported type-punning from an 
early stage.

In general, I do not think it is right to think "the standard doesn't 
ban it, so it is allowed", or "the rationale doesn't mention it, so it 
must have been viewed as obvious".  The C standard makes it clear that 
behaviour that is not described is as much "undefined behaviour" as 
things that are explicitly marked as "undefined behaviour".  So in C90, 
AFAICS, using a union for type punning is just like dereferencing a null 
pointer, or calling a function with the wrong number or type of 
parameters, or any other undefined behaviour.

That is why we have a language /standard/ - not just some interesting 
rationale documents.

[toc] | [prev] | [next] | [standalone]

#87488

Juha Nieminen <nospam@thanks.invalid> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Even so, clearly it was expected that unions would be used for
>> type punning,
>
> I'm not sure it's that evident.
>
> [...]
>
> I don't see how it's so obvious that 'union' was designed from the
> get-go with the intent of using it for type punning.

I didn't say anything about how the union construct was designed.
What I did say was that it was expected that unions would be used
for type punning, and that expectation was evident long before the
first C standard.  It isn't relevant to what I was saying whether
unions were designed that way or not.

[toc] | [prev] | [next] | [standalone]

#87098

On Thursday, October 20, 2022 at 1:21:25 AM UTC-4, Lynn McGuire wrote:
> On 10/19/2022 9:40 PM, daniel...@gmail.com wrote: 
> > On Wednesday, October 19, 2022 at 10:01:35 PM UTC-4, Lynn McGuire wrote: 
> > 
> >> longint nfac [8]; 
> >> fem::str <8> * nfac_str = (fem::str <8> *) nfac; 
> >> 
> >> fem::str <8> is an 8 character object that acts like a Fortran 
> >> character*8. longint is a long long. 
> >> 
> > I think that's undefined behaviour. 
> > 
> Why ? They are both pointers to 8 byte objects. I am just declaring 
> that I want to use the same address as a 8 byte character string (no 
> null !) or a long long integer. 
> 
ubsan will complain about load of misaligned address. In these cases you
need to use memcpy instead of cast and assignment.

See https://stackoverflow.com/questions/47619944/load-of-misaligned-address-and-ubsan-finding

[toc] | [prev] | [next] | [standalone]

#87082

On 10/19/2022 7:01 PM, Lynn McGuire wrote:
> I put the following cast into my code and one of my programmers wants me 
> to use static cast.  Why ?
>     https://en.cppreference.com/w/cpp/language/static_cast
> 
>     longint nfac [8];
>     fem::str <8> * nfac_str = (fem::str <8> *) nfac;
> 
> fem::str <8> is an 8 character object that acts like a Fortran 
> character*8.  longint is a long long.
> 

`static_cast`? `static_cast` cannot do this. One of your programmers 
probably meant `reinterpret_cast`. That would still be barely kosher 
assuming the resultant type is actually an array of `[signed/unsigned] 
char`.

In reality you need `std::bit_cast` here (C++20). Or the good old 
`std::memcpy`.

-- 
Best regards,
Andrey.

[toc] | [prev] | [next] | [standalone]

#87085

Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> I put the following cast into my code and one of my programmers wants me 
> to use static cast.  Why ?

static_cast protects you from accidentally converting between incompatible
types. (If you don't intend to convert between incompatible types, yet that
still happens, it's most certainly a bug.)

If you intentionally do want to convert between incompatible types, it's
a good idea to use reinterpret_cast instead of a C style cast. That's
because it expresses intent better (it kind of self-documents the code
saying "yes, I intend to cast between incompatible types here, it's
not an oversight or error"). It also makes it easier to find such
casts in the code.

(Also, I believe reinterpret_cast is still more restrictive than a
C style cast. I think it doesn't allow you to remove constness, which
is also a good idea even when converting between incompatible types.
Accidentally removing constness can easily change a well-defined
behavior into undefined.)

>    https://en.cppreference.com/w/cpp/language/static_cast
> 
>    longint nfac [8];
>    fem::str <8> * nfac_str = (fem::str <8> *) nfac;
> 
> fem::str <8> is an 8 character object that acts like a Fortran 
> character*8.  longint is a long long.

Technically speaking that's UB, but I'm not aware of any modern system
it will cause problems. Well, at least if you use a proper 'alignas'
qualifier with that 'nfac'. (Since the type is long long, the alignas
might be superfluous, but it doesn't hurt.)

[toc] | [prev] | [next] | [standalone]

#87093

>> I put the following cast into my code and one of my programmers wants 
me 
>> to use static cast.  Why ?
> 
> static_cast protects you from accidentally converting between 
incompatible
> types. (If you don't intend to convert between incompatible types, yet 
that
> still happens, it's most certainly a bug.)
> 
> If you intentionally do want to convert between incompatible types, it's
> a good idea to use reinterpret_cast instead of a C style cast. That's
> because it expresses intent better (it kind of self-documents the code
> saying "yes, I intend to cast between incompatible types here, it's
> not an oversight or error"). It also makes it easier to find such
> casts in the code.

This is the correct answer. The C-style cast is one cast to rule them all. 
You can do things you don't intend to with it (e.g., cast away qualifiers) 
and your compiler won't stop you. If you try to do the wrong thing with 
static/dynamic/const/reinterpret casts you will get an error. Do what you 
prefer but if you have to ask why one would use a static_cast then I think 
the C++ casts are preferable.

[toc] | [prev] | [next] | [standalone]

#87095

Especially dynamic_cast can help alot, because we might make human 
mistakes in polymorhism.

On 20/10/2022 17:50, Gawr Gura wrote:
casts in the code.
> 
> This is the correct answer. The C-style cast is one cast to rule them all.
> You can do things you don't intend to with it (e.g., cast away qualifiers)
> and your compiler won't stop you. If you try to do the wrong thing with
> static/dynamic/const/reinterpret casts you will get an error. Do what you
> prefer but if you have to ask why one would use a static_cast then I think
> the C++ casts are preferable.
> 

[toc] | [prev] | [next] | [standalone]

#87087

Am 20.10.2022 um 04:01 schrieb Lynn McGuire:
> I put the following cast into my code and one of my programmers wants me 
> to use static cast.  Why ?
>     https://en.cppreference.com/w/cpp/language/static_cast
> 
>     longint nfac [8];
>     fem::str <8> * nfac_str = (fem::str <8> *) nfac;
> 
> fem::str <8> is an 8 character object that acts like a Fortran 
> character*8.  longint is a long long.
> 
> Thanks,
> Lynn

I don't use static-cast at all. It provides some kind of child
proof lock in a a sense that you can less mistakes because you
can only convert to in a compatible type, but this never happened
to me before and normal C-style casts are readable better for me.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web