Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86221 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2022-09-09 12:49 -0500 |
| Last post | 2022-09-22 19:21 +0000 |
| Articles | 20 on this page of 92 — 19 participants |
Back to article view | Back to comp.lang.c++
"Richard Stallman Announces C Reference" Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-09 12:49 -0500
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-09 19:03 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-10 18:16 +0200
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-10 17:04 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 08:29 +0000
Re: "Richard Stallman Announces C Reference" Manfred <noname@add.invalid> - 2022-09-24 16:24 +0200
C++ is for real, C is just a toy (Was: "Richard Stallman Announces C Reference") gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-24 15:54 +0000
Re: C++ is for real, C is just a toy (Was: "Richard Stallman Announces C Reference") Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 18:07 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 08:29 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 11:16 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 09:44 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 13:42 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 15:44 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 17:55 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 16:17 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 18:22 +0200
Re: "Richard Stallman Announces C Reference" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-11 12:41 -0700
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 06:10 +0200
Re: "Richard Stallman Announces C Reference" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-12 00:27 -0700
Re: "Richard Stallman Announces C Reference" Bo Persson <bo@bo-persson.se> - 2022-09-12 09:18 +0200
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 09:42 +0200
Re: "Richard Stallman Announces C Reference" Bo Persson <bo@bo-persson.se> - 2022-09-12 12:05 +0200
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 12:12 +0200
Re: "Richard Stallman Announces C Reference" Manfred <noname@add.invalid> - 2022-09-24 16:31 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-12 15:58 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 18:48 +0200
Re: "Richard Stallman Announces C Reference" Bo Persson <bo@bo-persson.se> - 2022-09-12 20:32 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-13 13:27 +0000
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-13 22:33 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-14 06:04 +0000
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-14 10:38 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-14 12:21 +0000
Re: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-15 12:15 -0700
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-16 06:02 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-16 10:37 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-16 11:05 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-16 13:18 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-16 16:00 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-16 15:16 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-18 12:13 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 05:45 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-19 08:33 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 10:41 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-19 13:48 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-19 15:22 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-16 13:10 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 05:51 +0000
Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-19 12:27 -0700
Re: "Richard Stallman Announces C Reference" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-16 11:19 -0700
Re: "Richard Stallman Announces C Reference" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 06:56 -0700
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-16 14:29 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-16 17:04 +0200
Re: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-16 08:24 -0700
Re: "Richard Stallman Announces C Reference" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 09:00 -0700
Re: "Richard Stallman Announces C Reference" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-09-15 00:54 +0100
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-15 05:31 +0000
Re: "Richard Stallman Announces C Reference" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-09-15 10:19 +0100
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 12:41 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-14 09:16 +0200
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-14 10:29 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-14 15:55 +0200
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-16 20:16 +0000
Re: "Richard Stallman Announces C Reference" Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-16 16:55 -0500
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-16 22:21 +0000
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-17 14:52 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 06:06 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-18 12:34 +0200
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-18 12:22 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 06:11 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-19 10:14 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-14 12:12 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-14 15:58 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-13 06:47 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-13 13:29 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-14 05:56 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-14 09:37 +0000
boost::intrusive. Was: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-11 09:51 -0700
Re: boost::intrusive. Was: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 18:55 +0200
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-11 16:26 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 18:35 +0200
Re: "Richard Stallman Announces C Reference" Opus <ifonly@youknew.org> - 2022-09-12 19:22 +0200
Re: "Richard Stallman Announces C Reference" legalize+jeeves@mail.xmission.com (Richard) - 2022-09-22 19:24 +0000
Re: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-10 12:56 -0700
Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-10 15:53 -0700
Re: "Richard Stallman Announces C Reference" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-09-11 07:07 +0200
Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-11 16:17 -0700
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-11 13:50 +0200
Re: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-11 05:53 -0700
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-12 05:47 +0000
Re: "Richard Stallman Announces C Reference" Manu Raju <MR@invalid.invalid> - 2022-09-11 00:01 +0100
Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-10 16:26 -0700
Re: "Richard Stallman Announces C Reference" legalize+jeeves@mail.xmission.com (Richard) - 2022-09-22 19:21 +0000
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-19 05:45 +0000 |
| Message-ID | <tg8vls$o5a$1@gioia.aioe.org> |
| In reply to | #86400 |
David Brown <david.brown@hesbynett.no> wrote: > People who can't distinguish between serious, professional work (or > indeed serious amateur work) and overgrown teenager attitudes are a bane > to society. Documents like that guide are not light-hearted or > entertaining in a workplace - they are an embarrassment. It's fine to > post that kind of humour as a joke, but not as a requirement for real work. I have seriously entertained the idea of contacting the people maintaining the kernel website and offering to reword that page to use a more neutral and professional language (just the exaplantory text, not the code examples themselves). However, I don't think it's worth the effort to even contact them because I'm somewhat certain of what their answer will be. Something along the lines of "the page is fine as it is, there's no need to change it." And I wouldn't be surprised if there was some slight mockery in the response. (And that's assuming I would get any response at all.)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-19 08:33 +0000 |
| Message-ID | <tg99g0$qbp$1@gioia.aioe.org> |
| In reply to | #86400 |
On Sun, 18 Sep 2022 12:13:51 +0200 David Brown <david.brown@hesbynett.no> wrote: >On 16/09/2022 17:16, Muttley@dastardlyhq.com wrote: >> Both you and Juha are humourless bores and in your case one who takes himself > >> far too seriously. People who cling on to professionalism as some kind of >> badge are usually making up for a lack of actual skills. >> > >People who can't distinguish between serious, professional work (or >indeed serious amateur work) and overgrown teenager attitudes are a bane >to society. Documents like that guide are not light-hearted or >entertaining in a workplace - they are an embarrassment. It's fine to >post that kind of humour as a joke, but not as a requirement for real work. Like I said, you're a humourless bore, you didn't need to prove it yet again. If you're a manager god help your team, they must dread any meetings they have to suffer with you.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-19 10:41 +0000 |
| Message-ID | <tg9h05$7ep$1@gioia.aioe.org> |
| In reply to | #86416 |
Muttley@dastardlyhq.com wrote: > Like I said, you're a humourless bore, you didn't need to prove it yet again. > If you're a manager god help your team, they must dread any meetings they > have to suffer with you. You do understand that's not an argument against the notion that official kernel documentation should be more professional in tone and style?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-19 13:48 +0200 |
| Message-ID | <tg9kue$12gsa$1@dont-email.me> |
| In reply to | #86421 |
On 19/09/2022 12:41, Juha Nieminen wrote: > Muttley@dastardlyhq.com wrote: >> Like I said, you're a humourless bore, you didn't need to prove it yet again. >> If you're a manager god help your team, they must dread any meetings they >> have to suffer with you. > > You do understand that's not an argument against the notion that official > kernel documentation should be more professional in tone and style? I think you are overestimating him by questioning if he understands anything at all. And we can be very confident that even if he has actually learned anything from the information he has been given, he will not admit it.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-19 15:22 +0000 |
| Message-ID | <tga1f2$coc$1@gioia.aioe.org> |
| In reply to | #86422 |
On Mon, 19 Sep 2022 13:48:29 +0200 David Brown <david.brown@hesbynett.no> wrote: >On 19/09/2022 12:41, Juha Nieminen wrote: >> Muttley@dastardlyhq.com wrote: >>> Like I said, you're a humourless bore, you didn't need to prove it yet >again. >>> If you're a manager god help your team, they must dread any meetings they >>> have to suffer with you. >> >> You do understand that's not an argument against the notion that official >> kernel documentation should be more professional in tone and style? > >I think you are overestimating him by questioning if he understands >anything at all. And we can be very confident that even if he has Humourless AND arrogant. >actually learned anything from the information he has been given, he >will not admit it. Why would I change my opinion? The kernel is not a company product, its OSS and the tone can be whatever Linus wants. If you don't like it thats your problem, not his. I'm sure the Windows documentation is very professional. Shame about the OS.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-16 13:10 +0200 |
| Message-ID | <tg1lia$3o0kl$1@dont-email.me> |
| In reply to | #86346 |
On 16/09/2022 12:37, Muttley@dastardlyhq.com wrote: > On Fri, 16 Sep 2022 06:02:12 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >> Michael S <already5chosen@yahoo.com> wrote: >>>> Just read the cringe language used in the *official* Linux kernel coding >>>> style guideline page: >>>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html >>>> >>> >>> I like the language of this text. >>> Style itself - less so; agree or accept with 80%, but not with another 20%. >>> It seems, what you consider "professional language" I'd consider boring >>> and bureaucratic. Or, may be, not. In order to know for sure you have to >>> give me an example of what you consider well-written style guide. >> >> An official documentation intended for use by companies and individual >> people from all around the world, both hobbyists and professionals, >>from a wide variety of fields of industry, from a wide variety of >> backgrounds, countries, cultures and customs, *should* be as professional >> and neutral as possible. It *should* be "boring and bureaucratic". > > Bollocks. A lot of the people writing linux code are hobbiests and if you > want to attract those sorts of people a light hearted approach is a good > approach. The LAST thing you want is dull, tedious documentation that drones > on to the point where people just stop reading it. > It is possible to be light-hearted while remaining professional. It is /decades/ since the core of Linux development was done by hobby programmers. The great majority of the work on the kernel, excluding support for more obscure hardware, is done by people who are paid to write the code. It is important for the project that "small" programmers don't feel alienated, or that it is too bureaucratic, but it is also important to remember it is a professional project, run by professionals, and used by professionals. Fortunately, the style guide here is something only the actual technical coders will look at - and even then, most contributors will copy the existing code style rather than looking at the guide. They are much more likely to laugh at it than "corporate leader" types who might wonder if this is the kind of project they can bet their company's future on. It's worth noting that Linus Torvalds has gradually developed a more mature, diplomatic and professional style of leadership and of communication with the outside world, while still maintaining a unique development environment. I would expect that sooner or later, this guide will also get cleaned up (as well as being modernised to include C11, now that it is the standard for the kernel). >> When you write things like >> >> "I'd suggest printing out a copy of the GNU coding standards, and NOT >> read it. Burn them, it's a great symbolic gesture" >> >> or >> >> "Encoding the type of a function into the name (so-called Hungarian >> notation) is brain damaged [...] No wonder MicroSoft makes buggy programs" >> >> the only thing you are doing is alienating people. (And those are just > > You might be alienating some aspies with zero social skills but for most > people it'll elicit a chuckle and keep them reading. > >> two examples of many.) Also, how many big respectable international >> corporations would put this kind of language in their official >> documentation for the wider public? > > You're confusing business products with an open source project. One you pay > for, one you don't. > Much of the Linux world is professional and paid-for. When you buy a server from IBM with Red Hat Linux, you pay a /lot/. Linux is not driven by zero-cost usage of software written by people for free. Open source is not primarily about zero cost (though the fact that you can use it for zero cost hugely increases its popularity) - it is about an open development model, and sharing the cost and sharing the results. >> The Linux kernel is not a small hobby project for some small group of >> nerds anymore. It hasn't been for like a couple decades now. And it >> isn't even intended to be. The very coding style document itself > > Except plenty of people who work on the kernel ARE hobbyists. > They outnumber the professionals in terms of numbers of contributors - but the professionals outnumber the hobbyists in terms of the work done and code committed. And if you look at in terms of the key parts of the kernel, used by everyone, the difference is vastly greater. The style of this coding guide was fine when it was written, but the Linux project has moved on and changed enormously since then. I doubt if it has caused much real negative reaction in practice, but it is certainly due for an update.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-19 05:51 +0000 |
| Message-ID | <tg9005$rbh$1@gioia.aioe.org> |
| In reply to | #86348 |
David Brown <david.brown@hesbynett.no> wrote: > (as well as being modernised to include > C11, now that it is the standard for the kernel). Speaking of which, I find it a bit surprising that there seems to be no official rule, directive or even recommendation on which version of C can/should be used in kernel code. Or at least I can't find this anywhere (I have tried). The only thing I have found is some directive/rule that the kernel has to compile with gcc 3.3, but AFAIK even that rule is old and obsolete (and the current kernel might not compile with that version of gcc anymore.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-19 12:27 -0700 |
| Message-ID | <87o7vbf9lc.fsf@nosuchdomain.example.com> |
| In reply to | #86410 |
Juha Nieminen <nospam@thanks.invalid> writes:
> David Brown <david.brown@hesbynett.no> wrote:
>> (as well as being modernised to include
>> C11, now that it is the standard for the kernel).
>
> Speaking of which, I find it a bit surprising that there seems to be no
> official rule, directive or even recommendation on which version of C
> can/should be used in kernel code. Or at least I can't find this anywhere
> (I have tried).
>
> The only thing I have found is some directive/rule that the kernel has
> to compile with gcc 3.3, but AFAIK even that rule is old and obsolete
> (and the current kernel might not compile with that version of gcc
> anymore.)
https://www.kernel.org/doc/html/latest/process/programming-language.html
The kernel is written in the C programming language [c-language].
More precisely, the kernel is typically compiled with gcc [gcc]
under -std=gnu11 [gcc-c-dialect-options]: the GNU dialect of
ISO C11. clang [clang] is also supported, see docs on Building
Linux with Clang/LLVM.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-09-16 11:19 -0700 |
| Message-ID | <tg2ena$3td42$1@dont-email.me> |
| In reply to | #86346 |
On 9/16/2022 3:37 AM, Muttley@dastardlyhq.com wrote: > On Fri, 16 Sep 2022 06:02:12 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >> Michael S <already5chosen@yahoo.com> wrote: >>>> Just read the cringe language used in the *official* Linux kernel coding >>>> style guideline page: >>>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html >>>> >>> >>> I like the language of this text. >>> Style itself - less so; agree or accept with 80%, but not with another 20%. >>> It seems, what you consider "professional language" I'd consider boring >>> and bureaucratic. Or, may be, not. In order to know for sure you have to >>> give me an example of what you consider well-written style guide. >> >> An official documentation intended for use by companies and individual >> people from all around the world, both hobbyists and professionals, >>from a wide variety of fields of industry, from a wide variety of >> backgrounds, countries, cultures and customs, *should* be as professional >> and neutral as possible. It *should* be "boring and bureaucratic". > > Bollocks. A lot of the people writing linux code are hobbiests and if you > want to attract those sorts of people a light hearted approach is a good > approach. The LAST thing you want is dull, tedious documentation that drones > on to the point where people just stop reading it. > >> When you write things like >> >> "I'd suggest printing out a copy of the GNU coding standards, and NOT >> read it. Burn them, it's a great symbolic gesture" >> >> or >> >> "Encoding the type of a function into the name (so-called Hungarian >> notation) is brain damaged [...] No wonder MicroSoft makes buggy programs" [...] The WinNt 4 kernel, yes its in C... ;^) https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos How many bugs can you find? There has to be some in them there hills....? ;)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-16 06:56 -0700 |
| Message-ID | <86mtazl8y2.fsf@linuxsc.com> |
| In reply to | #86339 |
Michael S <already5chosen@yahoo.com> writes: > On Wednesday, September 14, 2022, Juha Nieminen wrote: > >> Andreas Kempe <ke...@lysator.liu.se> wrote: >> >>> This might be part of the reasoning, but I think the main reason >>> is that Linus is biased against C++ on the grounds of simply not >>> liking the language. >>> >>> Here's a quote I managed to find again from when they were >>> discussing Rust support in the kernel: >> >> I still find it astonishing how much unprofessionalism there is >> in the Linux development scene, even at the highest levels. >> >> Just read the cringe language used in the *official* Linux kernel >> coding style guideline page: >> https://www.kernel.org/doc/html/v4.10/process/coding-style.html >> >> (I'm not talking about the coding style itself, but the >> explanatory text.) > > I like the language of this text. > Style itself - less so; agree or accept with 80%, but not with > another 20%. Do you mind saying which parts you don't agree with?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-16 14:29 +0000 |
| Message-ID | <3L%UK.429954$iiS8.216193@fx17.iad> |
| In reply to | #86351 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >Michael S <already5chosen@yahoo.com> writes: > >> On Wednesday, September 14, 2022, Juha Nieminen wrote: >> >>> Andreas Kempe <ke...@lysator.liu.se> wrote: >>> >>>> This might be part of the reasoning, but I think the main reason >>>> is that Linus is biased against C++ on the grounds of simply not >>>> liking the language. >>>> >>>> Here's a quote I managed to find again from when they were >>>> discussing Rust support in the kernel: >>> >>> I still find it astonishing how much unprofessionalism there is >>> in the Linux development scene, even at the highest levels. >>> >>> Just read the cringe language used in the *official* Linux kernel >>> coding style guideline page: >>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html >>> >>> (I'm not talking about the coding style itself, but the >>> explanatory text.) >> >> I like the language of this text. >> Style itself - less so; agree or accept with 80%, but not with >> another 20%. > >Do you mind saying which parts you don't agree with? I think one should always use braces for if/while/do/for regardless of the number of statements in the construct. Perhaps this comes from my punched card days, when adding a statement to the if would have required repunching the if statement card if it hadn't used braces from the beginning, but it also does help avoid future problems during maintenance or enhancement activities. And I disagree with the 8 column hard tabs. As tabs were derived from mechanical typewriters, where the tabs were always variable, their rationale for 8 column tabs isn't compelling. I disagree with their opinion on typedefs (for C; for C++ since you don't need the struct/class keywords, the class/struct name doesn't need a typedef). I've been working on Linux kernel code off-and-on since 1997, including contributing an in-kernel debugger (kdb) in 1998/9 while at SGI.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-16 17:04 +0200 |
| Message-ID | <tg23a4$3r7qg$1@dont-email.me> |
| In reply to | #86354 |
On 16/09/2022 16:29, Scott Lurndal wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Wednesday, September 14, 2022, Juha Nieminen wrote:
>>>
>>>> Andreas Kempe <ke...@lysator.liu.se> wrote:
>>>>
>>>>> This might be part of the reasoning, but I think the main reason
>>>>> is that Linus is biased against C++ on the grounds of simply not
>>>>> liking the language.
>>>>>
>>>>> Here's a quote I managed to find again from when they were
>>>>> discussing Rust support in the kernel:
>>>>
>>>> I still find it astonishing how much unprofessionalism there is
>>>> in the Linux development scene, even at the highest levels.
>>>>
>>>> Just read the cringe language used in the *official* Linux kernel
>>>> coding style guideline page:
>>>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>>>>
>>>> (I'm not talking about the coding style itself, but the
>>>> explanatory text.)
>>>
>>> I like the language of this text.
>>> Style itself - less so; agree or accept with 80%, but not with
>>> another 20%.
>>
>> Do you mind saying which parts you don't agree with?
>
> I think one should always use braces for if/while/do/for
> regardless of the number of statements in the construct.
>
I agree.
> Perhaps this comes from my punched card days, when adding
> a statement to the if would have required repunching the if
> statement card if it hadn't used braces from the beginning,
> but it also does help avoid future problems during maintenance
> or enhancement activities.
My reasoning is that braces reduces the risk for errors - both while
writing code, and when reading it. As well as the well-known issue of
multi-statement macros (which should have a "do {...} while (0)" wrapper
anyway), it improves consistency. An open brace means the next line has
an extra indent, unindents have a close brace - and vice versa. This
makes it much easier to see the nesting and scope.
In addition, the kernel coding style rule requires:
if (condition)
do_this();
else
do_that();
and
if (condition) {
do_this();
do_more();
} else {
do_that();
}
This means adding the line "do_more()" changes another three lines that
are not semantically affected, simply to suit the style. That's bad
practice, especially for a project where revision control and changesets
are so critical - you do not want cosmetic changes on unrelated code.
I am okay with simple conditionals and a simple statement on the same
line without braces, as long as things are very clear :
if (!p_data) return; // No data, so nothing to do
if (x > max_value) x = max_value;
>
> And I disagree with the 8 column hard tabs. As tabs were
> derived from mechanical typewriters, where the tabs were
> always variable, their rationale for 8 column tabs isn't compelling.
>
Agreed. I usually use 4 spaces for a tab, although it is really just a
personal preference. I agree with the guide that many indentation
levels is a sign that your function is probably due for a refactoring,
but you don't have to have such big tabs to see that.
> I disagree with their opinion on typedefs (for C; for C++ since
> you don't need the struct/class keywords, the class/struct name
> doesn't need a typedef).
I don't agree with the guide on typedefs either, though that does not
necessarily mean we disagree in the same way about the same details!
Some of the factors in any coding style guide are going to be dependent
on characteristics of the project - rules that suit a single-person
project will not always match with one spanning hundreds or thousands of
developers. Similarly portability, project size, target system,
language standards, and all kinds of other factors come into play.
Disagreeing about a particular style guide point does not necessarily
mean I think it is /wrong/, merely that I typically follow different rules.
>
> I've been working on Linux kernel code off-and-on since 1997, including
> contributing an in-kernel debugger (kdb) in 1998/9 while at SGI.
Quiet - don't spoil people's delusions by telling them corporations
contribute to Linux!
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-09-16 08:24 -0700 |
| Message-ID | <6b0fb44d-6dc9-4072-af6e-26b3ca5ffd7en@googlegroups.com> |
| In reply to | #86351 |
On Friday, September 16, 2022 at 4:56:23 PM UTC+3, Tim Rentsch wrote: > Michael S <already...@yahoo.com> writes: > > On Wednesday, September 14, 2022, Juha Nieminen wrote: > > > >> Andreas Kempe <ke...@lysator.liu.se> wrote: > >> > >>> This might be part of the reasoning, but I think the main reason > >>> is that Linus is biased against C++ on the grounds of simply not > >>> liking the language. > >>> > >>> Here's a quote I managed to find again from when they were > >>> discussing Rust support in the kernel: > >> > >> I still find it astonishing how much unprofessionalism there is > >> in the Linux development scene, even at the highest levels. > >> > >> Just read the cringe language used in the *official* Linux kernel > >> coding style guideline page: > >> https://www.kernel.org/doc/html/v4.10/process/coding-style.html > >> > >> (I'm not talking about the coding style itself, but the > >> explanatory text.) > > > > I like the language of this text. > > Style itself - less so; agree or accept with 80%, but not with > > another 20%. > Do you mind saying which parts you don't agree with? Yes, I do.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-16 09:00 -0700 |
| Message-ID | <86edwbl37j.fsf@linuxsc.com> |
| In reply to | #86358 |
Michael S <already5chosen@yahoo.com> writes: > On Friday, September 16, 2022 at 4:56:23 PM UTC+3, Tim Rentsch wrote: > >> Michael S <already...@yahoo.com> writes: >> >>> On Wednesday, September 14, 2022, Juha Nieminen wrote: >>> >>>> Andreas Kempe <ke...@lysator.liu.se> wrote: >>>> >>>>> This might be part of the reasoning, but I think the main reason >>>>> is that Linus is biased against C++ on the grounds of simply not >>>>> liking the language. >>>>> >>>>> Here's a quote I managed to find again from when they were >>>>> discussing Rust support in the kernel: >>>> >>>> I still find it astonishing how much unprofessionalism there is >>>> in the Linux development scene, even at the highest levels. >>>> >>>> Just read the cringe language used in the *official* Linux kernel >>>> coding style guideline page: >>>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html >>>> >>>> (I'm not talking about the coding style itself, but the >>>> explanatory text.) >>> >>> I like the language of this text. >>> Style itself - less so; agree or accept with 80%, but not with >>> another 20%. >> >> Do you mind saying which parts you don't agree with? > > Yes, I do. In that case do you mind saying which parts you agree with? Just kidding.. I respect your decision not to answer, and say thank you for responding.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2022-09-15 00:54 +0100 |
| Message-ID | <20220915005446.83ef65e1d22f1f0aa8289e58@cvine--nospam--.freeserve.co.uk> |
| In reply to | #86305 |
On Wed, 14 Sep 2022 06:04:48 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: [snip] > If a new language were to be introduced into kernel code, like C++ > (or, heaven forbid, Rust), that would mean that a huge amount of devs > would either need to learn the new language or just don't participate > (in code reviews, further development, etc), which would ostensibly > mean a significant drop in the number of expert developers. The kernel > is complex enough as it is; it would not benefit from half the > developers dropping off (and perhaps creating their own fork and > going there). Rust is entering the linux kernel on an experimental basis, after receiving approval from Torvalds. If support hasn't yet been merged into mainline (I am not sure if it has or it hasn't) it is about to be. Make of it what you will. Presumably much of the Rust standard library isn't available.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-15 05:31 +0000 |
| Message-ID | <tfudcc$1u92$1@gioia.aioe.org> |
| In reply to | #86329 |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: >> If a new language were to be introduced into kernel code, like C++ >> (or, heaven forbid, Rust), that would mean that a huge amount of devs >> would either need to learn the new language or just don't participate >> (in code reviews, further development, etc), which would ostensibly >> mean a significant drop in the number of expert developers. The kernel >> is complex enough as it is; it would not benefit from half the >> developers dropping off (and perhaps creating their own fork and >> going there). > > Rust is entering the linux kernel on an experimental basis, after > receiving approval from Torvalds. If support hasn't yet been merged > into mainline (I am not sure if it has or it hasn't) it is about to be. > Make of it what you will. Presumably much of the Rust standard library > isn't available. Let's hope that doesn't start a downspiral which starts by alienating half of the current kernel developers. Sometimes I think that Torvalds should relinquish control of his own kernel, for its own good.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2022-09-15 10:19 +0100 |
| Message-ID | <20220915101918.c4bfe699b8dd984c8df0edc7@cvine--nospam--.freeserve.co.uk> |
| In reply to | #86330 |
On Thu, 15 Sep 2022 05:31:58 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: > Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: > >> If a new language were to be introduced into kernel code, like C++ > >> (or, heaven forbid, Rust), that would mean that a huge amount of devs > >> would either need to learn the new language or just don't participate > >> (in code reviews, further development, etc), which would ostensibly > >> mean a significant drop in the number of expert developers. The kernel > >> is complex enough as it is; it would not benefit from half the > >> developers dropping off (and perhaps creating their own fork and > >> going there). > > > > Rust is entering the linux kernel on an experimental basis, after > > receiving approval from Torvalds. If support hasn't yet been merged > > into mainline (I am not sure if it has or it hasn't) it is about to be. > > Make of it what you will. Presumably much of the Rust standard library > > isn't available. > > Let's hope that doesn't start a downspiral which starts by alienating > half of the current kernel developers. > > Sometimes I think that Torvalds should relinquish control of his own > kernel, for its own good. I don't think Torvalds was the originator of this: instead he has agreed to see if it works out. Rust seems to have received sufficiently widespread approbation within the kernel community as I understand it and I don't think there is (at least at present) any requirement to use or even know the language unless you are hacking on the particular modules that use it. I should have thought the experiment was worth the effort. Memory errors are still a significant source of bugs and vulnerabilities, and the promise that, by virtue of Rust's linear/affine type system, a component that compiles is guaranteed to be memory correct as long as the unsafe subset of Rust hasn't been used is quite a strong statement.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-22 12:41 +0000 |
| Message-ID | <tghl6f$13dt$1@gioia.aioe.org> |
| In reply to | #86333 |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: > I should have thought the experiment was worth the effort. Memory > errors are still a significant source of bugs and vulnerabilities, and > the promise that, by virtue of Rust's linear/affine type system, a > component that compiles is guaranteed to be memory correct as long as > the unsafe subset of Rust hasn't been used is quite a strong statement. I happened to stumble across this, which seems to contradict that notion: https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-14 09:16 +0200 |
| Message-ID | <tfrv41$2rkif$1@dont-email.me> |
| In reply to | #86302 |
On 14/09/2022 00:33, Andreas Kempe wrote: > Den 2022-09-13 skrev Muttley@dastardlyhq.com <Muttley@dastardlyhq.com>: >> On Mon, 12 Sep 2022 20:32:21 +0200 >> Bo Persson <bo@bo-persson.se> wrote: >>> On 2022-09-12 at 17:58, Muttley@dastardlyhq.com wrote: >>>>> my_class f(x); >>>> >>>> And if that instance has virtual functions where will the VFT go and what >>>> allocates it? Ditto any non primitive types which may cause an implcit >>> cascade >>>> of allocations. >>> >>> Just don't see how we know that int y = f(x); doesn't call other >>> functions that allocate structs on the heap? Structs that contain >> >> It may well do, but you can at least look at them to see how and kernel authors >> are extremely careful about how they allocate dynamic memory. Meanwhile >> who knows if std::string s = "hello" will allocate on the heap or if it'll >> use its small reerved amount of stack. >> >> > > In my view, this is not a language problem as much as a standard > library implementation problem. As have been brought up earlier, you > don't use the normal user space libc in the kernel for C code, but > have parts of the standard library implemented in a way to make it fit > the kernel. > > To seriously bring C++ into the kernel world, one would have to do the > same. That is, pick functions from the standard library that make > sense in the kernel and implement them to work there. One such thing > could of course be an std::string without hidden heap allocations. > > I, and doubtlessly many others, have long toyed with the idea that > kernel programming, Linux or *BSD is what I'm familiar with, could be > made simpler with a language that supports object oriented programming > instead of using C structs with function pointers. The possibility of > doing RAII would also be nice. Whether that language should be C++ is > another question and I don't have a good answer. When working on an OS kernel, there are lots of things in the C standard library that you avoid, and there is no difference in regard to C++. It has a lot in common with embedded development, and that is often done in C++. With the software I write, on microcontrollers, I am quite happy to use C++, but I am careful about the features I use. Exceptions are disabled, virtual inheritance is out (virtual functions are used with caution), and there is rarely a good enough reason for anything involving dynamic memory in my code. For a large OS kernel, the precise choices of which features in the language and library to use are a bit different from mine, but the same principles apply. And you often end up writing classes and functions that are somewhat similar to the standard library solutions, but which are more suited to your particular needs. Lots of OS kernels are already written in C++ - just not ones as visible as Linux or *BSD. There are also existing template libraries that could be useful. A particularly well-known one is EASTL, started by Electronic Arts as a version of the STL (back when the containers part of the C++ standard library was called the STL) that was better suited to high-performance gaming code. I don't know if it is an ideal fit for a big OS kernel, but it would likely be better than the standard library. <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html> <https://github.com/electronicarts/EASTL>
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kempe <kempe@lysator.liu.se> |
|---|---|
| Date | 2022-09-14 10:29 +0000 |
| Message-ID | <tfsae7$iac$1@nyheter.lysator.liu.se> |
| In reply to | #86310 |
Den 2022-09-14 skrev David Brown <david.brown@hesbynett.no>: > On 14/09/2022 00:33, Andreas Kempe wrote: >> Den 2022-09-13 skrev Muttley@dastardlyhq.com <Muttley@dastardlyhq.com>: >>> On Mon, 12 Sep 2022 20:32:21 +0200 >>> Bo Persson <bo@bo-persson.se> wrote: >>>> On 2022-09-12 at 17:58, Muttley@dastardlyhq.com wrote: >>>>>> my_class f(x); >>>>> >>>>> And if that instance has virtual functions where will the VFT go and what >>>>> allocates it? Ditto any non primitive types which may cause an implcit >>>> cascade >>>>> of allocations. >>>> >>>> Just don't see how we know that int y = f(x); doesn't call other >>>> functions that allocate structs on the heap? Structs that contain >>> >>> It may well do, but you can at least look at them to see how and kernel authors >>> are extremely careful about how they allocate dynamic memory. Meanwhile >>> who knows if std::string s = "hello" will allocate on the heap or if it'll >>> use its small reerved amount of stack. >>> >>> >> >> In my view, this is not a language problem as much as a standard >> library implementation problem. As have been brought up earlier, you >> don't use the normal user space libc in the kernel for C code, but >> have parts of the standard library implemented in a way to make it fit >> the kernel. >> >> To seriously bring C++ into the kernel world, one would have to do the >> same. That is, pick functions from the standard library that make >> sense in the kernel and implement them to work there. One such thing >> could of course be an std::string without hidden heap allocations. >> >> I, and doubtlessly many others, have long toyed with the idea that >> kernel programming, Linux or *BSD is what I'm familiar with, could be >> made simpler with a language that supports object oriented programming >> instead of using C structs with function pointers. The possibility of >> doing RAII would also be nice. Whether that language should be C++ is >> another question and I don't have a good answer. > > When working on an OS kernel, there are lots of things in the C standard > library that you avoid, and there is no difference in regard to C++. It > has a lot in common with embedded development, and that is often done in > C++. With the software I write, on microcontrollers, I am quite happy > to use C++, but I am careful about the features I use. Exceptions are > disabled, virtual inheritance is out (virtual functions are used with > caution), and there is rarely a good enough reason for anything > involving dynamic memory in my code. > What size are we talking about? In a professional setting, I've only worked with embedded systems large enough to run Linux. On those systems we used C++ as the primary language, with Python being used for some things as well. Due to using a full blown Linux system we didn't really have any restrictions regarding what language features to use so that was never a problem. When working on the kernel, we of course used C. I'm curious because I've occasionally searched around for C++ standard implementations aimed at kernel programming or bare metal programming without really finding much. For C, newlib is the one I have personally used to write bare metal stuff and it worked well. > For a large OS kernel, the precise choices of which features in the > language and library to use are a bit different from mine, but the same > principles apply. And you often end up writing classes and functions > that are somewhat similar to the standard library solutions, but which > are more suited to your particular needs. Lots of OS kernels are > already written in C++ - just not ones as visible as Linux or *BSD. > > There are also existing template libraries that could be useful. A > particularly well-known one is EASTL, started by Electronic Arts as a > version of the STL (back when the containers part of the C++ standard > library was called the STL) that was better suited to high-performance > gaming code. I don't know if it is an ideal fit for a big OS kernel, > but it would likely be better than the standard library. > ><https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html> ><https://github.com/electronicarts/EASTL> > Interesting. I haven't really worked with high performance applications like games in C++, but from what I've heard and read the standard library quite often isn't enough for various reasons. I did not know that EA had made their stuff open source and it frankly surprises me, in a good way.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web