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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#87118

Am 20.10.2022 um 16:55 schrieb JiiPee:
> On 20/10/2022 16:55, Scott Lurndal wrote:
>> Young C++ programmers don't understand C, so they think
>> that static_cast<fem::str<8>*> is more "readable". Heh.
> 
> its surely not more readable.
> but dynamic_cast is surely useful checking class hierarkies.

A virtual function that gives some type-capabiliy information
is usually much faster.

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

#87108

On 10/20/2022 8:55 AM, Scott Lurndal wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> 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.
>>
> 
> Young C++ programmers don't understand C, so they think
> that static_cast<fem::str<8>*> is more "readable". Heh.

The programmer in question is 39 and has been writing C and C++ since he 
was 13 or 14.

His actual comment was that static_cast's are easier to grep which I 
find hard to believe.

Thanks,
Lynn

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

#87111

On 10/20/2022 8:21 PM, Lynn McGuire wrote:
> On 10/20/2022 8:55 AM, Scott Lurndal wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>> 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.
>>>
>>
>> Young C++ programmers don't understand C, so they think
>> that static_cast<fem::str<8>*> is more "readable". Heh.
> 
> The programmer in question is 39 and has been writing C and C++ since he 
> was 13 or 14.
> 
> His actual comment was that static_cast's are easier to grep which I 
> find hard to believe.

If by grep you mean grep(1), then yes, static_cast is definitely easier 
to grep than a C-style cast.
However, the advantage of reinterpret_cast (static_cast wouldn't work) 
is not that it is more readable. It is that it hurts the eye.

Depending on which compiler you use, I'd verify that what you intend to 
do actually works. As far as the standard is concerned, at least one 
necessary condition is that fem::str<8> is effectively an unsigned char[8].
Otherwise it's UB unless your compiler says otherwise (although it 
probably Just Works on any of them, in practice.)

> 
> Thanks,
> Lynn

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

#87121

On 10/20/2022 10:52 PM, Manfred wrote:
> On 10/20/2022 8:21 PM, Lynn McGuire wrote:
>> On 10/20/2022 8:55 AM, Scott Lurndal wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>> 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.
>>>>
>>>
>>> Young C++ programmers don't understand C, so they think
>>> that static_cast<fem::str<8>*> is more "readable". Heh.
>>
>> The programmer in question is 39 and has been writing C and C++ since 
>> he was 13 or 14.
>>
>> His actual comment was that static_cast's are easier to grep which I 
>> find hard to believe.
> 
> If by grep you mean grep(1), then yes, static_cast is definitely easier 
> to grep than a C-style cast.
> However, the advantage of reinterpret_cast (static_cast wouldn't work) 
> is not that it is more readable. It is that it hurts the eye.
> 
> Depending on which compiler you use, I'd verify that what you intend to 
> do actually works. As far as the standard is concerned, at least one 
> necessary condition is that fem::str<8> is effectively an unsigned char[8].
> Otherwise it's UB unless your compiler says otherwise (although it 
> probably Just Works on any of them, in practice.)
> 
>>
>> Thanks,
>> Lynn

I am using Visual Studio 2015 on Windows 10 Pro x64.

fem::str<8> is an array of unsigned char [8] that I pass around the 
place to hold a Fortran string of given length that is blank filled 
rather than null terminated.
    https://cci.lbl.gov/fable/sources/fable/fem/str.hpp

And yes, I will be able to tell rather quickly if the cast is working 
properly or not.  I am minimizing usage though as I prefer char * and 
std::string.

Thanks,
Lynn

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

#87133

