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

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

“Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated”

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

Contents

  “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-21 14:04 -0500
    Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-21 12:28 -0700
    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:16 +0000
      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 09:45 +0200
      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:07 -0400
        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:42 +0200
          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 15:24 +0000
            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-09-26 09:00 -0700
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 16:11 +0000
                Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-09-26 09:22 -0700
    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 09:41 +0000
      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:46 +0100
        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 16:15 +0000
        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 20:43 +0200
          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 20:15 +0100
            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 22:56 +0200
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-22 23:15 +0100
                g++ with -O6 slower than with  -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 13:44 +0200
                  Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Bart <bc@freeuk.com> - 2022-09-23 13:53 +0100
                    Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:31 +0200
                  Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:53 +0200
                    Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 16:21 +0200
                      Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-24 17:05 +0200
                        Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] red floyd <no.spam.here@its.invalid> - 2022-09-24 12:33 -0700
                          Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Muttley@dastardlyhq.com - 2022-09-25 08:45 +0000
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 00:08 +0100
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:45 +0000
                Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-23 12:13 +0300
                  Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 10:01 +0000
                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-09-23 03:14 -0700
                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 12:57 -0700
                        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-02 13:53 -0700
                          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-07 16:00 -0700
                            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-08 10:57 -0700
                              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-09 08:33 -0700
                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:58 +0100
                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:03 -0400
                Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:32 +0200
                Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? red floyd <no.spam.here@its.invalid> - 2022-09-23 14:43 -0700
          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:26 +0000
            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:15 +0100
            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-23 12:35 -0700
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-23 12:44 -0700
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:09 +0000
      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 13:25 +0200
        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:13 +0000
          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-26 10:44 -0700
            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:26 +0000
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-09-27 09:56 -0600
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-27 10:50 -0700
      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 01:57 -0400
    Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2022-09-22 14:01 +0000
    Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-23 03:17 +0000
      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:50 +0000
        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:37 +0200
          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:19 +0000
            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 13:55 +0200
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 14:31 +0000
                Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-26 16:05 +0100
                  Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:36 +0000
                Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:21 +0200
                  Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 13:26 +0000
                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-27 16:53 +0200
                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 10:32 +0200
                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 18:18 +0000
                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 01:30 -0400
                        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 08:26 +0000
                          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-28 10:43 +0200
                          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 13:15 -0400
                            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 23:38 +0000
                              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:46 +0200
                                Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-29 17:58 +0000
                                  Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-30 09:17 +0200
                                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 16:39 +0000
                                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-01 12:47 +0200
                                  Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 17:20 +0000
                                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-30 20:59 +0300
                                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 07:31 -0700
                                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 13:38 +0200
                                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-02 13:00 +0100
                                        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 16:20 +0200
                                          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-10-02 22:05 +0200
                                            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-03 11:58 +0200
                                        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 07:24 -0700
                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 09:40 +0200
                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 07:56 -0400
                        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 15:50 +0200
                          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:21 +0000
                            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 16:17 +0000
                              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 16:56 +0000
                                Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-28 20:31 +0200
                                  Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? doctor@doctor.nl2k.ab.ca (The Doctor) - 2022-09-28 21:45 +0000
                            Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:50 +0200
                          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 19:33 -0400
              Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-26 09:04 -0600
                Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:27 +0200
                  Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 08:11 -0600
                    Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:10 +0200
                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 17:30 -0600
                      Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:26 +0000
                        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 11:00 +0200
                          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-28 13:33 +0100
        Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-09-25 19:31 +0200
          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-26 04:53 +0000
          Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 12:59 -0700
    Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Opus <ifonly@youknew.org> - 2022-09-23 18:32 +0200
    Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:08 -0400

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

