Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167776 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2022-09-21 14:04 -0500 |
| Last post | 2022-09-26 02:08 -0400 |
| Articles | 20 on this page of 119 — 31 participants |
Back to article view | Back to comp.lang.c
“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??? Single Stage to Orbit <alex.buell@munted.eu> - 2022-09-22 09:42 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 11:16 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:48 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 23:12 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 01:40 +0100
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 deprecated??? The Real Non Homosexual <cdalten@gmail.com> - 2022-10-10 19:12 -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??? 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” Ben Collver <bencollver@tilde.pink> - 2022-09-22 15:19 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 15:23 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-22 12:13 -0700
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Andrea Biscuola <a@abiscuola.com> - 2022-09-22 20:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” scott@slp53.sl.home (Scott Lurndal) - 2022-09-22 19:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Richard Harnden <richard.nospam@gmail.com> - 2022-09-22 17:36 +0100
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??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-27 22:32 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 23:52 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-27 19:57 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:03 +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??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 15:26 +0000
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-29 20:45 +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??? Michael S <already5chosen@yahoo.com> - 2022-10-01 11:40 -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??? 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??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:17 +0000
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??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 18:48 +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??? Bart <bc@freeuk.com> - 2022-09-27 12:41 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-27 15:22 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:13 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 16:50 +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??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? BGB <cr88192@gmail.com> - 2022-10-01 16:07 -0500
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 →
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-29 17:58 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220929104930.67@kylheku.com> |
| In reply to | #167906 |
["Followup-To:" header set to comp.lang.c.]
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?
One way that programmers, as a group, take responsibility for writing
correct code is by by developing tools, and using them.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-29 20:45 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th4p4g$nns9$1@dont-email.me> |
| In reply to | #167910 |
On 29/09/2022 19:58, Kaz Kylheku wrote:
> ["Followup-To:" header set to comp.lang.c.]
> 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.
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.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-30 17:20 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220930100037.560@kylheku.com> |
| In reply to | #167911 |
[ 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.
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.
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++))
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.
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.
> 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.
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. 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.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-09-30 20:59 +0300 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th7aql$12li6$2@dont-email.me> |
| In reply to | #167914 |
30.09.2022 20:20 Kaz Kylheku kirjutas: > Scrambled eval orders in a language in which side effects are the > principal means of getting anything done is a poor technical situation. > That must be some other language. I have never written any C++ code where side effects were the principal means of getting something done. If anything, C++ in general has moved towards more functional style over the years, with fewer mutable objects, not to speak about objects mutated by side effects.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-10-01 11:40 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <33da85af-fa7e-4a35-8f7a-87f9ee9599ffn@googlegroups.com> |
| In reply to | #167915 |
On Friday, September 30, 2022 at 9:00:03 PM UTC+3, Paavo Helde wrote: > 30.09.2022 20:20 Kaz Kylheku kirjutas: > > > Scrambled eval orders in a language in which side effects are the > > principal means of getting anything done is a poor technical situation. > > > That must be some other language. I have never written any C++ code > where side effects were the principal means of getting something done. > > If anything, C++ in general has moved towards more functional style over > the years, with fewer mutable objects, not to speak about objects > mutated by side effects. Just about everything in C++ is done as side-effects of expressions. I think, the only major exception to that is flow control.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-02 13:38 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <thbt7p$1mgus$1@dont-email.me> |
| In reply to | #167914 |
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]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-10-02 13:00 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87sfk6qvtb.fsf@bsb.me.uk> |
| In reply to | #167940 |
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-02 16:20 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <thc6ni$1n90q$1@dont-email.me> |
| In reply to | #167941 |
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-30 09:17 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th655f$uq72$1@dont-email.me> |
| In reply to | #167910 |
On 29/09/2022 19:58, Kaz Kylheku wrote: > ["Followup-To:" header set to comp.lang.c.] Would you /please/ stop doing that? It messes up the threads, giving a disjointed view in both groups with some posts missing and others appearing from nowhere as people correct your inappropriate follow-up groups. If you want to talk about C specifically, start a thread in comp.lang.c. If you want to talk about C++ specifically, start a thread in comp.lang.c++. When a thread is discussing both languages, such as this one (look at the subject), and everyone else is keeping both newsgroups in the followups, then you should do that too. There are only two good reasons why you should consider setting followups. One is if a branch is clearly diverging to a side-topic that is applicable to one group only, and is of no interest to people in the other group. This will normally be accompanied by a subject change. The other is when someone posts to the wrong group, and you are informing them of where they ought to be. Neither applies here. Note that "I only follow the one group comp.lang.c" is /not/ a relevant reason. Your follow-up settings mess up things particularly badly for those that happen to follow only comp.lang.c++. Your posts in this thread are as topical, relevant and interesting in both groups.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-30 16:39 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220930092247.654@kylheku.com> |
| In reply to | #167912 |
On 2022-09-30, David Brown <david.brown@hesbynett.no> wrote: > On 29/09/2022 19:58, Kaz Kylheku wrote: >> ["Followup-To:" header set to comp.lang.c.] > > Would you /please/ stop doing that? It messes up the threads, giving a > disjointed view in both groups with some posts missing and others > appearing from nowhere as people correct your inappropriate follow-up > groups. The question is, why do I do that? It's a bad idea in most cases. The workflow is that SLRN, in the cross-posting situation, brings up a a prompt like this: Crosspost using: (F)ollowup-To, (A)ll groups, (T)his group, (C)ancel There are times when I hit 'f' by mistake. (Could it be because 'f' is also the command for initiating the follow-up in the first place?) Among those times, there are times when I subsequently neglect to edit out the header associated body line. Maybe I jump to the bottom too fast, that being the fundamental race in Usenet, and all. Drilling into it now, I see that if the configuration option netiquette_warnings is set to 0, the prompt goes away, and the (A)ll behavior prevails. It's unfortunate that the warnings are lumped together under one option like that. I'd like to be warned if there is too much quoted material, or long lines and such. It can be solved in another way: Vim can easily be programmed to dispatch an action when a file named .followup is opened; that can be used to make some automatic edits. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-01 12:47 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th95ra$1ajc3$1@dont-email.me> |
| In reply to | #167913 |
On 30/09/2022 18:39, Kaz Kylheku wrote: > On 2022-09-30, David Brown <david.brown@hesbynett.no> wrote: >> On 29/09/2022 19:58, Kaz Kylheku wrote: >>> ["Followup-To:" header set to comp.lang.c.] >> >> Would you /please/ stop doing that? It messes up the threads, giving a >> disjointed view in both groups with some posts missing and others >> appearing from nowhere as people correct your inappropriate follow-up >> groups. > > The question is, why do I do that? It's a bad idea in most cases. > > The workflow is that SLRN, in the cross-posting situation, brings up a a > prompt like this: > > Crosspost using: (F)ollowup-To, (A)ll groups, (T)his group, (C)ancel > > There are times when I hit 'f' by mistake. (Could it be because 'f' is also > the command for initiating the follow-up in the first place?) > Among those times, there are times when I subsequently neglect to edit out the > header associated body line. Maybe I jump to the bottom too fast, > that being the fundamental race in Usenet, and all. > > Drilling into it now, I see that if the configuration option > netiquette_warnings is set to 0, the prompt goes away, and the (A)ll > behavior prevails. > > It's unfortunate that the warnings are lumped together under one > option like that. I'd like to be warned if there is too much quoted > material, or long lines and such. > > It can be solved in another way: Vim can easily be programmed to > dispatch an action when a file named .followup is opened; that > can be used to make some automatic edits. > No software is perfect - there's always something that is inconvenient or awkward. And there are always some cases where you want to do something different from the norm. Anyway, thanks for the explanation - and now back to the interesting C and C++ stuff!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-28 14:17 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <%HYYK.59589$kEr7.27657@fx44.iad> |
| In reply to | #167885 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: >On 2022-09-27, Scott Lurndal <scott@slp53.sl.home> wrote: >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>>["Followup-To:" header set to comp.lang.c.] >>>On 2022-09-27, Juha Nieminen <nospam@thanks.invalid> 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 >>> >>>That's a pretty stupid thing to fuss about in a language in which >>>the very *functions* have unspecified argument evaluation order. >>> >>>If you create an object using this kind of paradigm: >>> >>> obj *make_object(obj *arg1, obj *arg2, obj *arg3); >>> >>> make_object(complex_expr, another_complex_expr, third_complex_expr); >>> >>>the arguments expressions in your constructor call will be evaluated in >>>many possible orders, including interleaved with each other. >>> >>>*THAT* is the fucking place where you want to introduce order: >>>in an imperative, effect-full language, you want function arguments >>>to be strictly evaluated. >> >> To be fair, the language allows you to explicity order them >> rather easily: >> >> 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. It's also about readability. A 256-character line containing all the complex expressions in the function call is broken by design.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-28 09:40 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th0top$amr5$1@dont-email.me> |
| In reply to | #167869 |
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-09-28 07:56 -0400 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <WDWYK.39403$NNy7.25441@fx39.iad> |
| In reply to | #167888 |
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-28 15:50 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th1jfp$ce1o$1@dont-email.me> |
| In reply to | #167892 |
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]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-28 14:21 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <ALYYK.59591$kEr7.32291@fx44.iad> |
| In reply to | #167895 |
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]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-28 16:17 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <9s_YK.697795$BKL8.419141@fx15.iad> |
| In reply to | #167898 |
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]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-28 16:56 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220928095115.641@kylheku.com> |
| In reply to | #167900 |
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]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-28 18:48 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <uG0ZK.511950$Ny99.395114@fx16.iad> |
| In reply to | #167901 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: >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. Recall that in early C compilers, the internal passes were handled by separate executables (cpp, c0 (lex,parse), c1(codegen) and c2(optimization)).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-29 11:50 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th3pp1$kq18$1@dont-email.me> |
| In reply to | #167898 |
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]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web