Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86469 > 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 109 — 28 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??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:07 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:42 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 15:24 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-09-26 09:00 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 16:11 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-09-26 09:22 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 09:41 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:46 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 16:15 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 20:43 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 20:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 22:56 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-22 23:15 +0100
g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 13:44 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Bart <bc@freeuk.com> - 2022-09-23 13:53 +0100
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:31 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:53 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 16:21 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-24 17:05 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] red floyd <no.spam.here@its.invalid> - 2022-09-24 12:33 -0700
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Muttley@dastardlyhq.com - 2022-09-25 08:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 00:08 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-23 12:13 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 10:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-09-23 03:14 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 12:57 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-02 13:53 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-07 16:00 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-08 10:57 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-09 08:33 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:58 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:03 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? red floyd <no.spam.here@its.invalid> - 2022-09-23 14:43 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-23 12:35 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-23 12:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:09 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 13:25 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:13 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-26 10:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-09-27 09:56 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-27 10:50 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 01:57 -0400
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2022-09-22 14:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-23 03:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:50 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:37 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:19 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 13:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 14:31 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-26 16:05 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:36 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:21 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 13:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-27 16:53 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 10:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 18:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 01:30 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 08:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-28 10:43 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 13:15 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 23:38 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:46 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-29 17:58 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-30 09:17 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 16:39 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-01 12:47 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 17:20 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-30 20:59 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 07:31 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 13:38 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-02 13:00 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 16:20 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-10-02 22:05 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-03 11:58 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 07:24 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 09:40 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 07:56 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 15:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:21 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 16:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 16:56 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-28 20:31 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? doctor@doctor.nl2k.ab.ca (The Doctor) - 2022-09-28 21:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 19:33 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-26 09:04 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:27 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 08:11 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:10 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 17:30 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 11:00 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-28 13:33 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-09-25 19:31 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-26 04:53 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 12:59 -0700
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Opus <ifonly@youknew.org> - 2022-09-23 18:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:08 -0400
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| 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 | #86614 |
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 | #86617 |
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 | #86614 |
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 | #86643 |
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 | #86646 |
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 | #86650 |
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 | #86646 |
["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 | 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 | #86657 |
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 | #86663 |
["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 | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2022-09-28 10:43 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <jpifp1Fcsf2U1@mid.individual.net> |
| In reply to | #86667 |
On 2022-09-28 at 10: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: >> ... >>>> 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. > So you write comlicated expressions with lots of side effects, without considering the order of those side effects. Doesn't sound like a good way to write code.
[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 | #86667 |
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 | #86686 |
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 | #86692 |
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]
| 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 | #86697 |
["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-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 | #86708 |
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 | #86721 |
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 | #86732 |
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 | 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 | #86708 |
[ 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 | #86735 |
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-10-02 07:31 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <86h70mjo0o.fsf@linuxsc.com> |
| In reply to | #86736 |
Paavo Helde <eesnimi@osa.pri.ee> writes: > 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. That claim is very hard to believe. > 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. I feel obliged to mention that comments about C++ are not topical in comp.lang.c, and the Newsgroups: line should have been adjusted accordingly.
[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