#86758 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 30/09/2022 19:20, Kaz Kylheku wrote:
> [ Apologies for having had diverted this subthread to comp.lang.c ]
> On 2022-09-29, David Brown <david.brown@hesbynett.no> wrote:
>> On 29/09/2022 19:58, Kaz Kylheku wrote:
>>> On 2022-09-29, David Brown <david.brown@hesbynett.no> wrote:
>>>> On 29/09/2022 01:38, Kaz Kylheku wrote:
>>>>> On 2022-09-28, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>>>> On 9/28/22 04:26, Kaz Kylheku wrote:
>>>>>>> ["Followup-To:" header set to comp.lang.c.]
>>>>>>> On 2022-09-28, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>>>>>> On 9/27/22 20:03, Kaz Kylheku wrote:
>>>>>>>>> On 2022-09-27, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>>>>> ...
>>>>>>>>>> temp1 = complex_expr;
>>>>>>>>>> temp2 = another_complex_expr;
>>>>>>>>>> temp3 = yet_another_complex_expr;
>>>>>>>>>>
>>>>>>>>>> make_object(temp1, temp2, temp3).
>>>>>>>>>
>>>>>>>>> That transformation is the job of the compiler, though.
>>>>>>>>>
>>>>>>>>> It's not practical to do this even in small programs, let alone
>>>>>>>>> ones in which there are millions of function call expressions.
>>>>>>>>
>>>>>>>> You only do it when the order actually matters, not automatically for
>>>>>>>> all function calls.
>>>>>>>
>>>>>>> OK; I still need the compiler to tell me where those places are;
>>>>>>
>>>>>> You've got the communications direction wrong. Writing code that way is
>>>>>> how you tell the compiler that the order matters. Writing it as a simple
>>>>>> function call without explicit temporaries is how you tell the compiler
>>>>>> that you think the order doesn't matter. A good compiler should inform
>>>>>> you if realizes that the assumption is incorrect.
>>>>>
>>>>> Of course, I can tell which is the case by inspection. Problem is,
>>>>> suppose I didn't write the code myself and there are tens of thousands
>>>>> of function calls in it. I can't inspect them all, and so that's why
>>>>> I would need the compiler to tell me where the places are.
>>>>>
>>>>> I suspect that practically achievable diagnostics in this area will
>>>>> yield lots of false positives.
>>>>>
>>>>> For instance, the order probably doesn't matter in code like this:
>>>>>
>>>>>      debug_pf("device %s: status %x\n", dev_name(d), dev_status(d));
>>>>>
>>>>> yet, this code potentially has behavior dependent on the order
>>>>> of the function calls. The functions are external, defined in another
>>>>> translation unit; the compiler has no idea whether they mutate the d
>>>>> object. A diagnostic feature warning about potential side effects in
>>>>> function arguments would have to flag this.
>>>>>
>>>>> Really, the best solution is not to have this class of bug at all
>>>>> by a fixed order of evaluation.
>>>>>
>>>>
>>>> The logical extension of this is saying that when some programmers don't
>>>> understand the language properly, or make unwarranted assumptions, or
>>>> write poor code, you want the language to define away the bugs.
>>>
>>> Well, it does a fair good job of that already, right?. For instance, it
>>> tells you if you're passing a "foo *" pointer to a function that expects
>>> "bar *", or accessing a nonexistent member in a structure instead of just
>>> blindly fetching from that offset, or that you're passing too few or
>>> many arguments and so on.
>>>
>>> Every time you get a diagnostic in any such an area, that's a situation
>>> in which you didn't write correct code, and which would have either not
>>> been caught at all, or possibly very late, like years later in the field
>>> somewhere.
>>>
>>>> Programmers have to take responsibility for
>>>> writing correct code.
>>>
>>> When was the last time you took responsibility that a C function
>>> call correctly pops all the arguments off the stack which it pushed?
>>>
> 
>> Every time I use a function?  I take responsibility for picking a good
>> compiler that I am confident I can rely on, for testing my code, and for
>> writing code correctly in the first place - that's a programmer's job.
>> And when I accidentally put bugs in the code, that is my responsibility too.
>>
>>> One way that programmers, as a group, take responsibility for writing
>>> correct code is by by developing tools, and using them.
>>
>> Sure.  In particular, they are responsible for learning the tools and
>> using them properly to maximal effect for the task in hand.
> 
> This is a basic principle in the field and pretty much any other
> professional field; as such, it doesn't really inform.
> 
> It's true whether you're toggling switches on a panel to produce
> a binary program directly in memory, or whether you're using OCaml
> or Prolog.
> 

Yes.  And it is not uncommon in many fields to blame the tools for 
mistakes of the users.  Sometimes such blame is fair, of course - but 
usually not.

> Yet it is empirically valid that those diverse alternatives
> don't have the same safety, and we evolve things accordingly.
> 
> Speaking of returning the cross-posting to comp.lang.c++, that language
> as of C++17 has chosen to define some evaluation orders.
> 

Yes.  Primarily it is for the case of "cout << a() << b();".  This is a 
situation where specific ordering really does help the programmer.

Language changes are sometimes a good idea, but there are almost always 
trade-offs to consider.  Things that one person sees as clearly a good 
idea, will sound crazy and be a pain for someone else.

> The evaluation order of function arguments is not yet defined, but
> now there is a sequence point between the argument expressions.
> 
> That is obviouslly super important, because now the unspecified behavior
> stays unspecified when there are side effects like:
> 
>    f(i++, i++);
> 
> it doesn't help with the situation
> 
>    f(g(), h())
> 
> because those calls are sequenced. However, it helps in the
> argument space: with just the classic sequencing of function calls not
> being interleaved, this is still undefined:
> 
>    f(g(i++), h(i++))
> 

There is always going to be things that are undefined or unspecified. 
There are always going to be ways to write things that make no sense, or 
at least no well-defined and consistent sense.  A language can aim to 
reduce these possibilities, but it comes at a big cost.  There are three 
disadvantages, as I see them.  One is that it tells programmers that 
even though a piece of code is unclear to humans, it is valid code - and 
then some people write code like "f(i++, i++)" that is hard for others 
to comprehend.  Another is it reduces the ability of compilers and tools 
to help you write good, clear code (compilers can warn on "f(i++, i++)" 
when it is not defined behaviour).  And it reduces optimisation 
possibilities for perfectly good code.


> whereas by my understanding C++17 leaves it unspecified in which order g
> and h will be called, and which one will have receive the original value
> of i.  But, I think, we can infer that that function which is called
> first receives the original value of i, and i is reliably incremented
> twice.   Baby steps in the right direction, in any case.
> 

No - that is the /wrong/ message to take from the C++17 changes.  It is 
not "baby steps in the right direction" - it is a case of minimal 
changes needed to give defined behaviour to common incorrect code that 
has been used in practice for years.  The key motivation is that a lot 
of code has been written that assumes "cout << f() << g();" calls "f()" 
first, then "g()".

It is not a step in a direction towards more general changes, because 
that would mean making at least some existing correct code less efficient.

> I don't understand the rationale for sequencing A before B in A << B
> (what is so special about shifting); there must be some motivating
> example where you have a side effect in A that B depends on. What I'm
> likely missing that it's probably not the built-in arithmetic << that is
> of concern, but overloads.
> 

Correct.

>> But you don't get to pick different rules that you'd prefer to have for
>> the language, and then blame the language when your code doesn't work.
>> It is not the language that is at fault if someone writes code that
>> relies on execution order that is left unspecified by the standards -
>> it's the programmers' fault.
> 
> It's not a game of blame, but of reducing the unfortunate situations in
> which someone has a reason to look for something to blame.
> 

