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 | 19 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-09-28 19:33 -0400 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <%Q4ZK.110023$tRy7.73069@fx36.iad> |
| In reply to | #167895 |
On 9/28/22 9:50 AM, David Brown wrote: > On 28/09/2022 13:56, Richard Damon wrote: >> On 9/28/22 3:40 AM, David Brown wrote: >>> On 27/09/2022 15:26, Juha Nieminen wrote: >>>> In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >>>>>>> However, it's taken until C++20 to get designated >>>>>>> initialisers in C++, which suggests that they were not viewed as the >>>>>>> most important feature (though there has certainly been plenty of >>>>>>> call >>>>>>> for them in C++). >>>>>> >>>>>> And C++20 ruined one of the best aspects of them: The fact that >>>>>> you don't >>>>>> need to know the order in which the member variables have been >>>>>> defined >>>>>> in the struct. >>>>> >>>>> I agree with that. It strikes me as a strange requirement - just like >>>>> the insistence that initialisers in a constructor match the >>>>> declaration >>>>> order. Perhaps there is some clear, logical reason for that >>>>> restriction >>>>> (and perhaps someone could tell me what it is?). >>>> >>>> I understand that C++ wants member variables to be initialized in >>>> strict >>>> order of declaration (which in the case of C++ in particular can make >>>> quite a difference if those initializations have side effects), >>> >>> I understand that C++ /does/ insist on following the order of >>> declaration - I don't understand /why/. I appreciate that the >>> initialisations could have side effects, so it makes sense that the >>> initialisations are always carried out in the order of declaration - >>> but not that the order must be followed syntactically when writing >>> the constructor. (Alternatively, the language could have said that >>> the initialisations are carried out in the order given in the list in >>> the constructor - either would have worked, as long as it was clear >>> and consistent.) >>> >>> For example, if I have a class containing some ints and doubles, and >>> some flags, then I might want to order the member declarations to >>> pack nicely and match a cache line in total size. But I might prefer >>> the initialisations in constructors to follow a logical order that is >>> different. I fail to see a good reason why that is not allowed. >>> (Again, this is quite possibly just that I am ignorant of the good >>> reason.) >> >> The problem with the order listed in the constructor is that there >> might not be just one constructor, but several, that list the order >> differently. That gives the destructor problems, as it doesn't know >> what order to destruct the object, and the constructor's >> implementation might not even be visible at the point of generating >> the code for the destructor. >> >> That forces ALL classes to add hidden members that record the order of >> construction for this instance of the class, which violates the >> principle of trying to not pay for things you don't need. > > That all suggests it is a good idea for initialisers to be executed in > the order given in the class declaration (since practicality dictates > having one fixed order, that seems the sensible choice). It does /not/ > suggest that the same order should be required when listing the > initialisers. Right, because to allow otherwise adds a LOT of overhead. That is what I was implying. That IS the rules of C++, the initialzers are processed in the order the members are listed in the class definition, regardless of the order specified in the constructor. > >> >> Using the order from the class definition is the simple solution. >> >> Note, for your class with ints and doubles, it doesn't matter, as the >> destructor is trivial. >> > And yet C++ won't let me re-order them in the initialiser list. It will > let me use whatever order I want inside the body of the constructor > using assignment, and then the compiler will re-order to match exactly > the same code that I'd get with initialisers - whatever is the most > efficient code. You can specify the initializer list in what ever order you want, though a good compiler will have the option to give you are warning if the listed order isn't the order that it will do them in. In the body of the construtor, it is required to do them in the order listed, or at least act "as if" it did them in the order listed. Because of the "as if" rule, if you can't tell the difference, it doesn't matter what order they are done in.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2022-09-26 09:04 -0600 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <jpdtc1Fltd5U1@mid.individual.net> |
| In reply to | #167855 |
On 9/26/22 05:55, David Brown wrote: > Designated initialisers are certainly nice, but I would not call them > the "best" feature of C99. If I were to pick one favourite C99 feature, > it would be mixing declarations and statements - but such choices are > highly subjective. However, it's taken until C++20 to get designated > initialisers in C++, which suggests that they were not viewed as the > most important feature (though there has certainly been plenty of call > for them in C++). I'd go with the ability to place declarations close to the code using them also. Throwing in curly braces worked but it wasn't too elegant.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-27 11:27 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgufla$1ebg$1@dont-email.me> |
| In reply to | #167859 |
On 26/09/2022 17:04, rbowman wrote: > On 9/26/22 05:55, David Brown wrote: >> Designated initialisers are certainly nice, but I would not call them >> the "best" feature of C99. If I were to pick one favourite C99 >> feature, it would be mixing declarations and statements - but such >> choices are highly subjective. However, it's taken until C++20 to get >> designated initialisers in C++, which suggests that they were not >> viewed as the most important feature (though there has certainly been >> plenty of call for them in C++). > > I'd go with the ability to place declarations close to the code using > them also. Throwing in curly braces worked but it wasn't too elegant. > That is one of the important benefits of being able to mix declarations and statements, so I think we agree on our favourite feature. It is not the only benefit, however. Declaring your variable only when you have something useful to put in it lets you make many such variables "const" - then both the programmer and the compiler know it is not going to change. It makes adding new local variables "cheap" - so instead of re-using a single "int temp;" variable in a dozen places in the function, you have many const variables that do one thing, with one name, and you always know exactly what they are.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-27 12:41 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgunh4$1tnm$1@gioia.aioe.org> |
| In reply to | #167866 |
On 27/09/2022 10:27, David Brown wrote: > On 26/09/2022 17:04, rbowman wrote: >> On 9/26/22 05:55, David Brown wrote: >>> Designated initialisers are certainly nice, but I would not call them >>> the "best" feature of C99. If I were to pick one favourite C99 >>> feature, it would be mixing declarations and statements - but such >>> choices are highly subjective. However, it's taken until C++20 to >>> get designated initialisers in C++, which suggests that they were not >>> viewed as the most important feature (though there has certainly been >>> plenty of call for them in C++). >> >> I'd go with the ability to place declarations close to the code using >> them also. Throwing in curly braces worked but it wasn't too elegant. >> > > That is one of the important benefits of being able to mix declarations > and statements, so I think we agree on our favourite feature. > > It is not the only benefit, however. Declaring your variable only when > you have something useful to put in it lets you make many such variables > "const" - then both the programmer and the compiler know it is not going > to change. It makes adding new local variables "cheap" - so instead of > re-using a single "int temp;" variable in a dozen places in the > function, you have many const variables that do one thing, with one > name, and you always know exactly what they are. Sounds the opposite to me. Instead of knowing that 'temp' is an int, now you have a dozen variables called 'temp' that can all have different types. You need to double-check carefully to know what type they have. But if the type is unimportant, they are all ints anyway, now you are replicating the same type info in a dozen places. One day you decide to change 'int temp' to 'unsigned int temp', then it's a lot more work! > Declaring your variable only when you have something useful to put in > it lets you make many such variables "const" I tried introducing 'let' into my own languages (declare a variable that is assigned to only once). But I like declarations at the top of a function. Since 'let' variables *must* be initialised when declared, and the init expression might not be ready on function entry, then sometimes they have to be moved into the middle of the code. To me that was a significant flaw.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-27 15:22 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87a66kvqw6.fsf@bsb.me.uk> |
| In reply to | #167867 |
Bart <bc@freeuk.com> writes: > On 27/09/2022 10:27, David Brown wrote: <cut> >> ... Declaring your variable only >> when you have something useful to put in it lets you make many such >> variables "const" - then both the programmer and the compiler know it >> is not going to change. It makes adding new local variables "cheap" >> - so instead of re-using a single "int temp;" variable in a dozen >> places in the function, you have many const variables that do one >> thing, with one name, and you always know exactly what they are. > > Sounds the opposite to me. Instead of knowing that 'temp' is an int, > now you have a dozen variables called 'temp' that can all have > different types. You need to double-check carefully to know what type > they have. I suspect there's a typo. I doubt DB intended to suggest the same generic name for the various uses the 'temp' was dragooned into. One would use 'temp' when no other name covers all the uses, but 'const int array_stride', 'const int offset' etc for the specifics. As for the type, the point is that the declaration will be close to the use -- usually right there a line or two away. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-27 18:13 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgv7g5$3jo7$1@dont-email.me> |
| In reply to | #167871 |
On 27/09/2022 16:22, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 27/09/2022 10:27, David Brown wrote: > <cut> >>> ... Declaring your variable only >>> when you have something useful to put in it lets you make many such >>> variables "const" - then both the programmer and the compiler know it >>> is not going to change. It makes adding new local variables "cheap" >>> - so instead of re-using a single "int temp;" variable in a dozen >>> places in the function, you have many const variables that do one >>> thing, with one name, and you always know exactly what they are. >> >> Sounds the opposite to me. Instead of knowing that 'temp' is an int, >> now you have a dozen variables called 'temp' that can all have >> different types. You need to double-check carefully to know what type >> they have. > > I suspect there's a typo. I doubt DB intended to suggest the same > generic name for the various uses the 'temp' was dragooned into. One > would use 'temp' when no other name covers all the uses, but 'const int > array_stride', 'const int offset' etc for the specifics. > Yes, that's right. I don't think I can reasonably blame a typo here - I simply worded myself rather badly. (As an aside, I would prefer that C allowed the re-declaration of the same name within the same block, so that you can re-use the same name if that would have been more appropriate.) > As for the type, the point is that the declaration will be close to the > use -- usually right there a line or two away. > Indeed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-27 16:50 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgv2ja$34g9$1@dont-email.me> |
| In reply to | #167867 |
On 27/09/2022 13:41, Bart wrote:
> On 27/09/2022 10:27, David Brown wrote:
>> On 26/09/2022 17:04, rbowman wrote:
>>> On 9/26/22 05:55, David Brown wrote:
>>>> Designated initialisers are certainly nice, but I would not call
>>>> them the "best" feature of C99. If I were to pick one favourite C99
>>>> feature, it would be mixing declarations and statements - but such
>>>> choices are highly subjective. However, it's taken until C++20 to
>>>> get designated initialisers in C++, which suggests that they were
>>>> not viewed as the most important feature (though there has certainly
>>>> been plenty of call for them in C++).
>>>
>>> I'd go with the ability to place declarations close to the code using
>>> them also. Throwing in curly braces worked but it wasn't too elegant.
>>>
>>
>> That is one of the important benefits of being able to mix
>> declarations and statements, so I think we agree on our favourite
>> feature.
>>
>> It is not the only benefit, however. Declaring your variable only
>> when you have something useful to put in it lets you make many such
>> variables "const" - then both the programmer and the compiler know it
>> is not going to change. It makes adding new local variables "cheap" -
>> so instead of re-using a single "int temp;" variable in a dozen places
>> in the function, you have many const variables that do one thing, with
>> one name, and you always know exactly what they are.
>
> Sounds the opposite to me. Instead of knowing that 'temp' is an int,
> now you have a dozen variables called 'temp' that can all have different
> types. You need to double-check carefully to know what type they have.
You don't call them all "temp" !
You give them appropriate names. It's easy to see where they are
declared (if it is not, your functions are too long or messy). And then
you can see exactly what the variable is and what it is doing - not just
its type, but its value and use.
>
> But if the type is unimportant, they are all ints anyway, now you are
> replicating the same type info in a dozen places. One day you decide to
> change 'int temp' to 'unsigned int temp', then it's a lot more work!
>
> > Declaring your variable only when you have something useful to put in
> > it lets you make many such variables "const"
>
> I tried introducing 'let' into my own languages (declare a variable that
> is assigned to only once).
>
Many modern programming languages make unchangeable ("const" in C terms)
objects the default, and require an extra indication (such as the "mut"
keyword in Rust) to say the object can be changed. There are some
languages that go against such trends, trading safety, clarity and
maintainability for short-term gains in rapid coding (people write code
for all sorts of purposes, including small short-term programs).
> But I like declarations at the top of a function. Since 'let' variables
> *must* be initialised when declared, and the init expression might not
> be ready on function entry, then sometimes they have to be moved into
> the middle of the code.
>
> To me that was a significant flaw.
Well, as has been said, much of this is personal preference.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2022-09-27 08:11 -0600 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <jpgeksF3e8sU1@mid.individual.net> |
| In reply to | #167866 |
On 9/27/22 03:27, David Brown wrote: > On 26/09/2022 17:04, rbowman wrote: >> On 9/26/22 05:55, David Brown wrote: >>> Designated initialisers are certainly nice, but I would not call them >>> the "best" feature of C99. If I were to pick one favourite C99 >>> feature, it would be mixing declarations and statements - but such >>> choices are highly subjective. However, it's taken until C++20 to >>> get designated initialisers in C++, which suggests that they were not >>> viewed as the most important feature (though there has certainly been >>> plenty of call for them in C++). >> >> I'd go with the ability to place declarations close to the code using >> them also. Throwing in curly braces worked but it wasn't too elegant. >> > > That is one of the important benefits of being able to mix declarations > and statements, so I think we agree on our favourite feature. > > It is not the only benefit, however. Declaring your variable only when > you have something useful to put in it lets you make many such variables > "const" - then both the programmer and the compiler know it is not going > to change. It makes adding new local variables "cheap" - so instead of > re-using a single "int temp;" variable in a dozen places in the > function, you have many const variables that do one thing, with one > name, and you always know exactly what they are. I'm not fond of 'const'. We have a lot of legacy code where the programmers used it inappropriately so you wind up casting it away. I think they saw it in one declaration and decided it was always needed. Used correctly it's valuable
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-27 18:10 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgv791$3ilt$2@dont-email.me> |
| In reply to | #167870 |
On 27/09/2022 16:11, rbowman wrote: > On 9/27/22 03:27, David Brown wrote: >> On 26/09/2022 17:04, rbowman wrote: >>> On 9/26/22 05:55, David Brown wrote: >>>> Designated initialisers are certainly nice, but I would not call >>>> them the "best" feature of C99. If I were to pick one favourite C99 >>>> feature, it would be mixing declarations and statements - but such >>>> choices are highly subjective. However, it's taken until C++20 to >>>> get designated initialisers in C++, which suggests that they were >>>> not viewed as the most important feature (though there has certainly >>>> been plenty of call for them in C++). >>> >>> I'd go with the ability to place declarations close to the code using >>> them also. Throwing in curly braces worked but it wasn't too elegant. >>> >> >> That is one of the important benefits of being able to mix >> declarations and statements, so I think we agree on our favourite >> feature. >> >> It is not the only benefit, however. Declaring your variable only >> when you have something useful to put in it lets you make many such >> variables "const" - then both the programmer and the compiler know it >> is not going to change. It makes adding new local variables "cheap" - >> so instead of re-using a single "int temp;" variable in a dozen places >> in the function, you have many const variables that do one thing, with >> one name, and you always know exactly what they are. > > I'm not fond of 'const'. We have a lot of legacy code where the > programmers used it inappropriately so you wind up casting it away. I > think they saw it in one declaration and decided it was always needed. > Used correctly it's valuable Is it not better just to say that you are not fond of incorrect and badly written code? If you have code written by people who don't know how to use "const" properly, you should not let that stop you using it when it is useful.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2022-09-27 17:30 -0600 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <jphfbtF8bpfU1@mid.individual.net> |
| In reply to | #167877 |
On 9/27/22 10:10, David Brown wrote: > On 27/09/2022 16:11, rbowman wrote: >> On 9/27/22 03:27, David Brown wrote: >>> On 26/09/2022 17:04, rbowman wrote: >>>> On 9/26/22 05:55, David Brown wrote: >>>>> Designated initialisers are certainly nice, but I would not call >>>>> them the "best" feature of C99. If I were to pick one favourite >>>>> C99 feature, it would be mixing declarations and statements - but >>>>> such choices are highly subjective. However, it's taken until >>>>> C++20 to get designated initialisers in C++, which suggests that >>>>> they were not viewed as the most important feature (though there >>>>> has certainly been plenty of call for them in C++). >>>> >>>> I'd go with the ability to place declarations close to the code >>>> using them also. Throwing in curly braces worked but it wasn't too >>>> elegant. >>>> >>> >>> That is one of the important benefits of being able to mix >>> declarations and statements, so I think we agree on our favourite >>> feature. >>> >>> It is not the only benefit, however. Declaring your variable only >>> when you have something useful to put in it lets you make many such >>> variables "const" - then both the programmer and the compiler know it >>> is not going to change. It makes adding new local variables "cheap" >>> - so instead of re-using a single "int temp;" variable in a dozen >>> places in the function, you have many const variables that do one >>> thing, with one name, and you always know exactly what they are. >> >> I'm not fond of 'const'. We have a lot of legacy code where the >> programmers used it inappropriately so you wind up casting it away. I >> think they saw it in one declaration and decided it was always needed. >> Used correctly it's valuable > > Is it not better just to say that you are not fond of incorrect and > badly written code? If you have code written by people who don't know > how to use "const" properly, you should not let that stop you using it > when it is useful. > That is true but dealing with badly written code is part of my life.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-28 00:26 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220927172027.565@kylheku.com> |
| In reply to | #167877 |
["Followup-To:" header set to comp.lang.c.] On 2022-09-27, David Brown <david.brown@hesbynett.no> wrote: > On 27/09/2022 16:11, rbowman wrote: >> On 9/27/22 03:27, David Brown wrote: >>> On 26/09/2022 17:04, rbowman wrote: >>>> On 9/26/22 05:55, David Brown wrote: >>>>> Designated initialisers are certainly nice, but I would not call >>>>> them the "best" feature of C99. If I were to pick one favourite C99 >>>>> feature, it would be mixing declarations and statements - but such >>>>> choices are highly subjective. However, it's taken until C++20 to >>>>> get designated initialisers in C++, which suggests that they were >>>>> not viewed as the most important feature (though there has certainly >>>>> been plenty of call for them in C++). >>>> >>>> I'd go with the ability to place declarations close to the code using >>>> them also. Throwing in curly braces worked but it wasn't too elegant. >>>> >>> >>> That is one of the important benefits of being able to mix >>> declarations and statements, so I think we agree on our favourite >>> feature. >>> >>> It is not the only benefit, however. Declaring your variable only >>> when you have something useful to put in it lets you make many such >>> variables "const" - then both the programmer and the compiler know it >>> is not going to change. It makes adding new local variables "cheap" - >>> so instead of re-using a single "int temp;" variable in a dozen places >>> in the function, you have many const variables that do one thing, with >>> one name, and you always know exactly what they are. >> >> I'm not fond of 'const'. We have a lot of legacy code where the >> programmers used it inappropriately so you wind up casting it away. I >> think they saw it in one declaration and decided it was always needed. >> Used correctly it's valuable > > Is it not better just to say that you are not fond of incorrect and > badly written code? If you have code written by people who don't know > how to use "const" properly, you should not let that stop you using it > when it is useful. const requires a modicum of generic programming to use in a satisfactory manner in all circumstances. The problem is that functions with const-qualified pointer arguments accept qualified and unqualified pointers. If they return a pointer into the same object, if they make it const-qualified, it's inconvenient. If they return unqualified, an unsafe cast is required inside the function. The C++ versions of certain C library headers fix this. You can have code like this: const char *ptr = strchr(const_str, 'a'); as well as char *ptr = strchr(non_const_str, 'a'); thanks to there being two C++ overloads for the function. (I'm guessing that the C11 _Generic thing could be used for this, to create a strchr-like macro that has cases for const and non-const.) -- 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-28 11:00 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <th12f4$b2d9$1@dont-email.me> |
| In reply to | #167886 |
On 28/09/2022 02:26, Kaz Kylheku wrote: > ["Followup-To:" header set to comp.lang.c.] (Please don't set follow-ups that exclude groups that are clearly relevant and part of the active thread - it just breaks up conversations.) > On 2022-09-27, David Brown <david.brown@hesbynett.no> wrote: >> On 27/09/2022 16:11, rbowman wrote: <snip> >>> I'm not fond of 'const'. We have a lot of legacy code where the >>> programmers used it inappropriately so you wind up casting it away. I >>> think they saw it in one declaration and decided it was always needed. >>> Used correctly it's valuable >> >> Is it not better just to say that you are not fond of incorrect and >> badly written code? If you have code written by people who don't know >> how to use "const" properly, you should not let that stop you using it >> when it is useful. > > const requires a modicum of generic programming to use in a satisfactory > manner in all circumstances. The problem is that functions with > const-qualified pointer arguments accept qualified and unqualified > pointers. > > If they return a pointer into the same object, if they make it > const-qualified, it's inconvenient. If they return unqualified, > an unsafe cast is required inside the function. Yes, being "const consistent" can sometimes be awkward. That does not mean avoiding "const" is a good idea - it just means "const" is not quite as simple as one might like. > > The C++ versions of certain C library headers fix this. You can > have code like this: > > const char *ptr = strchr(const_str, 'a'); > > as well as > > char *ptr = strchr(non_const_str, 'a'); > > thanks to there being two C++ overloads for the function. Yes. > > (I'm guessing that the C11 _Generic thing could be used for this, > to create a strchr-like macro that has cases for const > and non-const.) > Yes, _Generic certainly could handle that.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-28 13:33 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87pmffu19g.fsf@bsb.me.uk> |
| In reply to | #167891 |
David Brown <david.brown@hesbynett.no> writes: > On 28/09/2022 02:26, Kaz Kylheku wrote: <cut> >> The C++ versions of certain C library headers fix this. You can >> have code like this: >> const char *ptr = strchr(const_str, 'a'); >> as well as >> char *ptr = strchr(non_const_str, 'a'); >> thanks to there being two C++ overloads for the function. > > Yes. > >> (I'm guessing that the C11 _Generic thing could be used for this, >> to create a strchr-like macro that has cases for const >> and non-const.) > > Yes, _Generic certainly could handle that. And now C23 proposes type-generic versions of strchr etc. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-09-25 19:31 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgq39g$2pt$1@gioia.aioe.org> |
| In reply to | #167816 |
On 9/23/2022 9:50 AM, Juha Nieminen wrote: > In comp.lang.c++ Kaz Kylheku <864-117-4973@kylheku.com> wrote: >> ["Followup-To:" header set to comp.lang.c.] >> On 2022-09-21, Lynn McGuire <lynnmcguire5@gmail.com> wrote: >>> ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? >>> https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/ >>> >>> ??????It???s time to halt starting any new projects in C/C++ and use Rust for >>> those scenarios where a non-GC language is required. >> >> Those scenarios are almost never, though. >> >> The niche is small, and nothing needs replacing in it. > > 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.) Non-GC is definitely not for embedded programming only. I have seen a pretty large project for digital imaging workstations fail because of the non deterministic nature of GC.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-26 04:53 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <20220925214731.135@kylheku.com> |
| In reply to | #167842 |
On 2022-09-25, Manfred <noname@add.invalid> wrote: > Non-GC is definitely not for embedded programming only. > I have seen a pretty large project for digital imaging workstations fail > because of the non deterministic nature of GC. And are you sure that you didn't see a large project fail for various reasons, whereby some people tried to shift the blame to garbage collection? Today someone will pull it off ... in the browser. (How many decades before the web was this?) -- 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-26 08:55 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgric9$3mc4q$1@dont-email.me> |
| In reply to | #167843 |
On 26/09/2022 06:53, Kaz Kylheku wrote: > On 2022-09-25, Manfred <noname@add.invalid> wrote: >> Non-GC is definitely not for embedded programming only. >> I have seen a pretty large project for digital imaging workstations fail >> because of the non deterministic nature of GC. > > And are you sure that you didn't see a large project fail for various > reasons, whereby some people tried to shift the blame to garbage > collection? > > Today someone will pull it off ... in the browser. > > (How many decades before the web was this?) > In high reliability small embedded systems, garbage collection is generally a very bad idea because it requires more space and is non-deterministic in time and space. (Indeed you usually try to work without any kind of dynamic memory allocation at all.) Such systems don't have swap memory, or paging systems. There is no option for dealing with "out of memory" conditions. The code runs as expected 100% of the time, and you can justify that from the code source and testing, or it is useless. Your car brake system can't take a 200 ms pause to do a garbage collection sweep. Not all systems (even embedded systems) have to be high reliability, of course. But there are also many other kinds of programming where determinism is important and the kind of variability you can get from asynchronous garbage collection is not acceptable. Game programming is a fine example. On the other hand, garbage collection can make some kinds of code faster, by leaving the clearing up until there is a natural down-time in the program, or running it in separate threads to avoid messing with the main work of the program. (The big risk there is trashing your caches.) I suspect that if a program is actually /failing/ due to garbage collection, rather than just having glitches, it is because someone is putting too much in the clean-up code or destructors. It's fine to use if for recycling memory, but if you use it for other acquired resources such as file handles, GUI handles, locks, etc., then things can go unexpectedly wrong - usually not in testing, but after delivery to the customer.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2022-10-01 16:07 -0500 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <thaa6p$1dt05$2@dont-email.me> |
| In reply to | #167849 |
On 9/26/2022 1:55 AM, David Brown wrote:
> On 26/09/2022 06:53, Kaz Kylheku wrote:
>> On 2022-09-25, Manfred <noname@add.invalid> wrote:
>>> Non-GC is definitely not for embedded programming only.
>>> I have seen a pretty large project for digital imaging workstations fail
>>> because of the non deterministic nature of GC.
>>
>> And are you sure that you didn't see a large project fail for various
>> reasons, whereby some people tried to shift the blame to garbage
>> collection?
>>
>> Today someone will pull it off ... in the browser.
>>
>> (How many decades before the web was this?)
>>
>
> In high reliability small embedded systems, garbage collection is
> generally a very bad idea because it requires more space and is
> non-deterministic in time and space. (Indeed you usually try to work
> without any kind of dynamic memory allocation at all.) Such systems
> don't have swap memory, or paging systems. There is no option for
> dealing with "out of memory" conditions. The code runs as expected 100%
> of the time, and you can justify that from the code source and testing,
> or it is useless. Your car brake system can't take a 200 ms pause to do
> a garbage collection sweep.
>
> Not all systems (even embedded systems) have to be high reliability, of
> course. But there are also many other kinds of programming where
> determinism is important and the kind of variability you can get from
> asynchronous garbage collection is not acceptable. Game programming is
> a fine example.
>
Generally agreed.
My first real attempt at a 3D engine had initially used a conservative
mark/sweep collector, and the results were "not particularly good"
(wasted lots of memory, and would then randomly stall when the GC did
its thing). I eventually ended up mostly defeating the GC and using it
more like "good ol' malloc".
My following projects generally avoided GC.
Though, admittedly, I have more recently started picking up the use of
"zone" allocators. These can allow some of the features of GC while also
avoiding some of their drawbacks.
The Doom engine had also used a zone allocator pretty effectively (most
of the engine was based around a "Z_Malloc" allocator that implemented
this), and Quake 1/2 had also used them (albeit to a much narrower
extent, instead moving most of the bulk allocation to a stack-like
"Hunk" allocator).
Major differences between a GC and zone:
GC needs a graph tracing and marking step, zone does not;
GC may happen whenever the GC decides, zone is explicit.
If not used correctly, a zone allocator can totally ruin a program, such
as if one frees data before one is done with it, or organizes stuff such
there are a lot of dangling pointers.
The Doom engine had a mechanism for this later case: a per object "user"
pointer, which if not null when the object is freed, it will interpret
the pointer as a double pointer which is then set to NULL.
Can also note that it seemingly fell into disuse or was dropped from
subsequent engines, implying it was kind of a gimmick.
In my BGBCC compiler, had also partly moved some stuff over to a zone
allocator, but had also not bothered with the user-pointer mechanism.
Generalizing the idea further, had ended up moving away from the "free
everything where ztag>=zref" to "free everything where
((ztag&zmask)==zref)" which allows freeing things in terms of specific
values or ranges, though requires the range of things to be freed to be
power-of-2.
Though, this could be a hint for why Quake and friends mostly went over
to its "Hunk" system: in most cases where Doom's original use was
sufficient, one could get basically the same effect via a big stack-like
allocator (and in many other cases, the Z_Malloc/Z_Free was basically
just being used like a normal malloc/free).
Well, and also with a "hunk", allocation is cheap, bulk free is fast,
and fragmentation issues are basically non-existent. Want to bulk free
stuff? Save the current hunk pointer, and restore it later to free
everything past this point.
However, one big downside is that one is on a thin edge between wasting
memory (by having the hunk bigger than needed), or not having enough.
However, as a "general purpose" construct, something like "the hunk" is
not so easily generalized. And, while it works well in Quake and
similar, this approach would be basically unusable for something like a
Minecraft clone.
Then again, Quake had some other limitations, such the inability to
spawn "new" types of entities once the map had already started, since
then the data in the hunk would no longer be in the correct order. IIRC,
Quake 2 and 3 had addressed this issue by moving over to multiple hunks
(say, with a "main hunk" for the map and similar, and another smaller
one for things like "precached" models and sound-effects).
Granted, could Quake 2 and 3 have worked had they malloc'ed all of the
alias models and sound effects instead? Probably.
I am less sure what happened in Doom 3, since it suddenly expanded to
nearly 1M lines and also switched from C to C++, my motivation to really
look too much into how its memory management worked was kinda reduced.
> On the other hand, garbage collection can make some kinds of code
> faster, by leaving the clearing up until there is a natural down-time in
> the program, or running it in separate threads to avoid messing with the
> main work of the program. (The big risk there is trashing your caches.)
>
Potentially.
With a zone allocator, one can also add a periodic zone-free for the
inner scratchpad zones into the outer loop, which then runs on a timer.
Any working data which is left in this inner working zone, is discarded
when the zone is freed.
In some of my use cases (such as in BGBCC), there is a "walk this graph
of nodes and reassign them do a different zone as needed" function.
Say, once one parses a program, one can reassign the AST to a "module
scope" zone, and clear up whatever remains (and intermediate working
nodes, etc).
For languages that need multiple toplevel passes (such as my BGBScript2
language), the ASTs can be reassigned to "program global".
Partly, the latter is because the front-end is organized like:
Parse every module (in order):
If C or C++ or similar, compile to IR bytecode;
If BS2 (or the faked Java or C# modes), add to a delayed queue.
For everything in the delayed queue:
Do a "toplevel only" compile step;
This stage mostly builds packages/namespaces and similar.
For everything in the delayed queue:
Compile it to bytecode.
If needed, invoke the backend to do its thing.
The output of the frontend is generally a big blob of linear stack-based
bytecode (all the metadata is also encoded via the linear bytecode),
with the "decoding" stage effectively working like a special purpose
interpreter which produces 3AC as output.
Had on/off considered moving to a RIFF based packaging instead of linear
bytecode, but had admittedly not done so yet (not a strong enough
incentive to go through the effort of doing so). Even if doing a big
blob of linear bytecode (like this was PostScript or something) is a
little, errm...
Note that it is possible to fairly directly interface between C and BS2
in BGBCC.
C:
int bar(int z);
int foo(int x, int y)
{ return(x+y); }
BS2:
native int foo(int x, int y);
native int bar(int z)
{ return(z*z); }
Where, the compiler interprets top-level declarations with 'native' as
"this should use the C ABI" (similar to 'extern "C" { ... }' in C++).
Note that, unlike Java or C#, the BS2 language does not impose much in
terms of program structure (despite it using a mostly Java-inspired syntax).
Though, one potential gotcha is that BS2 does (like C# and Java) use a
16-bit 'char' type, so if one ones 8-bit values they need to use
cchar/byte/sbyte/ubyte.
Well, and other differences, like:
int a[8][8];
Is very different from:
int[][] a=new! int[8][8];
Where:
int a[8]; //C-like, decays to int*
int[8] a; //similar, but bounds-checked and decays to int[], *1
int[] a=new! int[8]; //dynamically allocated (automatic lifetime, *1)
int[] a=new int[8]; //dynamically allocated (global lifetime, *2)
*1: These two cases are "mostly equivalent" in terms of semantics,
though the former is "less awkward" and more likely to be handled
efficiently.
*2: BS2 requires 'delete', else the array will be leaked.
Note that, unlike C, 'int[]' and 'int*' represent different concepts,
where 'int*' is a bare pointer (like C), and 'int[]' will be a tagged
type that also does bounds-checks and dynamic type-conversion checks
(whereas pointer casts may be done freely, and otherwise behave mostly
like in C). Unlike C#, "unsafe" blocks aren't really a thing (the
compiler can figure this part out easily enough on its own).
There was a consideration for:
int[] a=new(ztag) int[8];
Which would then assign the array to a given zone.
And, the potential gotcha if a person tries using BS2 and expecting
something like C# or Java, in that BS2 does not use automatic garbage
collection.
Generally, it exists more alongside C in my case (semi-competes with C,
but I am still mostly using C in my ISA project). I don't really use C++
much though, and BGBCC's C++ support is too limited to really be all
that useful (though, did recently get partial support for C++ templates).
In BGBCC's case, all of these languages use the same underlying compiler
machinery, mostly enabling/disabling different parts of the parser and
similar depending on which language it is compiling.
And, for the codebase's origins originally as an interpreter for a
terrible JavaScript knock-off, it hasn't done too horribly...
In some ways though still more like a JS interpreter hacked to function
as a C compiler, than a "proper" C compiler though.
It has its funkiness; doing "static libraries" by loading in big blobs
of stack-oriented bytecode rather than linking in object files, ... But,
alas.
> I suspect that if a program is actually /failing/ due to garbage
> collection, rather than just having glitches, it is because someone is
> putting too much in the clean-up code or destructors. It's fine to use
> if for recycling memory, but if you use it for other acquired resources
> such as file handles, GUI handles, locks, etc., then things can go
> unexpectedly wrong - usually not in testing, but after delivery to the
> customer.
>
Apparently this is an annoyingly common practice.
[toc] | [prev] | [next] | [standalone]
| From | Opus <ifonly@youknew.org> |
|---|---|
| Date | 2022-09-23 18:32 +0200 |
| Message-ID | <tgkn2c$1ldk$1@gioia.aioe.org> |
| In reply to | #167776 |
Le 21/09/2022 à 21:04, Lynn McGuire a écrit : > “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” > https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/ > > ““It’s time to halt starting any new projects in C/C++ and use Rust for > those scenarios where a non-GC language is required. For the sake of > security and reliability, the industry should declare those languages as > deprecated,” he said on Twitter, expressing a personal opinion rather > than a fresh Microsoft policy.” > > Wow ! Bold. It's not bold. It's just stupid.
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@gmail.com> |
|---|---|
| Date | 2022-09-26 02:08 -0400 |
| Message-ID | <tgrfk4$3m0g3$4@dont-email.me> |
| In reply to | #167776 |
[Multipart message — attachments visible in raw view] — view raw
On 9/21/22 15:04, Lynn McGuire wrote: > “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” > https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/ > > ““It’s time to halt starting any new projects in C/C++ and use Rust for > those scenarios where a non-GC language is required. For the sake of > security and reliability, the industry should declare those languages as > deprecated,” he said on Twitter, expressing a personal opinion rather > than a fresh Microsoft policy.” > > Wow ! Bold. > > Lynn > oh goodness me not more rust bullshit -- /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr. bluemanedhawk.github.io I think my Usenet provider stores their passwords in plain text. If i'm acting suspiciously, chances are that that backfired on them.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web