On 2022-10-21 at 20:59, Lynn McGuire wrote:
> On 10/20/2022 10:52 PM, Manfred wrote:
>> On 10/20/2022 8:21 PM, Lynn McGuire wrote:
>>> On 10/20/2022 8:55 AM, Scott Lurndal wrote:
>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>>> 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.
>>>>>
>>>>
>>>> Young C++ programmers don't understand C, so they think
>>>> that static_cast<fem::str<8>*> is more "readable". Heh.
>>>
>>> The programmer in question is 39 and has been writing C and C++ since 
>>> he was 13 or 14.
>>>
>>> His actual comment was that static_cast's are easier to grep which I 
>>> find hard to believe.
>>
>> If by grep you mean grep(1), then yes, static_cast is definitely 
>> easier to grep than a C-style cast.
>> However, the advantage of reinterpret_cast (static_cast wouldn't work) 
>> is not that it is more readable. It is that it hurts the eye.
>>
>> Depending on which compiler you use, I'd verify that what you intend 
>> to do actually works. As far as the standard is concerned, at least 
>> one necessary condition is that fem::str<8> is effectively an unsigned 
>> char[8].
>> Otherwise it's UB unless your compiler says otherwise (although it 
>> probably Just Works on any of them, in practice.)
>>
>>>
>>> Thanks,
>>> Lynn
> 
> I am using Visual Studio 2015 on Windows 10 Pro x64.
> 
> fem::str<8> is an array of unsigned char [8] that I pass around the 
> place to hold a Fortran string of given length that is blank filled 
> rather than null terminated.
>     https://cci.lbl.gov/fable/sources/fable/fem/str.hpp
> 
> And yes, I will be able to tell rather quickly if the cast is working 
> properly or not.  I am minimizing usage though as I prefer char * and 
> std::string.
> 

If it is always 8 bytes, I would use memcpy between two buffers and skip 
the pointer indirection.

The memcpy based implementation of C++20 bit_cast, as shown here

https://en.cppreference.com/w/cpp/numeric/bit_cast

is known to inline and optimize into

mov rax, From

for 64-bit values on common 64-bit compilers.

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

#87136

On 10/22/2022 11:31 AM, Bo Persson wrote:
> On 2022-10-21 at 20:59, Lynn McGuire wrote:
>> On 10/20/2022 10:52 PM, Manfred wrote:
>>> On 10/20/2022 8:21 PM, Lynn McGuire wrote:
>>>> On 10/20/2022 8:55 AM, Scott Lurndal wrote:
>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Young C++ programmers don't understand C, so they think
>>>>> that static_cast<fem::str<8>*> is more "readable". Heh.
>>>>
>>>> The programmer in question is 39 and has been writing C and C++ 
>>>> since he was 13 or 14.
>>>>
>>>> His actual comment was that static_cast's are easier to grep which I 
>>>> find hard to believe.
>>>
>>> If by grep you mean grep(1), then yes, static_cast is definitely 
>>> easier to grep than a C-style cast.
>>> However, the advantage of reinterpret_cast (static_cast wouldn't 
>>> work) is not that it is more readable. It is that it hurts the eye.
>>>
>>> Depending on which compiler you use, I'd verify that what you intend 
>>> to do actually works. As far as the standard is concerned, at least 
>>> one necessary condition is that fem::str<8> is effectively an 
>>> unsigned char[8].
>>> Otherwise it's UB unless your compiler says otherwise (although it 
>>> probably Just Works on any of them, in practice.)
>>>
>>>>
>>>> Thanks,
>>>> Lynn
>>
>> I am using Visual Studio 2015 on Windows 10 Pro x64.
>>
>> fem::str<8> is an array of unsigned char [8] that I pass around the 
>> place to hold a Fortran string of given length that is blank filled 
>> rather than null terminated.
>>     https://cci.lbl.gov/fable/sources/fable/fem/str.hpp
>>
>> And yes, I will be able to tell rather quickly if the cast is working 
>> properly or not.  I am minimizing usage though as I prefer char * and 
>> std::string.
>>
> 
> If it is always 8 bytes, I would use memcpy between two buffers and skip 
> the pointer indirection.
> 
> The memcpy based implementation of C++20 bit_cast, as shown here
> 
> https://en.cppreference.com/w/cpp/numeric/bit_cast
> 
> is known to inline and optimize into
> 
> mov rax, From
> 
> for 64-bit values on common 64-bit compilers.

Nope, that is a lot of extra work for the thousands of places that this 
interaction occurs.

Thanks,
Lynn

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

#87138