Fair enough.

> I can't look at a large body of code (that I perhaps didn't write: so no
> responsibility of mine) and easily know whether there is a problem due
> to eval order.

Analysing the correctness of other people's code is never an easy job!

However, I don't think a specified evaluation order would help.  If you 
see "f(g(), h());" in the code, you are concerned that the programmer 
might be assuming that "g()" is evaluated before "h()".  But if you know 
the programmer was good at his/her job, you will know that he/she would 
have used temporaries and run g() and h() before f() if the order 
mattered.  So you know the code is correct, and the order does not matter.

However, if the order were specified by the language, then you still 
know the code is correct but you don't know if the order of the call 
matters (and the programmer relied on the evaluation order), or if it 
does not matter.

The lack of specification in the language gives you /more/ information, 
not less.

And if you can't rely on the original programmer's competence, you can't 
rely on anything in the code without more detailed checking anyway.


Sometimes tighter specification for things like evaluation order gives 
you benefits, but not always - it can just as well be a disadvantage.


> If I'm charged with the responsibility of finding out,
> I could just give a quick answer "almost certainly no, modulo compiler
> bugs" if eval order is defined by the language, without any effort. (On
> the other hand, that leaves money on the table, doesn't it! Now I have
> to find alternative ways to get paid for the saved hours.)
> 
> Scrambled eval orders in a language in which side effects are the
> principal means of getting anything done is a poor technical situation.
> 

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

#86759 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

David Brown <david.brown@hesbynett.no> writes:

> On 30/09/2022 19:20, Kaz Kylheku wrote:
<cut>
>> Speaking of returning the cross-posting to comp.lang.c++, that language
>> as of C++17 has chosen to define some evaluation orders.
>
> Yes.  Primarily it is for the case of "cout << a() << b();".  This is
> a situation where specific ordering really does help the programmer.

I'm curious.  How does a specific ordering help the programmer here?
Even with no specified order of evaluation, the output must look as if
the result of b() was appended to the stream resulting from the
left-most << operator.  All the ordering does is cause any side effects
in a() and b() to be predictably ordered, and that might look more like
helping the programmer to write dodgy code.

-- 
Ben.

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

#86760 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 02/10/2022 14:00, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 30/09/2022 19:20, Kaz Kylheku wrote:
> <cut>
>>> Speaking of returning the cross-posting to comp.lang.c++, that language
>>> as of C++17 has chosen to define some evaluation orders.
>>
>> Yes.  Primarily it is for the case of "cout << a() << b();".  This is
>> a situation where specific ordering really does help the programmer.
> 
> I'm curious.  How does a specific ordering help the programmer here?
> Even with no specified order of evaluation, the output must look as if
> the result of b() was appended to the stream resulting from the
> left-most << operator.  All the ordering does is cause any side effects
> in a() and b() to be predictably ordered, and that might look more like
> helping the programmer to write dodgy code.
> 

Yes, it is a matter of side-effects.  Without side-effects in "a()" or 
"b()", the result is clear regardless of the order of evaluation.

And if there are side-effects, and order matters, then programmers can 
(and should, at least until C++17) write along the lines of :

	const auto res_a = a();
	const auto res_b = b();
	cout << res_a << res_b;

But it seems that many programmers have been assuming that using 
iostreams for output like this has a specified order - even when they 
don't make such assumptions about other kinds of expressions.  I suppose 
it is something about the appearance of the code that makes it look like 
there is an order to the evaluation.

Maybe it is not accurate to say this "helps the programmer", and it is 
more correct to say that it makes what used to be dodgy code into 
correct code.  But if it means their old dodgy code continues to work as 
they intended even when they use newer compilers that do more 
re-ordering optimisations, then it helps them.

A disadvantage of this change is that it might make some programmers 
think ordering is more tightly specified for other kinds of expression 
as well, and rely on such incorrect assumptions.

(I'm not convinced that this evaluation order change in C++17 is a good 
idea, or worth the complications of having this special case.  I am just 
trying to say why it is different from a more general evaluation order 
specification, and why the C++ committee thought it was worth changing.)

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

#86769 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 10/2/2022 4:20 PM, David Brown wrote:
> On 02/10/2022 14:00, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 30/09/2022 19:20, Kaz Kylheku wrote:
>> <cut>
>>>> Speaking of returning the cross-posting to comp.lang.c++, that language
>>>> as of C++17 has chosen to define some evaluation orders.
>>>
>>> Yes.  Primarily it is for the case of "cout << a() << b();".  This is
>>> a situation where specific ordering really does help the programmer.
>>
>> I'm curious.  How does a specific ordering help the programmer here?
>> Even with no specified order of evaluation, the output must look as if
>> the result of b() was appended to the stream resulting from the
>> left-most << operator.  All the ordering does is cause any side effects
>> in a() and b() to be predictably ordered, and that might look more like
>> helping the programmer to write dodgy code.
>>
> 
> Yes, it is a matter of side-effects.  Without side-effects in "a()" or 
> "b()", the result is clear regardless of the order of evaluation.
> 
> And if there are side-effects, and order matters, then programmers can 
> (and should, at least until C++17) write along the lines of :
> 
>      const auto res_a = a();
>      const auto res_b = b();
>      cout << res_a << res_b;
> 

I disagree that this change is to be interpreted as "giving some help to 
bad programmers".

