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

#87094

but boost::numberi_cast is something to consider, because it checks 
more... it checks if the number is valid in the conversation.

On 20/10/2022 09:52, Bonita Montero wrote:
> 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]

#87092

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.

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

#87096

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.

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

#87097

JiiPee <kerrttuPoistaTama11@gmail.com> writes:
>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.

dynamic_cast provides some level of introspection, which can
be useful; albeit at a small cost (for the typeid metadata).

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

#87099

On 20/10/2022 18:01, Scott Lurndal wrote:
> dynamic_cast provides some level of introspection, which can
> be useful; albeit at a small cost (for the typeid metadata).

sure, although about 99.9% in cases the speed is not an issue in these 
object oriented programs. But sure, if speed is in essence, one should 
consider not using it.

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

#87101

JiiPee <kerrttuPoistaTama11@gmail.com> writes:
>On 20/10/2022 18:01, Scott Lurndal wrote:
>> dynamic_cast provides some level of introspection, which can
>> be useful; albeit at a small cost (for the typeid metadata).
>
>sure, although about 99.9% in cases the speed is not an issue in these 
>object oriented programs.

I would argue against this viewpoint, myself.

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

#87105

On 20/10/2022 19:07, Scott Lurndal wrote:
> I would argue against this viewpoint, myself.

I mean, using static_cast is not slowing down a program in about  99.9% 
of cases against not using it. Talking about the slowness of static cast 
here. But of course I would not put a static cast in a tight loop 
looping millions of things a second.

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

#87106

JiiPee <kerrttuPoistaTama11@gmail.com> writes:
>On 20/10/2022 19:07, Scott Lurndal wrote:
>> I would argue against this viewpoint, myself.
>
>I mean, using static_cast is not slowing down a program in about  99.9% 
>of cases against not using it. Talking about the slowness of static cast 
>here. But of course I would not put a static cast in a tight loop 
>looping millions of things a second.

static_cast is an annotation.  It should not cause any significant
differences in the generated code.  dynamic_cast, on the other
hand, will at a minimum add a lookup to the typeinfo.

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

#87107

On 20/10/2022 20:30, Scott Lurndal wrote:
> static_cast is an annotation.  It should not cause any significant
> differences in the generated code.  dynamic_cast, on the other
> hand, will at a minimum add a lookup to the typeinfo.

sorry mistake, I meant dynamic_cast. But the code I have been doing and 
seen, I rarely see a place where dynamic cast would slow down 
signifantly. Because many of the loops are looping something maybe 
20-100 times so it does not slow down significantly there.

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

#87122

On 10/20/2022 12:14 PM, JiiPee wrote:
> On 20/10/2022 19:07, Scott Lurndal wrote:
>> I would argue against this viewpoint, myself.
> 
> I mean, using static_cast is not slowing down a program in about  99.9% 
> of cases against not using it. Talking about the slowness of static cast 
> here. But of course I would not put a static cast in a tight loop 
> looping millions of things a second.

I am always concerned about speed.  My calculation engine needs to have 
responses in seconds if needful for large online rotating equipment up 
to 55,000 hp in size.

My other case is the endless recycle calculations of refinery or large 
natural gas plants that can go 20 or 30 minute on a modern 4 Ghz cpu.

When we finish our C++ port then we will be looking at selected speedups 
using limited parallelization and memset.

Lynn

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

#87124

On 21/10/2022 22:05, Lynn McGuire wrote:
>> I mean, using static_cast is not slowing down a program in about  
>> 99.9% of cases against not using it. Talking about the slowness of 
>> static cast here. But of course I would not put a static cast in a 
>> tight loop looping millions of things a second.
> 
> I am always concerned about speed.

IN my coding, also professional, very rarely this kind of thing would 
slow down essentially. I have very rarely time critical situations.

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

#87125

On 21/10/2022 22:05, Lynn McGuire wrote:
> I am always concerned about speed.

Me also if needed. But... for example in a user interface programming 
speed it not important. I mean, when opening a dialog box takes 0.0001 
seconds or 0.0002 seconds makes no difference :). And I am mostly doing 
this kind of programming, when small things are processed.

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

#87135

On 10/22/2022 12:47 AM, JiiPee wrote:
> On 21/10/2022 22:05, Lynn McGuire wrote:
>> I am always concerned about speed.
> 
> Me also if needed. But... for example in a user interface programming 
> speed it not important. I mean, when opening a dialog box takes 0.0001 
> seconds or 0.0002 seconds makes no difference :). And I am mostly doing 
> this kind of programming, when small things are processed.

I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering 
software application to pure C++.  I am trying to not lose any speed in 
the process.

Thanks,
Lynn

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

#87139

On Sat, 22 Oct 2022 15:03:44 -0500
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>On 10/22/2022 12:47 AM, JiiPee wrote:
>> On 21/10/2022 22:05, Lynn McGuire wrote:
>>> I am always concerned about speed.
>> 
>> Me also if needed. But... for example in a user interface programming 
>> speed it not important. I mean, when opening a dialog box takes 0.0001 
>> seconds or 0.0002 seconds makes no difference :). And I am mostly doing 
>> this kind of programming, when small things are processed.
>
>I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering 
>software application to pure C++.  I am trying to not lose any speed in 
>the process.

700K lines?? Unless you have some autotranslation tool you'll reach retirement 
age long before you've finished so the speed will be someone elses problem.

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

#87140