On 10/22/2022 11:31 AM, Bo Persson wrote:
> On 2022-10-21 at 20:59, Lynn McGuire wrote:
>> On 10/20/2022 10:52 PM, Manfred wrote:
>>> On 10/20/2022 8:21 PM, Lynn McGuire wrote:
>>>> On 10/20/2022 8:55 AM, Scott Lurndal wrote:
>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Young C++ programmers don't understand C, so they think
>>>>> that static_cast<fem::str<8>*> is more "readable". Heh.
>>>>
>>>> The programmer in question is 39 and has been writing C and C++ 
>>>> since he was 13 or 14.
>>>>
>>>> His actual comment was that static_cast's are easier to grep which I 
>>>> find hard to believe.
>>>
>>> If by grep you mean grep(1), then yes, static_cast is definitely 
>>> easier to grep than a C-style cast.
>>> However, the advantage of reinterpret_cast (static_cast wouldn't 
>>> work) is not that it is more readable. It is that it hurts the eye.
>>>
>>> Depending on which compiler you use, I'd verify that what you intend 
>>> to do actually works. As far as the standard is concerned, at least 
>>> one necessary condition is that fem::str<8> is effectively an 
>>> unsigned char[8].
>>> Otherwise it's UB unless your compiler says otherwise (although it 
>>> probably Just Works on any of them, in practice.)
>>>
>>>>
>>>> Thanks,
>>>> Lynn
>>
>> I am using Visual Studio 2015 on Windows 10 Pro x64.
>>
>> fem::str<8> is an array of unsigned char [8] that I pass around the 
>> place to hold a Fortran string of given length that is blank filled 
>> rather than null terminated.
>>     https://cci.lbl.gov/fable/sources/fable/fem/str.hpp
>>
>> And yes, I will be able to tell rather quickly if the cast is working 
>> properly or not.  I am minimizing usage though as I prefer char * and 
>> std::string.
>>
> 
> If it is always 8 bytes, I would use memcpy between two buffers and skip 
> the pointer indirection.
> 
> The memcpy based implementation of C++20 bit_cast, as shown here
> 
> https://en.cppreference.com/w/cpp/numeric/bit_cast
> 
> is known to inline and optimize into
> 
> mov rax, From
> 
> for 64-bit values on common 64-bit compilers.

But, I will keep it in mind for the future.

Our memory sharing technology was developed back in the late 1970s when 
we were having severe memory problems on the mainframes.  Over the 
years, we used it all over the place.   We create 300 to 20,000 (depends 
on size of the simulation) memory blocks that we use all over the place 
for each software run.

Thanks,
Lynn

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

#87204

Manfred <noname@add.invalid> writes:

> On 10/20/2022 8:21 PM, Lynn McGuire wrote:
>
>> On 10/20/2022 8:55 AM, Scott Lurndal wrote:
>>
>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>
>>>> 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.
>>>
>>> Young C++ programmers don't understand C, so they think
>>> that static_cast<fem::str<8>*> is more "readable".  Heh.
>>
>> The programmer in question is 39 and has been writing C and C++
>> since he was 13 or 14.
>>
>> His actual comment was that static_cast's are easier to grep which I
>> find hard to believe.
>
> If by grep you mean grep(1), then yes, static_cast is definitely
> easier to grep than a C-style cast.
> However, the advantage of reinterpret_cast (static_cast wouldn't work)
> is not that it is more readable.  It is that it hurts the eye.
>
> Depending on which compiler you use, I'd verify that what you intend
> to do actually works.  As far as the standard is concerned, at least
> one necessary condition is that fem::str<8> is effectively an unsigned
> char[8].
> Otherwise it's UB unless your compiler says otherwise (although it
> probably Just Works on any of them, in practice.)

If a construct is described by the standard as being undefined
behavior, said construct is still undefined behavior no matter
what the implementation does.  The condition of being undefined
behavior is only a statement of what is mandated (or not) by
the standard;  it has nothing to do with whether something
"defines" the behavior.

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

#87208