The key point is that this is about the insertion operator, not binary 
shift (here the C++ syntax does not help indeed)
Insertion operators, and specifically in combination with streams, have 
been explicitly designed /from day one/ to allow for:

   cout <<
     value_1 <<
     value_2 <<
     value_3 <<
     value_4 <<
     value_5 <<
     value_6;

Along the same lines:

   cout <<
     f_1() <<
     f_2() <<
     f_3() <<
     f_4() <<
     f_5() <<
     f_6();

Is just expected semantics, which good language design should account for.

I am pretty confident that the construct that you suggest as "the right 
way" was not the intention of the language designers - think e.g. IO 
manipulators.


> But it seems that many programmers have been assuming that using 
> iostreams for output like this has a specified order - even when they 
> don't make such assumptions about other kinds of expressions.  I suppose 
> it is something about the appearance of the code that makes it look like 
> there is an order to the evaluation.
> 
> Maybe it is not accurate to say this "helps the programmer", and it is 
> more correct to say that it makes what used to be dodgy code into 
> correct code.  But if it means their old dodgy code continues to work as 
> they intended even when they use newer compilers that do more 
> re-ordering optimisations, then it helps them.
> 
> A disadvantage of this change is that it might make some programmers 
> think ordering is more tightly specified for other kinds of expression 
> as well, and rely on such incorrect assumptions.
> 
> (I'm not convinced that this evaluation order change in C++17 is a good 
> idea, or worth the complications of having this special case.  I am just 
> trying to say why it is different from a more general evaluation order 
> specification, and why the C++ committee thought it was worth changing.)

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

#86781 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 02/10/2022 22:05, Manfred wrote:
> On 10/2/2022 4:20 PM, David Brown wrote:

<snip>

>>
>> Yes, it is a matter of side-effects.  Without side-effects in "a()" or 
>> "b()", the result is clear regardless of the order of evaluation.
>>
>> And if there are side-effects, and order matters, then programmers can 
>> (and should, at least until C++17) write along the lines of :
>>
>>      const auto res_a = a();
>>      const auto res_b = b();
>>      cout << res_a << res_b;
>>
> 
> I disagree that this change is to be interpreted as "giving some help to 
> bad programmers".
> 
> The key point is that this is about the insertion operator, not binary 
> shift (here the C++ syntax does not help indeed)
> Insertion operators, and specifically in combination with streams, have 
> been explicitly designed /from day one/ to allow for:
> 
>    cout <<
>      value_1 <<
>      value_2 <<
>      value_3 <<
>      value_4 <<
>      value_5 <<
>      value_6;
> 
> Along the same lines:
> 
>    cout <<
>      f_1() <<
>      f_2() <<
>      f_3() <<
>      f_4() <<
>      f_5() <<
>      f_6();
> 
> Is just expected semantics, which good language design should account for.
> 
> I am pretty confident that the construct that you suggest as "the right 
> way" was not the intention of the language designers - think e.g. IO 
> manipulators.
> 

(As an aside, I think the IO manipulators are a terrible concept - modal 
settings for an IO stream to change the format is just /wrong/.)

IO manipulators are not affected by evaluation order beyond the general 
rule of evaluating a subexpression before it is used.

Consider :

	cout << hex << f();

This is treated as "(cout << hex) << f();".  It doesn't matter if the 
"(cout << hex)" is evaluated before "f()", in regard to the output - 
both are evaluated before the output of "f()" is actually sent to the 
stream.


Certainly a lot of people have viewed the iostreams syntax as implying 
that "cout << f1() << f2()" evaluated "f1()" before "f2()".  And 
certainly that is a reasonable request for a language (though it is also 
reasonable to say the order should not be specified).  The issue is that 
no matter what you might prefer, or what the iostreams designers might 
have intended, the language (prior to C++17) did not guarantee such an 
evaluation order.  So if your code relied on the order of side-effects 
of "f1()" and "f2()", then prior to C++17 you had to order it yourself 
(such as by using temporaries, or sticking to a compiler that guaranteed 
and documented the evaluation order).

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

#86761 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 30/09/2022 19:20, Kaz Kylheku wrote:
>
> <cut>
>
>>> Speaking of returning the cross-posting to comp.lang.c++, that language
>>> as of C++17 has chosen to define some evaluation orders.
>>
>> Yes.  Primarily it is for the case of "cout << a() << b();".  This is
>> a situation where specific ordering really does help the programmer.
>
> I'm curious.  How does a specific ordering help the programmer here?
> Even with no specified order of evaluation, the output must look as if
> the result of b() was appended to the stream resulting from the
> left-most << operator.  All the ordering does is cause any side effects
> in a() and b() to be predictably ordered, and that might look more like
> helping the programmer to write dodgy code.

For this sub-thread I think the posting should have been limited
to comp.lang.c++, and not included comp.lang.c.

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

#86666 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 27/09/2022 15:26, Juha Nieminen wrote:
> In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote:
>>>> However, it's taken until C++20 to get designated
>>>> initialisers in C++, which suggests that they were not viewed as the
>>>> most important feature (though there has certainly been plenty of call
>>>> for them in C++).
>>>
>>> And C++20 ruined one of the best aspects of them: The fact that you don't
>>> need to know the order in which the member variables have been defined
>>> in the struct.
>>
>> I agree with that.  It strikes me as a strange requirement - just like
>> the insistence that initialisers in a constructor match the declaration
>> order.  Perhaps there is some clear, logical reason for that restriction
>> (and perhaps someone could tell me what it is?).
> 
> I understand that C++ wants member variables to be initialized in strict
> order of declaration (which in the case of C++ in particular can make
> quite a difference if those initializations have side effects),

