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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-26 13:55 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgs3un$3nr9v$1@dont-email.me> |
| In reply to | #167853 |
On 26/09/2022 10:19, Juha Nieminen wrote: > In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >>> I wouldn't call embedded programming to be a "small niche". >>> >>> (Well, the subset of embedded programming that happens on processors >>> so small that they can't run Linux, at least.) >> >> And it will be a /long/ time before Rust has significant market share in >> these devices. Despite wanting the newest microcontrollers, embedded >> programmers are a conservative bunch - C90 is, I think, the most popular >> choice of language. (Yes, C90 - not C99.) > > In my experience working in the field I think C99 has gained popularity > even among many (although not all) old-school "as bare metal as possible" > embedded C programmers. > Certainly C99 has gained popularity, but I think many C programmers would be surprised to see how common C90 still is. It's also common to have a kind of mixture of C90 with bits of C99 - people might use single line comments but define all their local variables uninitialised at the top of a function and use "int" when they should use "bool". And the use of compiler extensions is also common - for many microcontrollers, it is unavoidable. > Designated initializers are perhaps the best thing that has happened to C > during its entire existence (which is why they have been widely adopted > in the Linux kernel, and many other major C projects). 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++).
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-26 14:31 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgsd4k$lcr$1@gioia.aioe.org> |
| In reply to | #167855 |
In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >> Designated initializers are perhaps the best thing that has happened to C >> during its entire existence (which is why they have been widely adopted >> in the Linux kernel, and many other major C projects). > > 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. It is indeed highly subjective. Many C programmers are of the opinion that declaring variables within the code implementation is actually a bad thing, and they still prefer declaring all the variables of the function at the beginning. (If I'm not mistaken, this is actually one of the style requirements of the Linux kernel code. Although I'm not sure if it's outright required or just recommended.) When you have seen and programmed with designated initializers, however, you really start to appreciate them. If you are writing eg. a Linux kernel module, you essentially "fill out" some particular structs with the data required for your module to work. The great thing about designated initializers is that not only are these struct initializations much more readable, but moreover the code doesn't need to care what the order of the member variables is, or if there are more member variables before, after, or in-between the ones being initialized. It really makes a lot easier. (It also allows for those structs to be changed by eg. adding new member variables without breaking tons of existing code.) > 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. (Not having to care about the order allows for refactoring of the struct by swapping things around. Also, the order of the member variables in the struct might have been chosen for space efficiency, while in the initialization you can use a more logical order of initialization by grouping related values together.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-26 16:05 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgsf3j$1mg0$1@gioia.aioe.org> |
| In reply to | #167858 |
On 26/09/2022 15:31, Juha Nieminen wrote:
> In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote:
>>> Designated initializers are perhaps the best thing that has happened to C
>>> during its entire existence (which is why they have been widely adopted
>>> in the Linux kernel, and many other major C projects).
>>
>> 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.
>
> It is indeed highly subjective. Many C programmers are of the opinion
> that declaring variables within the code implementation is actually a
> bad thing, and they still prefer declaring all the variables of the
> function at the beginning. (If I'm not mistaken, this is actually one
> of the style requirements of the Linux kernel code. Although I'm not
> sure if it's outright required or just recommended.)
>
> When you have seen and programmed with designated initializers, however,
> you really start to appreciate them. If you are writing eg. a Linux
> kernel module, you essentially "fill out" some particular structs with
> the data required for your module to work. The great thing about
> designated initializers is that not only are these struct initializations
> much more readable, but moreover the code doesn't need to care what the
> order of the member variables is, or if there are more member variables
> before, after, or in-between the ones being initialized. It really makes
> a lot easier. (It also allows for those structs to be changed by eg.
> adding new member variables without breaking tons of existing code.)
I don't like designated initialisers.
First because my private C compiler doesn't support them, so I have to
switch to another when some code uses them, or edit it to remove the
dependency.
But also, they tend to be used gratuitously; I've actually seen examples
like this:
typedef struct {int x, y;} Point;
Point p = {100, 200}; // without designated initialisers
Point q = {110, 220};
Point r = {.x = 100, .y = 200};
Point s = {.y = 220, .x = 110};
The designated ones introduce too much clutter for a simple struct like
this, but also people feel free mix up the order, just because they can.
So you can't as easily see the patterns like those in the first example,
or they can be misleading unless you keep an eye on those names.
Another problem is when you decide to change the member names,
especially when the names weren't particularly important. Just changing
the order can mean data within the struct will get mixed up.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-27 06:36 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgu5ki$1tqu$1@gioia.aioe.org> |
| In reply to | #167860 |
In comp.lang.c++ Bart <bc@freeuk.com> wrote:
> I don't like designated initialisers.
>
> First because my private C compiler doesn't support them, so I have to
> switch to another when some code uses them, or edit it to remove the
> dependency.
That's a rather strange reason not to like them.
> But also, they tend to be used gratuitously; I've actually seen examples
> like this:
>
> typedef struct {int x, y;} Point;
>
> Point p = {100, 200}; // without designated initialisers
> Point q = {110, 220};
>
> Point r = {.x = 100, .y = 200};
> Point s = {.y = 220, .x = 110};
>
> The designated ones introduce too much clutter for a simple struct like
> this, but also people feel free mix up the order, just because they can.
> So you can't as easily see the patterns like those in the first example,
> or they can be misleading unless you keep an eye on those names.
You are assuming that the struct is directly visible there and extremely
obvious what it contains. It's not always that obvious. For example, this
is a very typical way to register a device driver in the Linux kernel
(directly from the source codes):
//----------------------------------------------------------
static struct platform_driver ftgpio_gpio_driver = {
.driver = {
.name = "ftgpio010-gpio",
.of_match_table = of_match_ptr(ftgpio_gpio_of_match),
},
.probe = ftgpio_gpio_probe,
.remove = ftgpio_gpio_remove,
};
builtin_platform_driver(ftgpio_gpio_driver);
//----------------------------------------------------------
What does that 'platform_driver' struct look like? Does it contain member
variables other than those being initialized here? Are they in this
particular order? I have no idea. And I don't have to have an idea.
And consider how much more readable the above initialization is.
It pretty much documents itself.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-27 11:21 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgufba$1dae$1@dont-email.me> |
| In reply to | #167858 |
On 26/09/2022 16:31, Juha Nieminen wrote: > In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >>> Designated initializers are perhaps the best thing that has happened to C >>> during its entire existence (which is why they have been widely adopted >>> in the Linux kernel, and many other major C projects). >> >> 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. > > It is indeed highly subjective. Many C programmers are of the opinion > that declaring variables within the code implementation is actually a > bad thing, and they still prefer declaring all the variables of the > function at the beginning. (If I'm not mistaken, this is actually one > of the style requirements of the Linux kernel code. Although I'm not > sure if it's outright required or just recommended.) Somewhat bizarrely, the coding style for the Linux kernel allows (AFAIUI) very complex initialisation of the variables at the start of a function, but no mixing of declarations and statements. So it partially encourages the "don't define your variables until you have good data for initialisation" style, but by disallowing statements between the declarations it pushes people towards unwieldy and overly complex expressions. I assume this is because until recently, the kernel was based on C90 - but it was C90 with gcc extensions. The gcc "gnu90" pseudo-standard supports mixed declarations and statements, just like C99. I understand that some people like a clean list of uninitialised variable declarations at the start of a function, much like in Pascal. I don't think it is a good way to code, but people have their preferences. The Linux kernel style looks to me like a mongrel hybrid that does not lead to clean and clear code. > > When you have seen and programmed with designated initializers, however, > you really start to appreciate them. I /do/ use them, and appreciate them - but I don't find them to be such a revolution that you apparently do. Maybe that's just a matter of the kind of code I write compared to the kind of code you write. > If you are writing eg. a Linux > kernel module, you essentially "fill out" some particular structs with > the data required for your module to work. The great thing about > designated initializers is that not only are these struct initializations > much more readable, but moreover the code doesn't need to care what the > order of the member variables is, or if there are more member variables > before, after, or in-between the ones being initialized. It really makes > a lot easier. (It also allows for those structs to be changed by eg. > adding new member variables without breaking tons of existing code.) > >> 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?). > > (Not having to care about the order allows for refactoring of the struct > by swapping things around. Also, the order of the member variables in > the struct might have been chosen for space efficiency, while in the > initialization you can use a more logical order of initialization by > grouping related values together.) Yes.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-27 13:26 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgutm0$pp1$1@gioia.aioe.org> |
| In reply to | #167865 |
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), 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". 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.)
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2022-09-27 16:53 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <jpgh3rF3np3U1@mid.individual.net> |
| In reply to | #167869 |
On 2022-09-27 at 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), 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". > 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.) The thing is that destructors are supposed to be called in the reverse order of construction (to allow "unchaining" any dependencies again). This becomes really messy if we allow different construction order in different places of the program. I belive the strictness here is a do-the-right-thing attempt, avoiding the constructor initializer list reordering that we have always had. When adding a new feature, try to avoid the old mistakes!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-28 10:32 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th10r1$augs$1@dont-email.me> |
| In reply to | #167873 |
On 27/09/2022 16:53, Bo Persson wrote: > On 2022-09-27 at 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), 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". >> 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.) > > The thing is that destructors are supposed to be called in the reverse > order of construction (to allow "unchaining" any dependencies again). > This becomes really messy if we allow different construction order in > different places of the program. > > I belive the strictness here is a do-the-right-thing attempt, avoiding > the constructor initializer list reordering that we have always had. > When adding a new feature, try to avoid the old mistakes! > The old mistake (IMHO) is that re-ordering was not allowed, and they are re-making it here. Aggregate initialisation in C++ is already limited to classes without user-declared or inherited constructors. I think you'd have to try hard to make a class for which designated initialisers are allowed, but the order of initialisation or destruction matters.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-27 18:18 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220927111408.394@kylheku.com> |
| In reply to | #167869 |
["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. But no, we can't have that; let's obsess over order in the initializer syntax. C++ is a shizophrenic language designed by a disingenuous committee whose main aim is self-preservation and not the betterment of a programming language.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-09-27 22:32 +0300 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgvj59$4kq5$2@dont-email.me> |
| In reply to | #167880 |
27.09.2022 21:18 Kaz Kylheku kirjutas: > ["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. In practice this is not a problem, one just needs to avoid side effects in those complex expressions, which would be a good idea anyway even with a strict evaluation order. > > But no, we can't have that; let's obsess over order in the initializer > syntax. These situations are not really comparable. In a function call: 1. It is easy to destruct the constructed arguments in reverse order of creation, whatever order that might be. 2. One argument cannot access another argument, so they cannot have inter-dependencies. With class members: 1. Without a defined order, it might become very complicated to destroy the members in reverse order of creation. 2. The members can refer to each other, so this defined order must be known to the programmer, so that he can avoid invalid references. So it's more like that the language designers would have happily let also the member initialization order to be arbitrary, it's just that by technical reasons this is not feasible.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-27 23:52 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220927154035.51@kylheku.com> |
| In reply to | #167881 |
On 2022-09-27, Paavo Helde <eesnimi@osa.pri.ee> wrote: > 27.09.2022 21:18 Kaz Kylheku kirjutas: >> ["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. > > In practice this is not a problem, one just needs to avoid side effects > in those complex expressions, which would be a good idea anyway even > with a strict evaluation order. In practice, it's not a *known* problem, because you've done whatever it takes to remove known instances where it is a problem. If it's not a problem for functions, why would it be a problem for initializers? >> But no, we can't have that; let's obsess over order in the initializer >> syntax. > > These situations are not really comparable. In a function call: They are completely comparable. Construction of a object is a functional abstraction. > > 1. It is easy to destruct the constructed arguments in reverse order of > creation, whatever order that might be. > 2. One argument cannot access another argument, so they cannot have > inter-dependencies. The order in which initializers are evaluated is independent of the order of construction. In a sane language, everything is ordered. Say you ahve some structure with a b c members. You write a construcctor for it which takes (x y z) arguments and initializes c = y, b = x, a = z. So can have it so that the constructor's argument expressions are evaluated left to right, x y z, and the values are then initialized in a b c order z x y. C++ could have it that the base class initializers in a constructor are evaluated left-to-right, as they appear, but then are actually called in the order in which they are declared in the class. Any side effects which are in the initializing expressions themselves happen left to right. Those side effects imbued into the constructors themselves happen in the object order. > With class members: > > 1. Without a defined order, it might become very complicated to destroy > the members in reverse order of creation. Rather, what becomes complicated is convincing yourself that the program is correct regardless of what order is chosen, since testing one build of the code covers only one order. It's not hard to code the thing so that the order doesn't matter, and arguably a good idea. (Regardless of that, being able to rely on the order to to surprisingly change due to a compiler flag is good.) Members of an object shouldn't depend on what other members there are in the object and in what order. When a member is being destroyed, it shouldn't be messing with any adjacent objects; just clean up its own local resources and bugger off, without assuming that anything around it is valid. That said, a clean-up order defined along the subclass/superclass relationships is a good idea. However, which order is a good idea is debatable. (The mistake in C++ is that it supports only the order that the destruction of a derived class is before the base class. In fact, it would be more useful if the there was a pre-destruction hook executed in the derived class, followed by base destruction, followed by a post-destruction hook, only after which the object becomes garbage. This is because dependencies between the base and drived parts can go either way. A derived class can provide services used by the base, including resources that the base depends on, and those resources should go away last. But it could be the other way also.) > 2. The members can refer to each other, so this defined order must be > known to the programmer, so that he can avoid invalid references. These objects should probably not be referencing each other at destruction time, where the concern is just to release resources and such, which shouldn't require collaboration. Managing resources could involve collaboration of parent object and contained member (or base - derived). Siblings shouldn't know about each other as far clean-up goes; that's just some kind of code smell. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-27 19:57 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <7BIYK.100167$ocy7.42366@fx38.iad> |
| In reply to | #167880 |
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).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-28 00:03 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220927165229.354@kylheku.com> |
| In reply to | #167882 |
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. A C-to-C transpiler could do it. I've often thought about a safer C which works by source to source transformation, doing things like this.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-09-28 01:30 -0400 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th0m63$a507$1@dont-email.me> |
| In reply to | #167885 |
On 9/27/22 20:03, Kaz Kylheku wrote: > On 2022-09-27, Scott Lurndal <scott@slp53.sl.home> wrote: ... >> 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. You only do it when the order actually matters, not automatically for all function calls. In every case where the order doesn't matter, that leaves the compiler free to reorder the evaluations in whichever order is most convenient/fastest.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-28 08:26 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220928012034.643@kylheku.com> |
| In reply to | #167887 |
["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: > ... >>> 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. > > 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; I'm not looking at thousands of function calls to classify them into whether they are stuffed with side effects whose order matters or not. > In every case where the order doesn't matter, that > leaves the compiler free to reorder the evaluations in whichever order > is most convenient/fastest. In cases where the order doesn't matter, the compiler can still reorder the evaluations even if they are expressed in a pattern which constraints the abstract order. The business of unspecified evaluation orders is mostly geared toward helping compilers from 1982 generate better code with less analysis. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-28 14:18 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <yIYYK.59590$kEr7.6844@fx44.iad> |
| In reply to | #167889 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: >["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: >> ... >>>> 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. >> >> 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; >I'm not looking at thousands of function calls to classify them >into whether they are stuffed with side effects whose order >matters or not. Do it when you write the code in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-28 15:26 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220928082419.710@kylheku.com> |
| In reply to | #167897 |
On 2022-09-28, 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-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: >>> ... >>>>> 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. >>> >>> 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; >>I'm not looking at thousands of function calls to classify them >>into whether they are stuffed with side effects whose order >>matters or not. > > Do it when you write the code in the first place. OK, I need to be a greenfield project with no inherited code, developed solo. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-09-28 13:15 -0400 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th1vf4$dfa0$1@dont-email.me> |
| In reply to | #167889 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-28 23:38 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220928162825.705@kylheku.com> |
| In reply to | #167902 |
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.
--
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-09-29 11:46 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th3pik$kpdd$1@dont-email.me> |
| In reply to | #167905 |
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. Reality
can't work that way. Programmers have to take responsibility for
writing correct code.
/Everyone/ has their own personal choice of things they think are flaws
in the language, or common coding errors that could be reduced by a
change to the language. Equally, there will be people who prefer that
aspect of the language remains as it is. This applies to all
programming languages - it is not a C or C++ thing.
We can all sympathise with having to deal with code written by others
that is not as good as we'd like.
But remember that whenever one person says "eliminates a class of bugs",
others see "eliminates a class of optimisations" or "eliminates a type
of coding flexibility" or "eliminates scope for static error detection
or run-time sanitizer tracking".
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web