On 23/10/2022 10:35, Muttley@dastardlyhq.com wrote:
> speed will be someone elses problem.

Yes, optimization is not always the first thing to do. although surely 
good to keep in mind when developing that makes it easy to change later 
on faster.

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

#87144

On 10/23/2022 2:35 AM, Muttley@dastardlyhq.com wrote:
> On Sat, 22 Oct 2022 15:03:44 -0500
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>> On 10/22/2022 12:47 AM, JiiPee wrote:
>>> On 21/10/2022 22:05, Lynn McGuire wrote:
>>>> I am always concerned about speed.
>>>
>>> Me also if needed. But... for example in a user interface programming
>>> speed it not important. I mean, when opening a dialog box takes 0.0001
>>> seconds or 0.0002 seconds makes no difference :). And I am mostly doing
>>> this kind of programming, when small things are processed.
>>
>> I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering
>> software application to pure C++.  I am trying to not lose any speed in
>> the process.
> 
> 700K lines?? Unless you have some autotranslation tool you'll reach retirement
> age long before you've finished so the speed will be someone elses problem.

I am using a very customized version of the good old f2c tool.   I have 
converted 8,000 lines so far in two weeks.

Lynn

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

#87143

On 10/22/2022 10:03 PM, Lynn McGuire wrote:
> On 10/22/2022 12:47 AM, JiiPee wrote:
>> On 21/10/2022 22:05, Lynn McGuire wrote:
>>> I am always concerned about speed.
>>
>> Me also if needed. But... for example in a user interface programming 
>> speed it not important. I mean, when opening a dialog box takes 0.0001 
>> seconds or 0.0002 seconds makes no difference :). And I am mostly 
>> doing this kind of programming, when small things are processed.
> 
> I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering 
> software application to pure C++.

This sounds even more as a reason to get to very stable C++ in the 
process. I'd not want to have any chance of obscure UB hidden deeply in 
the result code.

Which begs the question from the original post:

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

Is the cast to/from 8 char string and long long really the best you want 
here?
Unless I am missing something, if you want e.g. to compare those 
strings, I'd expect that in any decent implementation memcmp is 
optimized just fine.

   I am trying to not lose any speed in
> the process.

Sure, but correctness always comes first.

> 
> Thanks,
> Lynn

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

#87145

On Saturday, October 22, 2022 at 11:04:09 PM UTC+3, Lynn McGuire wrote:
> On 10/22/2022 12:47 AM, JiiPee wrote: 
> > On 21/10/2022 22:05, Lynn McGuire wrote: 
> >> I am always concerned about speed. 
> > 
> > Me also if needed. But... for example in a user interface programming 
> > speed it not important. I mean, when opening a dialog box takes 0.0001 
> > seconds or 0.0002 seconds makes no difference :). And I am mostly doing 
> > this kind of programming, when small things are processed.
> I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering 
> software application to pure C++. I am trying to not lose any speed in 
> the process. 
> 
> Thanks, 
> Lynn

What is your motivation for such huge effort?
What's wrong with Fortran 77 as long as it is working?
And *if* there is really something wrong with working Fortran 77,
then why do you port to C++?
Is not it easier to port to Modern Fortran (F20xx) or, may be, to port 
majority of code to Modern Fortran and minority to Julia ?

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

#87148

On 10/23/2022 5:04 PM, Michael S wrote:
> On Saturday, October 22, 2022 at 11:04:09 PM UTC+3, Lynn McGuire wrote:
>> On 10/22/2022 12:47 AM, JiiPee wrote:
>>> On 21/10/2022 22:05, Lynn McGuire wrote:
>>>> I am always concerned about speed.
>>>
>>> Me also if needed. But... for example in a user interface programming
>>> speed it not important. I mean, when opening a dialog box takes 0.0001
>>> seconds or 0.0002 seconds makes no difference :). And I am mostly doing
>>> this kind of programming, when small things are processed.
>> I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering
>> software application to pure C++. I am trying to not lose any speed in
>> the process.
>>
>> Thanks,
>> Lynn
> 
> What is your motivation for such huge effort?
> What's wrong with Fortran 77 as long as it is working?
> And *if* there is really something wrong with working Fortran 77,
> then why do you port to C++?
> Is not it easier to port to Modern Fortran (F20xx) or, may be, to port
> majority of code to Modern Fortran and minority to Julia ?

The maintenance on the mixed code is becoming cumbersome.  And I cannot 
find a good Fortran / C++ compiler mix that meets my needs.  And I need 
a 64 bit version of our software yesterday.  Seven of my users have now 
tried to move to 64 bit Excel.

I prefer C++.  I've been programming in Fortran since 1975, Pascal since 
1983, C since 1987, Smalltalk since 1993, and C++ since 1999.  I will 
miss Fortran but not totally since we have a Fortran interpreter 
embedded in our software since 1983.

I and two of my programmers converted our Smalltalk Windows user 
interface to C++ in 2001/2002.  The port was great, the code base only 
increased from 250,000 lines to 350,000 lines.

Lynn

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

#87117

Am 20.10.2022 um 17:32 schrieb JiiPee:

> sure, although about 99.9% in cases the speed is not an issue in these 
> object oriented programs. But sure, if speed is in essence, one should 
> consider not using it.

That's nonsense. OOP doesn't cost more than procedural programming since
with the latter you have context like this also. Virtual functions have
some slight overhead but it is very small.

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

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

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

csiph-web