I understand that C++ /does/ insist on following the order of 
declaration - I don't understand /why/.  I appreciate that the 
initialisations could have side effects, so it makes sense that the 
initialisations are always carried out in the order of declaration - but 
not that the order must be followed syntactically when writing the 
constructor.  (Alternatively, the language could have said that the 
initialisations are carried out in the order given in the list in the 
constructor - either would have worked, as long as it was clear and 
consistent.)

For example, if I have a class containing some ints and doubles, and 
some flags, then I might want to order the member declarations to pack 
nicely and match a cache line in total size.  But I might prefer the 
initialisations in constructors to follow a logical order that is 
different.  I fail to see a good reason why that is not allowed. 
(Again, this is quite possibly just that I am ignorant of the good reason.)

> but when
> it comes to designated initializers I really think that the C++20 standard
> should have allowed any order in the initialization list, and simply
> declared that if the initializers are not specified in the same order
> as the members have been declared, the behavior is "implementation-defined".

Agreed.

> In other words, if the initializers are listed in the correct order, the
> behavior is well-defined, but if they are in another order it's up to the
> compiler whether it will reorder them to match the declaration order, or
> initialize the members in the order specified in the list. (In other
> words, if the initializers have side effects, you can't rely on them
> being done in any particular order.)
> 
> (Another possibility is that it could have made an exception with POD
> types, and allow out-of-order initialization with those.)

Also possible.

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

#86672 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 9/28/22 3:40 AM, David Brown wrote:
> On 27/09/2022 15:26, Juha Nieminen wrote:
>> In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote:
>>>>> However, it's taken until C++20 to get designated
>>>>> initialisers in C++, which suggests that they were not viewed as the
>>>>> most important feature (though there has certainly been plenty of call
>>>>> for them in C++).
>>>>
>>>> And C++20 ruined one of the best aspects of them: The fact that you 
>>>> don't
>>>> need to know the order in which the member variables have been defined
>>>> in the struct.
>>>
>>> I agree with that.  It strikes me as a strange requirement - just like
>>> the insistence that initialisers in a constructor match the declaration
>>> order.  Perhaps there is some clear, logical reason for that restriction
>>> (and perhaps someone could tell me what it is?).
>>
>> I understand that C++ wants member variables to be initialized in strict
>> order of declaration (which in the case of C++ in particular can make
>> quite a difference if those initializations have side effects),
> 
> I understand that C++ /does/ insist on following the order of 
> declaration - I don't understand /why/.  I appreciate that the 
> initialisations could have side effects, so it makes sense that the 
> initialisations are always carried out in the order of declaration - but 
> not that the order must be followed syntactically when writing the 
> constructor.  (Alternatively, the language could have said that the 
> initialisations are carried out in the order given in the list in the 
> constructor - either would have worked, as long as it was clear and 
> consistent.)
> 
> For example, if I have a class containing some ints and doubles, and 
> some flags, then I might want to order the member declarations to pack 
> nicely and match a cache line in total size.  But I might prefer the 
> initialisations in constructors to follow a logical order that is 
> different.  I fail to see a good reason why that is not allowed. (Again, 
> this is quite possibly just that I am ignorant of the good reason.)

The problem with the order listed in the constructor is that there might 
not be just one constructor, but several, that list the order 
differently. That gives the destructor problems, as it doesn't know what 
order to destruct the object, and the constructor's implementation might 
not even be visible at the point of generating the code for the destructor.

That forces ALL classes to add hidden members that record the order of 
construction for this instance of the class, which violates the 
principle of trying to not pay for things you don't need.

Using the order from the class definition is the simple solution.

Note, for your class with ints and doubles, it doesn't matter, as the 
destructor is trivial.

> 
>> but when
>> it comes to designated initializers I really think that the C++20 
>> standard
>> should have allowed any order in the initialization list, and simply
>> declared that if the initializers are not specified in the same order
>> as the members have been declared, the behavior is 
>> "implementation-defined".
> 
> Agreed.
> 
>> In other words, if the initializers are listed in the correct order, the
>> behavior is well-defined, but if they are in another order it's up to the
>> compiler whether it will reorder them to match the declaration order, or
>> initialize the members in the order specified in the list. (In other
>> words, if the initializers have side effects, you can't rely on them
>> being done in any particular order.)
>>
>> (Another possibility is that it could have made an exception with POD
>> types, and allow out-of-order initialization with those.)
> 
> Also possible.

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