On Thursday, 3 November 2022 at 02:54:58 UTC+2, Tim Rentsch wrote:
> Manfred <non...@add.invalid> writes: 
> 
> > On 10/20/2022 8:21 PM, Lynn McGuire wrote: 
> > 
> >> On 10/20/2022 8:55 AM, Scott Lurndal wrote: 
> >> 
> >>> Lynn McGuire <lynnmc...@gmail.com> writes: 
> >>> 
> >>>> 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. 
> >>> 
> >>> Young C++ programmers don't understand C, so they think 
> >>> that static_cast<fem::str<8>*> is more "readable". Heh. 
> >> 
> >> The programmer in question is 39 and has been writing C and C++ 
> >> since he was 13 or 14. 
> >> 
> >> His actual comment was that static_cast's are easier to grep which I 
> >> find hard to believe. 
> > 
> > If by grep you mean grep(1), then yes, static_cast is definitely 
> > easier to grep than a C-style cast. 
> > However, the advantage of reinterpret_cast (static_cast wouldn't work) 
> > is not that it is more readable. It is that it hurts the eye. 
> > 
> > Depending on which compiler you use, I'd verify that what you intend 
> > to do actually works. As far as the standard is concerned, at least 
> > one necessary condition is that fem::str<8> is effectively an unsigned 
> > char[8]. 
> > Otherwise it's UB unless your compiler says otherwise (although it 
> > probably Just Works on any of them, in practice.)
> 
> If a construct is described by the standard as being undefined 
> behavior, said construct is still undefined behavior no matter 
> what the implementation does. The condition of being undefined 
> behavior is only a statement of what is mandated (or not) by 
> the standard; it has nothing to do with whether something 
> "defines" the behavior.

The effect of undefined behavior is that compilers are allowed
to do whatever these please when running a program that contains it
as far C++ standard is concerned. However if particular compiler
documents outcome of particular situation (described as undefined
behavior by standard) more narrowly then that compiler can't anymore
do whatever it pleases without contradicting its documentation.
So the effect is gone ... whatever words one uses about it does not
matter.

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

#87405

Tiib <ootiib@hot.ee> writes:

> On Thursday, 3 November 2022 at 02:54:58 UTC+2, Tim Rentsch wrote:
>
>> Manfred <non...@add.invalid> writes:
>>
>>> On 10/20/2022 8:21 PM, Lynn McGuire wrote:
>>>
>>>> On 10/20/2022 8:55 AM, Scott Lurndal wrote:
>>>>
>>>>> Lynn McGuire <lynnmc...@gmail.com> writes:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Young C++ programmers don't understand C, so they think
>>>>> that static_cast<fem::str<8>*> is more "readable".  Heh.
>>>>
>>>> The programmer in question is 39 and has been writing C and C++
>>>> since he was 13 or 14.
>>>>
>>>> His actual comment was that static_cast's are easier to grep which I
>>>> find hard to believe.
>>>
>>> If by grep you mean grep(1), then yes, static_cast is definitely
>>> easier to grep than a C-style cast.
>>> However, the advantage of reinterpret_cast (static_cast wouldn't work)
>>> is not that it is more readable.  It is that it hurts the eye.
>>>
>>> Depending on which compiler you use, I'd verify that what you intend
>>> to do actually works.  As far as the standard is concerned, at least
>>> one necessary condition is that fem::str<8> is effectively an unsigned
>>> char[8].
>>> Otherwise it's UB unless your compiler says otherwise (although it
>>> probably Just Works on any of them, in practice.)
>>
>> If a construct is described by the standard as being undefined
>> behavior, said construct is still undefined behavior no matter
>> what the implementation does.  The condition of being undefined
>> behavior is only a statement of what is mandated (or not) by
>> the standard;  it has nothing to do with whether something
>> "defines" the behavior.
>
> The effect of undefined behavior [...]

Undefined behavior is a classification;  it doesn't have effects.
Moreover the classification holds regardless of how an
implementation might treat constructs that are so classified.

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

#87409

