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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-14 15:55 +0200 |
| Message-ID | <tfsmhf$2vqod$1@dont-email.me> |
| In reply to | #86314 |
On 14/09/2022 12:29, Andreas Kempe wrote: > 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. Smaller than that - usually a /lot/ smaller. I tend to think of "embedded Linux systems" as primarily /Linux/ systems, rather than primarily /embedded/ systems. Some people prefer "resource constrained embedded systems" as an alternative name. Basically, I am considering systems where you have a single statically linked program. (You might have sometimes have an extra boot program, or updater, or test program - but the normal mode of operation is one program.) > 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. Sure. On embedded Linux systems, I too use Python - or whatever else suits the task at hand. > > 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. > Newlib is the most common choice, as well as its variant newlib-nano which is smaller (but more limited). I don't know of any good C++ standard library implementations targetting such systems - the aforementioned EASTL is the nearest. Generally, I think, people make their own classes as needed. So if you really need a dynamically sized array (and usually you don't - a fixed size can be better in many ways, and std::array is overhead-free), you just make one. It's not hard when it is for a particular purpose. The effort in making the standard library classes is having them robust in the face of users wanting vectors of rvalue references to pointers to member functions, and whatever else pesky users try to do. For use in a fixed program, you can make them a /lot/ simpler and fine-tune them to your needs. It's a bit more like C programming in that respect - you might have to invent your own wheels, but you can make them exactly the shape you want. >> 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. General container classes are much less used in high performance coding now than they used to be. Your key focus in programming such applications is cache usage - almost everything else (except getting the graphics card to do the work instead of the processor) is secondary.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kempe <kempe@lysator.liu.se> |
|---|---|
| Date | 2022-09-16 20:16 +0000 |
| Message-ID | <tg2lik$29qi$1@nyheter.lysator.liu.se> |
| In reply to | #86322 |
Den 2022-09-14 skrev David Brown <david.brown@hesbynett.no>: > On 14/09/2022 12:29, Andreas Kempe wrote: >> 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. > > Smaller than that - usually a /lot/ smaller. I tend to think of > "embedded Linux systems" as primarily /Linux/ systems, rather than > primarily /embedded/ systems. Some people prefer "resource constrained > embedded systems" as an alternative name. > > Basically, I am considering systems where you have a single statically > linked program. (You might have sometimes have an extra boot program, > or updater, or test program - but the normal mode of operation is one > program.) > I guess the term embedded is a bit diluted these days with how powerful SoCs have become. Working on projects for very small processors, I've only used C or assembly and my main experience is using PICs. I have toyed with the idea of using C++, but there isn't really any free C++ compilers PICs as far as I've found. Thank you for an informative reply! >[...]
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2022-09-16 16:55 -0500 |
| Message-ID | <tg2rca$3un6v$1@dont-email.me> |
| In reply to | #86368 |
On 9/16/2022 3:16 PM, Andreas Kempe wrote: > Den 2022-09-14 skrev David Brown <david.brown@hesbynett.no>: >> On 14/09/2022 12:29, Andreas Kempe wrote: >>> 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. >> >> Smaller than that - usually a /lot/ smaller. I tend to think of >> "embedded Linux systems" as primarily /Linux/ systems, rather than >> primarily /embedded/ systems. Some people prefer "resource constrained >> embedded systems" as an alternative name. >> >> Basically, I am considering systems where you have a single statically >> linked program. (You might have sometimes have an extra boot program, >> or updater, or test program - but the normal mode of operation is one >> program.) >> > > I guess the term embedded is a bit diluted these days with how > powerful SoCs have become. > > Working on projects for very small processors, I've only used C or > assembly and my main experience is using PICs. I have toyed with the > idea of using C++, but there isn't really any free C++ compilers PICs > as far as I've found. > > Thank you for an informative reply! > >> [...] What is a PIC ? Lynn
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-16 22:21 +0000 |
| Message-ID | <zF6VK.377678$6Il8.344461@fx14.iad> |
| In reply to | #86371 |
Lynn McGuire <lynnmcguire5@gmail.com> writes: >On 9/16/2022 3:16 PM, Andreas Kempe wrote: >>> [...] > >What is a PIC ? 15 seconds with google "programming a PIC" gets you here: https://en.wikipedia.org/wiki/PIC_microcontrollers
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kempe <kempe@lysator.liu.se> |
|---|---|
| Date | 2022-09-17 14:52 +0000 |
| Message-ID | <slrntibnoq.1nb3.kempe@renge.lysator.liu.se> |
| In reply to | #86371 |
Den 2022-09-16 skrev Lynn McGuire <lynnmcguire5@gmail.com>: > On 9/16/2022 3:16 PM, Andreas Kempe wrote: >> >> Working on projects for very small processors, I've only used C or >> assembly and my main experience is using PICs. I have toyed with the >> idea of using C++, but there isn't really any free C++ compilers PICs >> as far as I've found. >> >> Thank you for an informative reply! >> >>> [...] > > What is a PIC ? > A Wikipedia link has been provided, but I think it courteous to explain what I meant here on Usenet. I was referring to microcontrollers made by Microchip that range from small 8 bit RISC processors to larger 32 bit MIPS dittos. Compiling C, or C++ for that matter, for the smaller 8 bit ones is quite interesting since they don't have a stack on which to push and pop values. The stack is an automatically managed fix-depth callstack only and the chip automatically pushes and pops return addresses when calling and returning from functions. I enjoy the smaller 8 bit PICs for their small instruction set where all instructions except for branching take the same amount of time, making timing code pretty easy to write. The bad thing is that there is, to my knowledge, no good open source compiler, although the basic Microchip C compiler is free as in free beer. // Andreas Kempe
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-19 06:06 +0000 |
| Message-ID | <tg90tg$157h$1@gioia.aioe.org> |
| In reply to | #86387 |
Andreas Kempe <kempe@lysator.liu.se> wrote: > I enjoy the smaller 8 bit PICs for their small instruction set where > all instructions except for branching take the same amount of time, > making timing code pretty easy to write. The bad thing is that there > is, to my knowledge, no good open source compiler, although the basic > Microchip C compiler is free as in free beer. I suppose sdcc is *the* C compiler for 8-bit CPUs, although their webpage states that "Microchip PIC16 and PIC18 targets are unmaintained" (which I don't know if it means that you can't compile for them, or just that there might be bugs or inefficiencies.) Not that sdcc is an extraordinarily good compiler (it's quite bad at optimizing for size or speed. For example it will often load the same value from memory to a register several times for several consecutive operations because the optimizer is unable to see that the value was already loaded to that register and hasn't changed.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-18 12:34 +0200 |
| Message-ID | <tg6s8f$fs0o$1@dont-email.me> |
| In reply to | #86371 |
On 16/09/2022 23:55, Lynn McGuire wrote: > > What is a PIC ? > Ignorance is bliss - you'd have been happier if you never knew :-) Since Scott has already posted a link, I think the key thing to know is that it is one of the most brain-dead of all the brain-dead 8-bit CISC microcontroller architectures around. It makes the 8051 look smart. We are talking single register, banked ram and flash/rom access, separate memory spaces for code and data, an assembly language that reminds me of microcoding rather than assembly code, hardware return stack of limited size, very limited and highly inefficient indirect memory access instead of pointers. There have been a number of C compilers for the chips, each of which has its own range of non-standard features, extensions and limitations necessary to get usable results out of the device. The official compiler supplied (at a high cost) by the manufacturer at one time supported structs, and arrays, but not arrays of structs or structs containing arrays. On the other hand, the manufacturer never stops making devices - even when they are decades out of date, you can still buy them. That kind of long-term availability is very rare in the business. And the microcontrollers are incredibly robust. I've seen PIC microcontrollers rated for 85 °C run happily at 160 °C. Short-circuits, over-voltages, and all kinds of hardship that would kill a lesser microcontroller rarely bother PICs. And they are popular with hobby users as they are available in packages with big legs that are easy to solder at home.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-18 12:22 +0200 |
| Message-ID | <tg6rh0$fml9$1@dont-email.me> |
| In reply to | #86368 |
On 16/09/2022 22:16, Andreas Kempe wrote: > Den 2022-09-14 skrev David Brown <david.brown@hesbynett.no>: >> On 14/09/2022 12:29, Andreas Kempe wrote: >>> 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. >> >> Smaller than that - usually a /lot/ smaller. I tend to think of >> "embedded Linux systems" as primarily /Linux/ systems, rather than >> primarily /embedded/ systems. Some people prefer "resource constrained >> embedded systems" as an alternative name. >> >> Basically, I am considering systems where you have a single statically >> linked program. (You might have sometimes have an extra boot program, >> or updater, or test program - but the normal mode of operation is one >> program.) >> > > I guess the term embedded is a bit diluted these days with how > powerful SoCs have become. Yes, indeed. There have always been powerful embedded systems, with big processors running big OS's, but they used to be very much in the minority. Now you can put a Pi Zero running Linux in anything. The key distinction, I think, whether the system is running a single statically linked program as its main task (either bare bones, or with an RTOS of some kind). > > Working on projects for very small processors, I've only used C or > assembly and my main experience is using PICs. I have toyed with the > idea of using C++, but there isn't really any free C++ compilers PICs > as far as I've found. > The PICs (and by that I assume you mean the 8-bit devices, not the PIC32 chips which have MIPS cores) have always had quite limited tools - they are not well suited to C coding, never mind C++. The only 8-bit microcontroller for which C++ is a reasonable option is the AVR, for which the most common compiler is gcc. The core language is well supported, but much of the library is very limited - including language-support code for things like exceptions. > Thank you for an informative reply! > >> [...]
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-19 06:11 +0000 |
| Message-ID | <tg9174$18hb$1@gioia.aioe.org> |
| In reply to | #86401 |
David Brown <david.brown@hesbynett.no> wrote: >> I guess the term embedded is a bit diluted these days with how >> powerful SoCs have become. > > Yes, indeed. There have always been powerful embedded systems, with big > processors running big OS's, but they used to be very much in the > minority. Now you can put a Pi Zero running Linux in anything. The key > distinction, I think, whether the system is running a single statically > linked program as its main task (either bare bones, or with an RTOS of > some kind). There are still tons of devices which use processors so small that it wouldn't make any sense to have Linux running in them, just for them to blink some leds and update some LCD, or act as a watchdog. Price and power consumption (and sometimes even physical size) play important roles here.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-19 10:14 +0200 |
| Message-ID | <tg98ci$11eu3$1@dont-email.me> |
| In reply to | #86412 |
On 19/09/2022 08:11, Juha Nieminen wrote: > David Brown <david.brown@hesbynett.no> wrote: >>> I guess the term embedded is a bit diluted these days with how >>> powerful SoCs have become. >> >> Yes, indeed. There have always been powerful embedded systems, with big >> processors running big OS's, but they used to be very much in the >> minority. Now you can put a Pi Zero running Linux in anything. The key >> distinction, I think, whether the system is running a single statically >> linked program as its main task (either bare bones, or with an RTOS of >> some kind). > > There are still tons of devices which use processors so small that it > wouldn't make any sense to have Linux running in them, just for them > to blink some leds and update some LCD, or act as a watchdog. Price > and power consumption (and sometimes even physical size) play important > roles here. We use such microcontrollers all the time. Note that there are /many/ advantages of them - not just price, power and size. There are complete Linux SOMs available that are smaller and cheaper (and not much more power) than some of the microcontrollers I use, but the microcontrollers are still the better choice by a long way. In terms of counts of devices shipped, processors that are capable of running an OS like Linux are a negligible rounding error compared to microcontrollers. (Mind you, someone managed to get Linux running on an 8-bit AVR microcontroller... <http://dangerousprototypes.com/blog/2012/03/29/running-linux-on-a-8bit-avr/> )
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-14 12:12 +0000 |
| Message-ID | <tfsgg6$1oj5$1@gioia.aioe.org> |
| In reply to | #86310 |
David Brown <david.brown@hesbynett.no> wrote: > 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. Would probably not be usable without modifications because in (Linux) kernel code you can't use 'malloc()' (and, I assume, consequently 'new'). The kernel provides its own dynamic memory allocation functions, so any such dynamic library would need to be changed to use those.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-14 15:58 +0200 |
| Message-ID | <tfsmm5$2vqod$2@dont-email.me> |
| In reply to | #86318 |
On 14/09/2022 14:12, Juha Nieminen wrote: > David Brown <david.brown@hesbynett.no> wrote: >> 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. > > Would probably not be usable without modifications because in (Linux) > kernel code you can't use 'malloc()' (and, I assume, consequently 'new'). > The kernel provides its own dynamic memory allocation functions, so > any such dynamic library would need to be changed to use those. I believe the EASTL is flexible enough to support any allocator you want, though it has a different concept of allocator than the C++ standard library. And you can always override global "new". But no, I am not suggesting that it would be an off-the-shelve solution - merely that it is possible to have much of the convenience of C++ containers and other library features while avoiding some of the bits you don't want in an OS kernel.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-13 06:47 +0000 |
| Message-ID | <tfp92n$dv$1@gioia.aioe.org> |
| In reply to | #86258 |
In comp.lang.c++ Muttley@dastardlyhq.com wrote: > On Sun, 11 Sep 2022 13:42:20 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >>Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com: >> >>> The necessity is for a language that can have embedded assembler, is very >>> efficient to compile and once compiled and is explicit. Because of this >>> C++'s hidden conversions, exceptions and most of the STL can be ruled >>> out which doesn't leave much left thats an advantage over C. >> >>That all isn't a problem in the kernel if you know what you do. >>Kernel-Programmers are very skilled and the should be able to >>handle that, but it's not up to their mindset. > > Its nothing to do with their mindset, its to do with knowing EXACTLY what the > code is going to do and/or where the program counter is going to go. There > is nothing to fall back on to tidy up any fuckups and no C++ runtime to hold > your hand. You seem to think that the Linux kernel has some kind of extraordinarily strict requirement in terms of what the code is doing, at the lowest level, so that it's always absolutely clear exactly what the CPU is doing at any given moment, what the values of registers (especially the instruction pointer) are, and so on. You seem to be painting kernel code as something that it actually isn't. There's nothing particularly special about kernel code. The vast majority of it is just pretty normal C code with no special requirements. You don't need to know "where the program counter is going to go". Why would you? For what reason? If an interrupt happens, then registers are stored as normal and then restored. (The only peculiar limitation in kernel code is that you can't use the standard C library for anything, because most of it cannot work at the kernel level, especially at boot time before any partitions have been mounted and thus no dynamically loadable libraries can be used. However, this just limits your use of the standard library, for practical reasons rather than "you need to always know where the program counter is going to go". The kernel offers alternatives for most of the standard library utilities that are useful in kernel code.)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-13 13:29 +0000 |
| Message-ID | <tfq0kl$18pe$1@gioia.aioe.org> |
| In reply to | #86294 |
On Tue, 13 Sep 2022 06:47:53 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >(The only peculiar limitation in kernel code is that you can't use the >standard C library for anything, because most of it cannot work at the >kernel level, especially at boot time before any partitions have been >mounted and thus no dynamically loadable libraries can be used. However, Oh dear, and you were doing so well. Heard of libc.a?
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-14 05:56 +0000 |
| Message-ID | <tfrqe2$1afv$1@gioia.aioe.org> |
| In reply to | #86299 |
In comp.lang.c++ Muttley@dastardlyhq.com wrote: > On Tue, 13 Sep 2022 06:47:53 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >>(The only peculiar limitation in kernel code is that you can't use the >>standard C library for anything, because most of it cannot work at the >>kernel level, especially at boot time before any partitions have been >>mounted and thus no dynamically loadable libraries can be used. However, > > Oh dear, and you were doing so well. > > Heard of libc.a? I don't understand what you are trying to say. You cannot use the standard C library in kernel code. It's a hard rule. The kernel sources provide their own alternatives for most standard library utilities that are useful in kernel code. If you didn't know that and you don't believe me, just check it out. And while you are at it, check out *why* you can't use it.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-14 09:37 +0000 |
| Message-ID | <tfs7ct$187i$1@gioia.aioe.org> |
| In reply to | #86304 |
On Wed, 14 Sep 2022 05:56:20 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >In comp.lang.c++ Muttley@dastardlyhq.com wrote: >> On Tue, 13 Sep 2022 06:47:53 -0000 (UTC) >> Juha Nieminen <nospam@thanks.invalid> wrote: >>>(The only peculiar limitation in kernel code is that you can't use the >>>standard C library for anything, because most of it cannot work at the >>>kernel level, especially at boot time before any partitions have been >>>mounted and thus no dynamically loadable libraries can be used. However, >> >> Oh dear, and you were doing so well. >> >> Heard of libc.a? > >I don't understand what you are trying to say. > >You cannot use the standard C library in kernel code. It's a hard rule. >The kernel sources provide their own alternatives for most standard >library utilities that are useful in kernel code. > >If you didn't know that and you don't believe me, just check it out. >And while you are at it, check out *why* you can't use it. The reason is nothing to with with dynamically loadable libraries as you stated. That was my point.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-09-11 09:51 -0700 |
| Subject | boost::intrusive. Was: "Richard Stallman Announces C Reference" |
| Message-ID | <3a21256e-d6fa-483e-90b1-22bcaca1dde0n@googlegroups.com> |
| In reply to | #86253 |
On Sunday, September 11, 2022 at 12:44:40 PM UTC+3, Mut...@dastardlyhq.com wrote: > On Sun, 11 Sep 2022 11:16:14 +0200 > Bonita Montero <Bonita....@gmail.com> wrote: > >Am 11.09.2022 um 10:29 schrieb Mut...@dastardlyhq.com: > >> On Sat, 10 Sep 2022 18:16:45 +0200 > >> Bonita Montero <Bonita....@gmail.com> wrote: > >>> Am 09.09.2022 um 19:49 schrieb Lynn McGuire: > >>>> "Richard Stallman Announces C Reference" > >>>> > >>>> > >>> > >https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-re > > > >>> ference.html > >>>> > >>>> "Richard Stallman (RMS) is a controversial figure - you either like or > >>>> dislike him - but you have to assume he knows his C. So an announcement > >>>> that he has a book on the subject is interesting." > >>>> > >>>> "As you might guess, being the founder of the Free Software Foundation, > >>>> Stallman's book is free to download, but at this stage you will have to > >>>> do some work if you want to read it and it seems to be still in beta. > >>>> The text contains requests for comments." > >>>> > >>>> I did not know that RS wrote the first gcc compiler. > >>>> > >>>> Lynn > >>> > >>> C is a good language to learn programming > >>> but actually not to solve real tasks. > >> > >> Real tasks such as most OS kernels and all the GNU command line utilities? > > > >That's a matter of the writer's mindset and tradition and > >not of necessities. > The necessity is for a language that can have embedded assembler, is very > efficient to compile and once compiled and is explicit. Because of this C++'s > hidden conversions, exceptions and most of the STL can be ruled out which > doesn't leave much left thats an advantage over C. Back in 2008 I found boost::intrusive project very promising. It promised many of advantages as STL containers without any exceptions and memory allocation outside of user's control. Didn't follow it since then. Would guess, it somehow didn't deliver otherwise by now it would be part of STL.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-11 18:55 +0200 |
| Subject | Re: boost::intrusive. Was: "Richard Stallman Announces C Reference" |
| Message-ID | <tfl3ta$207i5$1@dont-email.me> |
| In reply to | #86268 |
Am 11.09.2022 um 18:51 schrieb Michael S: > Back in 2008 I found boost::intrusive project very promising. > It promised many of advantages as STL containers without any exceptions > and memory allocation outside of user's control. > Didn't follow it since then. > Would guess, it somehow didn't deliver otherwise by now it would be > part of STL. I don't know why someone should drop exceptions. Error handling is sinewy anyway, but exceptions are the most comfortable way to have error-handling.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-11 16:26 +0000 |
| Message-ID | <Y_nTK.405773$iiS8.111438@fx17.iad> |
| In reply to | #86252 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 11.09.2022 um 10:29 schrieb Muttley@dastardlyhq.com: >> On Sat, 10 Sep 2022 18:16:45 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 09.09.2022 um 19:49 schrieb Lynn McGuire: >>>> "Richard Stallman Announces C Reference" >>>> >>>> >>> https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-re >>> ference.html >>>> >>>> "Richard Stallman (RMS) is a controversial figure - you either like or >>>> dislike him - but you have to assume he knows his C. So an announcement >>>> that he has a book on the subject is interesting." >>>> >>>> "As you might guess, being the founder of the Free Software Foundation, >>>> Stallman's book is free to download, but at this stage you will have to >>>> do some work if you want to read it and it seems to be still in beta. >>>> The text contains requests for comments." >>>> >>>> I did not know that RS wrote the first gcc compiler. >>>> >>>> Lynn >>> >>> C is a good language to learn programming >>> but actually not to solve real tasks. >> >> Real tasks such as most OS kernels and all the GNU command line utilities? > >That's a matter of the writer's mindset and tradition and >not of necessities. But they "solve real tasks", which you claimed wasn't the case. Admit you were wrong, just this once.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-11 18:35 +0200 |
| Message-ID | <tfl2on$2034v$2@dont-email.me> |
| In reply to | #86266 |
Am 11.09.2022 um 18:26 schrieb Scott Lurndal: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 11.09.2022 um 10:29 schrieb Muttley@dastardlyhq.com: >>> On Sat, 10 Sep 2022 18:16:45 +0200 >>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> Am 09.09.2022 um 19:49 schrieb Lynn McGuire: >>>>> "Richard Stallman Announces C Reference" >>>>> >>>>> >>>> https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-re >>>> ference.html >>>>> >>>>> "Richard Stallman (RMS) is a controversial figure - you either like or >>>>> dislike him - but you have to assume he knows his C. So an announcement >>>>> that he has a book on the subject is interesting." >>>>> >>>>> "As you might guess, being the founder of the Free Software Foundation, >>>>> Stallman's book is free to download, but at this stage you will have to >>>>> do some work if you want to read it and it seems to be still in beta. >>>>> The text contains requests for comments." >>>>> >>>>> I did not know that RS wrote the first gcc compiler. >>>>> >>>>> Lynn >>>> >>>> C is a good language to learn programming >>>> but actually not to solve real tasks. >>> >>> Real tasks such as most OS kernels and all the GNU command line utilities? >> >> That's a matter of the writer's mindset and tradition and >> not of necessities. > > But they "solve real tasks", which you claimed wasn't the case. > Admit you were wrong, just this once. Yes they do, but with much more work than a proper language would make.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web