#86676 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 28/09/2022 13:56, Richard Damon wrote:
> On 9/28/22 3:40 AM, David Brown wrote:
>> On 27/09/2022 15:26, Juha Nieminen wrote:
>>> In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote:
>>>>>> However, it's taken until C++20 to get designated
>>>>>> initialisers in C++, which suggests that they were not viewed as the
>>>>>> most important feature (though there has certainly been plenty of 
>>>>>> call
>>>>>> for them in C++).
>>>>>
>>>>> And C++20 ruined one of the best aspects of them: The fact that you 
>>>>> don't
>>>>> need to know the order in which the member variables have been defined
>>>>> in the struct.
>>>>
>>>> I agree with that.  It strikes me as a strange requirement - just like
>>>> the insistence that initialisers in a constructor match the declaration
>>>> order.  Perhaps there is some clear, logical reason for that 
>>>> restriction
>>>> (and perhaps someone could tell me what it is?).
>>>
>>> I understand that C++ wants member variables to be initialized in strict
>>> order of declaration (which in the case of C++ in particular can make
>>> quite a difference if those initializations have side effects),
>>
>> I understand that C++ /does/ insist on following the order of 
>> declaration - I don't understand /why/.  I appreciate that the 
>> initialisations could have side effects, so it makes sense that the 
>> initialisations are always carried out in the order of declaration - 
>> but not that the order must be followed syntactically when writing the 
>> constructor.  (Alternatively, the language could have said that the 
>> initialisations are carried out in the order given in the list in the 
>> constructor - either would have worked, as long as it was clear and 
>> consistent.)
>>
>> For example, if I have a class containing some ints and doubles, and 
>> some flags, then I might want to order the member declarations to pack 
>> nicely and match a cache line in total size.  But I might prefer the 
>> initialisations in constructors to follow a logical order that is 
>> different.  I fail to see a good reason why that is not allowed. 
>> (Again, this is quite possibly just that I am ignorant of the good 
>> reason.)
> 
> The problem with the order listed in the constructor is that there might 
> not be just one constructor, but several, that list the order 
> differently. That gives the destructor problems, as it doesn't know what 
> order to destruct the object, and the constructor's implementation might 
> not even be visible at the point of generating the code for the destructor.
> 
> That forces ALL classes to add hidden members that record the order of 
> construction for this instance of the class, which violates the 
> principle of trying to not pay for things you don't need.

That all suggests it is a good idea for initialisers to be executed in 
the order given in the class declaration (since practicality dictates 
having one fixed order, that seems the sensible choice).  It does /not/ 
suggest that the same order should be required when listing the 
initialisers.

> 
> Using the order from the class definition is the simple solution.
> 
> Note, for your class with ints and doubles, it doesn't matter, as the 
> destructor is trivial.
> 
And yet C++ won't let me re-order them in the initialiser list.  It will 
let me use whatever order I want inside the body of the constructor 
using assignment, and then the compiler will re-order to match exactly 
the same code that I'd get with initialisers - whatever is the most 
efficient code.

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

#86677 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

David Brown <david.brown@hesbynett.no> writes:
>On 28/09/2022 13:56, Richard Damon wrote:

>That all suggests it is a good idea for initialisers to be executed in 
>the order given in the class declaration (since practicality dictates 
>having one fixed order, that seems the sensible choice).  It does /not/ 
>suggest that the same order should be required when listing the 
>initialisers.
>
>> 
>> Using the order from the class definition is the simple solution.
>> 
>> Note, for your class with ints and doubles, it doesn't matter, as the 
>> destructor is trivial.
>> 
>And yet C++ won't let me re-order them in the initialiser list.  It will 
>let me use whatever order I want inside the body of the constructor 
>using assignment, and then the compiler will re-order to match exactly 
>the same code that I'd get with initialisers - whatever is the most 
>efficient code.

I suppose that when BS was writing cfront, it wasn't feasible to
support different orders for declaration and initialization; subsequent
code being sensitive to such, relaxation as compilers became more
sophisticated was counterindicated.

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

#86682 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

scott@slp53.sl.home (Scott Lurndal) writes:
>David Brown <david.brown@hesbynett.no> writes:
>>On 28/09/2022 13:56, Richard Damon wrote:
>
>>That all suggests it is a good idea for initialisers to be executed in 
>>the order given in the class declaration (since practicality dictates 
>>having one fixed order, that seems the sensible choice).  It does /not/ 
>>suggest that the same order should be required when listing the 
>>initialisers.
>>
>>> 
>>> Using the order from the class definition is the simple solution.
>>> 
>>> Note, for your class with ints and doubles, it doesn't matter, as the 
>>> destructor is trivial.
>>> 
>>And yet C++ won't let me re-order them in the initialiser list.  It will 
>>let me use whatever order I want inside the body of the constructor 
>>using assignment, and then the compiler will re-order to match exactly 
>>the same code that I'd get with initialisers - whatever is the most 
>>efficient code.
>
>I suppose that when BS was writing cfront, it wasn't feasible to
>support different orders for declaration and initialization; subsequent
>code being sensitive to such, relaxation as compilers became more
>sophisticated was counterindicated.

Moreover, since function call arguments were passed on a stack,
were pushed in reverse order and the target architectures of the day
had limited registers, it follows that compiler writers in the day
would process arguments in reverse order when generating code.

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

#86685 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 2022-09-28, Scott Lurndal <scott@slp53.sl.home> wrote:
> Moreover, since function call arguments were passed on a stack,
> were pushed in reverse order and the target architectures of the day
> had limited registers, it follows that compiler writers in the day
> would process arguments in reverse order when generating code.

Not just limited registers; but limited analysis. Because you can
reorder the evaluation to go in the stack-convenient order, in cases
where you can confirm that it makes no difference.

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

#86687 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 2022-09-28 at 18:56, Kaz Kylheku wrote:
> On 2022-09-28, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Moreover, since function call arguments were passed on a stack,
>> were pushed in reverse order and the target architectures of the day
>> had limited registers, it follows that compiler writers in the day
>> would process arguments in reverse order when generating code.
> 
> Not just limited registers; but limited analysis. Because you can
> reorder the evaluation to go in the stack-convenient order, in cases
> where you can confirm that it makes no difference.

The "stack convenient" order is very important for some common 
functions, like printf. Evaluating that function call left-to-right and 
push the parameters so that the format string is at the bottom of an 
unknown sized parameter pack is - Extremely Inconvenient(TM).

So the evaluation is ordered so that the format string is pushed last 
and easy to find for printf. Kind of important for it to figure out the 
types and numbers of the other parameters.

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

#86690 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