On Wednesday, 16 November 2022 at 02:19:46 UTC+2, Tim Rentsch wrote:
> Tiib <oot...@hot.ee> writes: 
> 
> > On Thursday, 3 November 2022 at 02:54:58 UTC+2, Tim Rentsch wrote: 
> > 
> >> Manfred <non...@add.invalid> writes: 
> >> 
> >>> On 10/20/2022 8:21 PM, Lynn McGuire wrote: 
> >>> 
> >>>> On 10/20/2022 8:55 AM, Scott Lurndal wrote: 
> >>>> 
> >>>>> Lynn McGuire <lynnmc...@gmail.com> writes: 
> >>>>> 
> >>>>>> 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. 
> >>>>> 
> >>>>> Young C++ programmers don't understand C, so they think 
> >>>>> that static_cast<fem::str<8>*> is more "readable". Heh. 
> >>>> 
> >>>> The programmer in question is 39 and has been writing C and C++ 
> >>>> since he was 13 or 14. 
> >>>> 
> >>>> His actual comment was that static_cast's are easier to grep which I 
> >>>> find hard to believe. 
> >>> 
> >>> If by grep you mean grep(1), then yes, static_cast is definitely 
> >>> easier to grep than a C-style cast. 
> >>> However, the advantage of reinterpret_cast (static_cast wouldn't work) 
> >>> is not that it is more readable. It is that it hurts the eye. 
> >>> 
> >>> Depending on which compiler you use, I'd verify that what you intend 
> >>> to do actually works. As far as the standard is concerned, at least 
> >>> one necessary condition is that fem::str<8> is effectively an unsigned 
> >>> char[8]. 
> >>> Otherwise it's UB unless your compiler says otherwise (although it 
> >>> probably Just Works on any of them, in practice.) 
> >> 
> >> If a construct is described by the standard as being undefined 
> >> behavior, said construct is still undefined behavior no matter 
> >> what the implementation does. The condition of being undefined 
> >> behavior is only a statement of what is mandated (or not) by 
> >> the standard; it has nothing to do with whether something 
> >> "defines" the behavior. 
> >
> > The effect of undefined behavior [...] 
> 
> Undefined behavior is a classification; it doesn't have effects. 

You managed  to read 5 words?
I meant effect to people/organizations who implement a 
compiler as specified by standard. 

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

#87489

Tiib <ootiib@hot.ee> writes:

> On Wednesday, 16 November 2022 at 02:19:46 UTC+2, Tim Rentsch wrote:
>
>> Tiib <oot...@hot.ee> writes:
>>
>>> On Thursday, 3 November 2022 at 02:54:58 UTC+2, Tim Rentsch wrote:
>>>
>>>> Manfred <non...@add.invalid> writes:
>>>>
>>>>> On 10/20/2022 8:21 PM, Lynn McGuire wrote:
>>>>>
>>>>>> On 10/20/2022 8:55 AM, Scott Lurndal wrote:
>>>>>>
>>>>>>> Lynn McGuire <lynnmc...@gmail.com> writes:
>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> Young C++ programmers don't understand C, so they think
>>>>>>> that static_cast<fem::str<8>*> is more "readable".  Heh.
>>>>>>
>>>>>> The programmer in question is 39 and has been writing C and C++
>>>>>> since he was 13 or 14.
>>>>>>
>>>>>> His actual comment was that static_cast's are easier to grep
>>>>>> which I find hard to believe.
>>>>>
>>>>> If by grep you mean grep(1), then yes, static_cast is definitely
>>>>> easier to grep than a C-style cast.  However, the advantage of
>>>>> reinterpret_cast (static_cast wouldn't work) is not that it is
>>>>> more readable.  It is that it hurts the eye.
>>>>>
>>>>> Depending on which compiler you use, I'd verify that what you
>>>>> intend to do actually works.  As far as the standard is
>>>>> concerned, at least one necessary condition is that fem::str<8>
>>>>> is effectively an unsigned char[8].
>>>>> Otherwise it's UB unless your compiler says otherwise (although
>>>>> it probably Just Works on any of them, in practice.)
>>>>
>>>> If a construct is described by the standard as being undefined
>>>> behavior, said construct is still undefined behavior no matter
>>>> what the implementation does.  The condition of being undefined
>>>> behavior is only a statement of what is mandated (or not) by
>>>> the standard;  it has nothing to do with whether something
>>>> "defines" the behavior.
>>>
>>> The effect of undefined behavior [...]
>>
>> Undefined behavior is a classification;  it doesn't have effects.
>
> You managed  to read 5 words?
> I meant [...]

If you can't be bothered to say what you mean in the first
place, don't expect people to waste their time trying to
figure out what you do mean.

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

#87490

On 20 Nov 2022 14:59, Tim Rentsch wrote:
> Tiib <ootiib@hot.ee> writes:
>> [snip]
>>
>> You managed  to read 5 words?
>> I meant [...]
> 
> If you can't be bothered to say what you mean in the first
> place, don't expect people to waste their time trying to
> figure out what you do mean.