In article <jpji7nFi2gbU1@mid.individual.net>,
Bo Persson  <bo@bo-persson.se> wrote:
>On 2022-09-28 at 18:56, Kaz Kylheku wrote:
>> On 2022-09-28, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Moreover, since function call arguments were passed on a stack,
>>> were pushed in reverse order and the target architectures of the day
>>> had limited registers, it follows that compiler writers in the day
>>> would process arguments in reverse order when generating code.
>> 
>> Not just limited registers; but limited analysis. Because you can
>> reorder the evaluation to go in the stack-convenient order, in cases
>> where you can confirm that it makes no difference.
>
>The "stack convenient" order is very important for some common 
>functions, like printf. Evaluating that function call left-to-right and 
>push the parameters so that the format string is at the bottom of an 
>unknown sized parameter pack is - Extremely Inconvenient(TM).
>
>So the evaluation is ordered so that the format string is pushed last 
>and easy to find for printf. Kind of important for it to figure out the 
>types and numbers of the other parameters.
>
>
>

C/C++ being deprecated?  How would computing work?
-- 
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b 
Quebec oubliez les extremes et votez PLQ Beware https://mindspring.com

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

#86698 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 28/09/2022 16:21, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/09/2022 13:56, Richard Damon wrote:
> 
>> That all suggests it is a good idea for initialisers to be executed in
>> the order given in the class declaration (since practicality dictates
>> having one fixed order, that seems the sensible choice).  It does /not/
>> suggest that the same order should be required when listing the
>> initialisers.
>>
>>>
>>> Using the order from the class definition is the simple solution.
>>>
>>> Note, for your class with ints and doubles, it doesn't matter, as the
>>> destructor is trivial.
>>>
>> And yet C++ won't let me re-order them in the initialiser list.  It will
>> let me use whatever order I want inside the body of the constructor
>> using assignment, and then the compiler will re-order to match exactly
>> the same code that I'd get with initialisers - whatever is the most
>> efficient code.
> 
> I suppose that when BS was writing cfront, it wasn't feasible to
> support different orders for declaration and initialization; subsequent
> code being sensitive to such, relaxation as compilers became more
> sophisticated was counterindicated.

I can quite believe that being flexible about the ordering would have 
involved more compiler effort at the time, and that's a solid argument. 
  But we have seen many cases where features are initially very 
restricted, but get freer as compilers get more sophisticated and can 
handle them better - constexpr functions is a prime case.

I can't see the challenges of writing cfront as a reason not to allow 
freely ordered designated initialisers.

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

#86691 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 9/28/22 9:50 AM, David Brown wrote:
> On 28/09/2022 13:56, Richard Damon wrote:
>> On 9/28/22 3:40 AM, David Brown wrote:
>>> On 27/09/2022 15:26, Juha Nieminen wrote:
>>>> In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote:
>>>>>>> However, it's taken until C++20 to get designated
>>>>>>> initialisers in C++, which suggests that they were not viewed as the
>>>>>>> most important feature (though there has certainly been plenty of 
>>>>>>> call
>>>>>>> for them in C++).
>>>>>>
>>>>>> And C++20 ruined one of the best aspects of them: The fact that 
>>>>>> you don't
>>>>>> need to know the order in which the member variables have been 
>>>>>> defined
>>>>>> in the struct.
>>>>>
>>>>> I agree with that.  It strikes me as a strange requirement - just like
>>>>> the insistence that initialisers in a constructor match the 
>>>>> declaration
>>>>> order.  Perhaps there is some clear, logical reason for that 
>>>>> restriction
>>>>> (and perhaps someone could tell me what it is?).
>>>>
>>>> I understand that C++ wants member variables to be initialized in 
>>>> strict
>>>> order of declaration (which in the case of C++ in particular can make
>>>> quite a difference if those initializations have side effects),
>>>
>>> I understand that C++ /does/ insist on following the order of 
>>> declaration - I don't understand /why/.  I appreciate that the 
>>> initialisations could have side effects, so it makes sense that the 
>>> initialisations are always carried out in the order of declaration - 
>>> but not that the order must be followed syntactically when writing 
>>> the constructor.  (Alternatively, the language could have said that 
>>> the initialisations are carried out in the order given in the list in 
>>> the constructor - either would have worked, as long as it was clear 
>>> and consistent.)
>>>
>>> For example, if I have a class containing some ints and doubles, and 
>>> some flags, then I might want to order the member declarations to 
>>> pack nicely and match a cache line in total size.  But I might prefer 
>>> the initialisations in constructors to follow a logical order that is 
>>> different.  I fail to see a good reason why that is not allowed. 
>>> (Again, this is quite possibly just that I am ignorant of the good 
>>> reason.)
>>
>> The problem with the order listed in the constructor is that there 
>> might not be just one constructor, but several, that list the order 
>> differently. That gives the destructor problems, as it doesn't know 
>> what order to destruct the object, and the constructor's 
>> implementation might not even be visible at the point of generating 
>> the code for the destructor.
>>
>> That forces ALL classes to add hidden members that record the order of 
>> construction for this instance of the class, which violates the 
>> principle of trying to not pay for things you don't need.
> 
> That all suggests it is a good idea for initialisers to be executed in 
> the order given in the class declaration (since practicality dictates 
> having one fixed order, that seems the sensible choice).  It does /not/ 
> suggest that the same order should be required when listing the 
> initialisers.

Right, because to allow otherwise adds a LOT of overhead. That is what I 
was implying. That IS the rules of C++, the initialzers are processed in 
the order the members are listed in the class definition, regardless of 
the order specified in the constructor.