It's silly of you to pretend that you read just the first 5 words of a 
sentence.

Even more silly to turn that around and demand that any contributor here 
should sum up what they mean in the first 5 words of each sentence, 
presumably with the rest of each sentence clarifying the first 5 words.

That position reminds me of Molbo-land, Moronia, Infantilia and other 
such places.


- Alf

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

#87492

"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:

> On 20 Nov 2022 14:59, Tim Rentsch wrote:
>
>> Tiib <ootiib@hot.ee> writes:
>>
>>> [snip]
>>>
>>> You managed  to read 5 words?
>>> I meant [...]
>>
>> If you can't be bothered to say what you mean in the first
>> place, don't expect people to waste their time trying to
>> figure out what you do mean.
>
> It's silly of you to pretend that you read just the first 5 words of a
> sentence.

I am neither claiming nor pretending that I read only the first
five words of Tiib's comment.  Those words are simply all that I
was responding to.

When given a bad omelette, I don't need to eat the whole thing to
discover it is bad.

> [...]

The rest of what you wrote seems irrelevant since your initial
assumption was wrong.  In most cases it's better if you don't
read things into what I say that aren't there.

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

#87493

On Sunday, 20 November 2022 at 17:23:06 UTC+2, Tim Rentsch wrote:
> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes: 
> 
> > On 20 Nov 2022 14:59, Tim Rentsch wrote: 
> > 
> >> Tiib <oot...@hot.ee> writes: 
> >> 
> >>> [snip] 
> >>> 
> >>> You managed to read 5 words? 
> >>> I meant [...] 
> >> 
> >> If you can't be bothered to say what you mean in the first 
> >> place, don't expect people to waste their time trying to 
> >> figure out what you do mean. 
> > 
> > It's silly of you to pretend that you read just the first 5 words of a 
> > sentence.
> I am neither claiming nor pretending that I read only the first 
> five words of Tiib's comment. 

You left such impression. And improved it by saying that if 5
first words do not manage to say everything, then you should
not read rest of the sentence. 

>> Those words are simply all that I  was responding to. 

Your response only misrepresented these five words.

>
> When given a bad omelette, I don't need to eat the whole thing to 
> discover it is bad. 

Look who's talking? What you post is mixture of lies, 
misrepresentations and other sad garbage. Can be you have
nothing better to do but that is not my fault.

> 
> > [...] 
> 
> The rest of what you wrote seems irrelevant since your initial 
> assumption was wrong. In most cases it's better if you don't 
> read things into what I say that aren't there.

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

#88286

Tiib <ootiib@hot.ee> writes:

> On Sunday, 20 November 2022 at 17:23:06 UTC+2, Tim Rentsch wrote:
>
>> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
>>
>>> On 20 Nov 2022 14:59, Tim Rentsch wrote:
>>>
>>>> Tiib <oot...@hot.ee> writes:
>>>>
>>>>> [snip]
>>>>>
>>>>> You managed to read 5 words?
>>>>> I meant [...]
>>>>
>>>> If you can't be bothered to say what you mean in the first
>>>> place, don't expect people to waste their time trying to
>>>> figure out what you do mean.
>>>
>>> It's silly of you to pretend that you read just the first 5 words of a
>>> sentence.
>>
>> I am neither claiming nor pretending that I read only the first
>> five words of Tiib's comment.
>
> You left such impression.

That is your problem, not mine.

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

#87223

Scott Lurndal <scott@slp53.sl.home> wrote:
> Young C++ programmers don't understand C, so they think
> that static_cast<fem::str<8>*> is more "readable". Heh.

So your opinion on what's "readable" and what isn't is better than my
opinion on the subject because... why?

I'm 99% certain that the main (if not even only) reason why you don't like
static_cast is because it's longer. That's it. No other reason.

I have noticed a very common psychological phenomenon that for some
reason beginner programmers try to write code that's as short as possible,
even when that comes at the cost of legibility (a phenomenon that I have
named "the brevity-over-clarity style of programming"). Way too many
programmers never learn out of this bad habit.

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

#87229

Juha Nieminen <nospam@thanks.invalid> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>> Young C++ programmers don't understand C, so they think
>> that static_cast<fem::str<8>*> is more "readable". Heh.
>
>So your opinion on what's "readable" and what isn't is better than my
>opinion on the subject because... why?

It's an opinion.  You know the old saying.

>
>I'm 99% certain that the main (if not even only) reason why you don't like
>static_cast is because it's longer. That's it. No other reason.

Actually, I don't like it because it doesn't add anything useful over
a plain c-style cast.

>
>I have noticed a very common psychological phenomenon that for some
>reason beginner programmers try to write code that's as short as possible,
>even when that comes at the cost of legibility (a phenomenon that I have
>named "the brevity-over-clarity style of programming"). Way too many
>programmers never learn out of this bad habit.

Some of us learned by punching programs on cards and on 110 baud teletypes on computers
with 4k words of memory.   Brevity was to be celebrated.

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

#87261

On 04/11/2022 13:47, Scott Lurndal wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Young C++ programmers don't understand C, so they think
>>> that static_cast<fem::str<8>*> is more "readable". Heh.
>>
>> So your opinion on what's "readable" and what isn't is better than my
>> opinion on the subject because... why?
> 
> It's an opinion.  You know the old saying.
> 
>>
>> I'm 99% certain that the main (if not even only) reason why you don't like
>> static_cast is because it's longer. That's it. No other reason.
> 
> Actually, I don't like it because it doesn't add anything useful over
> a plain c-style cast.
> 
I don't like it because it's longer. But sometimes it is better. You 
know exactly what it will do.

>>
>> I have noticed a very common psychological phenomenon that for some
>> reason beginner programmers try to write code that's as short as possible,
>> even when that comes at the cost of legibility (a phenomenon that I have
>> named "the brevity-over-clarity style of programming"). Way too many
>> programmers never learn out of this bad habit.
> 
> Some of us learned by punching programs on cards and on 110 baud teletypes on computers
> with 4k words of memory.   Brevity was to be celebrated.

You had a card punch? You didn't have to shade in the fields with a 6B 
pencil? Luxury...

I too learned back in the bad old days. These days I can touch type on a 
nice light keyboard I can use for hours. Not like the ASR33 keyboard 
that really needed two fingers to press the keys.

The world is in some ways a better place.

Andy

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

#87266

On 11/4/22 09:47, Scott Lurndal wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
..
>> I'm 99% certain that the main (if not even only) reason why you don't
>> like
>> static_cast is because it's longer. That's it. No other reason.
>
> Actually, I don't like it because it doesn't add anything useful over
> a plain c-style cast.

It's advantage over the plain c-style cast lies in what it won't do: it
won't do any of the things for which const_cast<> or reinterpret_cast<>
are needed instead. It also won't do what dynamic_cast<> does, but
that's also true of the c-style cast.
Particularly in a language that allows overloading and template type
parameters, the consequences of a c-style cast can be hard to
anticipate. The named casts help ensure that only the desired type of
change can occur without triggering a mandatory diagnostic.

>> I have noticed a very common psychological phenomenon that for some
>> reason beginner programmers try to write code that's as short as
>> possible,
>> even when that comes at the cost of legibility (a phenomenon that I have
>> named "the brevity-over-clarity style of programming"). Way too many
>> programmers never learn out of this bad habit.
>
> Some of us learned by punching programs on cards and on 110 baud
> teletypes on computers
> with 4k words of memory. Brevity was to be celebrated.

In 1974 my high school provided computer programming classes, when
almost no one else did, because an alumnus donated a long-obsolete IBM
1620 with a Fortran I compiler, using punched cards and a teletype. It
being a decimal machine, I seem to recall it had 10000 decimal digits of
memory.

While I learned touch typing at an early age, I was always prone to
errors. On punched cards, that meant a lot of wasted cards. Cards that
were correctly punched were a precious resource for me. I took to using
some really bad policies when writing my programs. I used very short
generic variable names, allowing me to re-use them for very different
purposes in different programs. If I typed a variable name incorrectly
on my first try, that incorrect spelling became the new correct spelling
for the variable. I gave statements widely spaced statement numbers,
allowing me to insert new statements between them.

I dropped all of these absurd policies like hot potatoes the instant I
started working on a computer which allowed me to save and edit programs.

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web