> 
>>
>> Using the order from the class definition is the simple solution.
>>
>> Note, for your class with ints and doubles, it doesn't matter, as the 
>> destructor is trivial.
>>
> And yet C++ won't let me re-order them in the initialiser list.  It will 
> let me use whatever order I want inside the body of the constructor 
> using assignment, and then the compiler will re-order to match exactly 
> the same code that I'd get with initialisers - whatever is the most 
> efficient code.

You can specify the initializer list in what ever order you want, though 
a good compiler will have the option to give you are warning if the 
listed order isn't the order that it will do them in.

In the body of the construtor, it is required to do them in the order 
listed, or at least act "as if" it did them in the order listed.

Because of the "as if" rule, if you can't tell the difference, it 
doesn't matter what order they are done in.

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

#86616 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 9/26/22 05:55, David Brown wrote:
> Designated initialisers are certainly nice, but I would not call them 
> the "best" feature of C99.  If I were to pick one favourite C99 feature, 
> it would be mixing declarations and statements - but such choices are 
> highly subjective.  However, it's taken until C++20 to get designated 
> initialisers in C++, which suggests that they were not viewed as the 
> most important feature (though there has certainly been plenty of call 
> for them in C++).

I'd go with the ability to place declarations close to the code using 
them also. Throwing in curly braces worked but it wasn't too elegant.

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

#86644 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 26/09/2022 17:04, rbowman wrote:
> On 9/26/22 05:55, David Brown wrote:
>> Designated initialisers are certainly nice, but I would not call them 
>> the "best" feature of C99.  If I were to pick one favourite C99 
>> feature, it would be mixing declarations and statements - but such 
>> choices are highly subjective.  However, it's taken until C++20 to get 
>> designated initialisers in C++, which suggests that they were not 
>> viewed as the most important feature (though there has certainly been 
>> plenty of call for them in C++).
> 
> I'd go with the ability to place declarations close to the code using 
> them also. Throwing in curly braces worked but it wasn't too elegant.
> 

That is one of the important benefits of being able to mix declarations 
and statements, so I think we agree on our favourite feature.

It is not the only benefit, however.  Declaring your variable only when 
you have something useful to put in it lets you make many such variables 
"const" - then both the programmer and the compiler know it is not going 
to change.  It makes adding new local variables "cheap" - so instead of 
re-using a single "int temp;" variable in a dozen places in the 
function, you have many const variables that do one thing, with one 
name, and you always know exactly what they are.

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

#86647 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 9/27/22 03:27, David Brown wrote:
> On 26/09/2022 17:04, rbowman wrote:
>> On 9/26/22 05:55, David Brown wrote:
>>> Designated initialisers are certainly nice, but I would not call them 
>>> the "best" feature of C99.  If I were to pick one favourite C99 
>>> feature, it would be mixing declarations and statements - but such 
>>> choices are highly subjective.  However, it's taken until C++20 to 
>>> get designated initialisers in C++, which suggests that they were not 
>>> viewed as the most important feature (though there has certainly been 
>>> plenty of call for them in C++).
>>
>> I'd go with the ability to place declarations close to the code using 
>> them also. Throwing in curly braces worked but it wasn't too elegant.
>>
> 
> That is one of the important benefits of being able to mix declarations 
> and statements, so I think we agree on our favourite feature.
> 
> It is not the only benefit, however.  Declaring your variable only when 
> you have something useful to put in it lets you make many such variables 
> "const" - then both the programmer and the compiler know it is not going 
> to change.  It makes adding new local variables "cheap" - so instead of 
> re-using a single "int temp;" variable in a dozen places in the 
> function, you have many const variables that do one thing, with one 
> name, and you always know exactly what they are.

I'm not fond of 'const'. We have a lot of legacy code where the 
programmers used it inappropriately so you wind up casting it away. I 
think they saw it in one declaration and decided it was always needed. 
Used correctly it's valuable

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

#86655 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

On 27/09/2022 16:11, rbowman wrote:
> On 9/27/22 03:27, David Brown wrote:
>> On 26/09/2022 17:04, rbowman wrote:
>>> On 9/26/22 05:55, David Brown wrote:
>>>> Designated initialisers are certainly nice, but I would not call 
>>>> them the "best" feature of C99.  If I were to pick one favourite C99 
>>>> feature, it would be mixing declarations and statements - but such 
>>>> choices are highly subjective.  However, it's taken until C++20 to 
>>>> get designated initialisers in C++, which suggests that they were 
>>>> not viewed as the most important feature (though there has certainly 
>>>> been plenty of call for them in C++).
>>>
>>> I'd go with the ability to place declarations close to the code using 
>>> them also. Throwing in curly braces worked but it wasn't too elegant.
>>>
>>
>> That is one of the important benefits of being able to mix 
>> declarations and statements, so I think we agree on our favourite 
>> feature.
>>
>> It is not the only benefit, however.  Declaring your variable only 
>> when you have something useful to put in it lets you make many such 
>> variables "const" - then both the programmer and the compiler know it 
>> is not going to change.  It makes adding new local variables "cheap" - 
>> so instead of re-using a single "int temp;" variable in a dozen places 
>> in the function, you have many const variables that do one thing, with 
>> one name, and you always know exactly what they are.
> 
> I'm not fond of 'const'. We have a lot of legacy code where the 
> programmers used it inappropriately so you wind up casting it away. I 
> think they saw it in one declaration and decided it was always needed. 
> Used correctly it's valuable

Is it not better just to say that you are not fond of incorrect and 
badly written code?  If you have code written by people who don't know 
how to use "const" properly, you should not let that stop you using it 
when it is useful.

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

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

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

csiph-web