11 ms·

C++ has far more to offer over C than just template metaprogramming. Basic memory management and error handling, for example, are radically easier and less err

C++ has far more to offer over C than just template metaprogramming. Basic memory management and error handling, for example, are radically easier and less error prone in C++ than in C. Less reliance on macros and goto's should be pretty obvious wins. There's really very little reason to ever use C over C++ with modern toolchains.

naasking 9y ago
> Basic memory management and error handling, for example, are radically easier and less error prone in C++ than in C. Microkernels don't need memory management. Dynamic memory management in a kernel is a denial of service attack vector. Fuschia is built on a microkernel, so I expect they will follow the property of every microkernel since the mid 90s: no dynamic memory allocation in the kernel, all memory needed is allocated at boot. Furthermore, you don't want exceptions in kernel code. That carries huge and surprising runtime execution and space costs. Simply put, there is no reason to choose C++ for a microkernel, and many, many reasons not to.
- stouset 9y ago
  Let’s say I take your assertions at face value. Supposedly qualified, intelligent engineers who were no doubt aware of these points still decided C++ was an appropriate language to implement this microkernel. Surely there’s a reason. Why?
  - naasking 9y ago
    > Supposedly qualified, intelligent engineers who were no doubt aware of these points Are they aware of them? That's not so clear. There's a lot of literature in microkernel design. Lots of things have been tried which sound good but haven't worked out, and some things didn't work out well before would work well now. As usual, security also rarely gets the attention it deserves and it's doubly important at the kernel level.
    - s2g 9y ago
      Ah, so basically anyone who doesn’t agree with you just doesn’t understand.
      - deleted 9y ago
        [deleted]
      - deleted 9y ago
        [deleted]
      - naasking 9y ago
        That would be the principle of charity in action. I would hope those who disagree would approach disagreements the same way, and one or both of us will learn the truth. Should I be assuming people who disagree with me as idiots or evil?
        stouset 9y ago
        The principle of charity would have you assume there do exist good reasons to write a microkernel in C++. Perhaps not ones that you would agree outweigh the downsides, but at the very least I suspect there’s some argument to be made in favor that isn’t simply staggering ignorance.
        michaelmrose 9y ago
        Wouldn't it be easy enough to assume that c++ has the necessary features, performance to do the job and the authors were presumably very familiar with c++ and decided existing expertise outweighed perceived advantages of other options? This does not seem incredibly complicated.
        naasking 9y ago
        > The principle of charity would have you assume there do exist good reasons to write a microkernel in C++ Except this was tried. More than once for different kernels (EROS and L4 at least), and they regretted it and then switched back to C. Both projects made many excellent arguments against C++ in a microkernel that haven't suddenly disappeared in modern C++. So I think I am being charitable in this case because the weight of evidence suggests otherwise. It's charitable to assume that the developers are well meaning but aren't familiar with the history. This isn't staggering ignorance, just ordinary run of the mill ignorance.
- kllrnohj 9y ago
  > Microkernels don't need memory management. Of course they do. It takes memory to hold metadata about a process. It takes memory to hold resources about other services. It takes memory to pass data between them. Just because that memory is reserved at boot doesn't mean it suddenly has no lifecycle of any kind. > Furthermore, you don't want exceptions in kernel code. Nobody said anything about C++ throw/catch exceptions. > Simply put, there is no reason to choose C++ for a microkernel, and many, many reasons not to. If you want to avoid C++ that's great, but to argue for C over it is insanity rooted in nostalgia.
  - naasking 9y ago
    > Just because that memory is reserved at boot doesn't mean it suddenly has no lifecycle of any kind. Yes it does. The "lifecycle" is: allocate at boot, machine halts. All of the memory you describe for other purposes is allocated at user level and booked to processes. This is how you make a kernel immune to DoS. > Nobody said anything about C++ throw/catch exceptions. That's the only meaningful difference in error handling between C and C++. Since you mentioned error handling as a reason to choose C++, what else could you possibly mean? > If you want to avoid C++ that's great, but to argue for C over it is insanity rooted in nostalgia. Sure, you keep believing that. It's clear you're not familiar with microkernel design. The advantages C++ has for application-level programming are useless in this domain.
    - mortdeus 9y ago
      how about we argue the impossibility of most people ever being able to understand what's going on in C++ code (even their own code) and the cataclysmic consequences of using an over convoluted language? I mean there is a reason why the original pioneers of C don't use C++. (i mean other than the fact that dmr is dead)
      - paulhilbert 9y ago
        So goto spaghetti is understandable? And dropping those isn't an argument since proper C++ usage also implies agreeing on a proper subset of the language to use. Modern C++ with sane restrictions is way more easy to understand. Especially w.r.t. resource ownership and lifetimes (as pointed out).
- muizelaar 9y ago
  There's dynamic memory allocation in the kernel: https://fuchsia.googlesource.com/zircon/+/master/kernel/kernel/thread.c#131 https://fuchsia.googlesource.com/zircon/+/master/kernel/kern... https://fuchsia.googlesource.com/zircon/+/master/kernel/object/message_packet.cpp#31 https://fuchsia.googlesource.com/zircon/+/master/kernel/obje...
  - naasking 9y ago
    Well that's a shame! Unless we're missing something in the control path leading to these points, this kernel has trivially exploitable DoS problems. Creating threads doesn't require a capability, so at least the thread allocation is a clear DoS.
- petters 9y ago
  Surely constructs like scope guards etc. are useful in kernel development as well?
  - rjeli 9y ago
    C compilers have scope guard extensions. http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html http://echorand.me/site/notes/articles/c_cleanup/cleanup_att... Systemd uses it: https://github.com/systemd/systemd/blob/5809f340fd7e5e6c76e229059c50d92e1f57e8d8/src/basic/alloc-util.h#L50-L54 https://github.com/systemd/systemd/blob/5809f340fd7e5e6c76e2...
    - pjmlp 9y ago
      Language extensions is the keyword here. Some people rather use official language features.
      - auvrw 9y ago
        part of making a new operating system could be getting to muck with the language features ... ... i suppose this project is locked into G-standard C++ and with lots of good reasons (e.g. toolchain). although i'm an anti-C++ person, i suppose the sorts of tools available internal to Alphabet make it much more manageable. anyway, for an example of the original premise: i'm slowly learning some things about plan 9 C via 9front.. there are some departures from ANSI C, including additional features like (completely undocumented, except for the relatively compact source) operator overloading. equally important for the type of person that finds C++ too busy, some features (e.g. certain preprocessor features) are removed.
  - naasking 9y ago
    Exceptions and even RAII should never be used in a microkernel. This might be useful in a monolothic kernel, but that's not the context here.
    - jensa1948 9y ago
coldtea 9y ago
>Basic memory management and error handling, for example, are radically easier and less error prone in C++ than in C You wouldn't be doing much memory management in such a kernel. And where you would, you wouldn't let it to C++.
flohofwoe 9y ago
> There's really very little reason to ever use C over C++ with modern toolchains. - most C code compiles magnitudes faster than most C++ code (unless you don't use templates or the C++ stdlib) - you need C headers anyway for the public API, because the C++ ABI is not standardized (and a mess), trying to do shared libraries with C++ would result in such abominations like COM - about half of features that C++ adds on top of C only make sense if you do OOP and encourage bad practices - C is a much simpler and "complete" language, there's less room for debating about coding style, what C++ subset to use etc... (that's one thing that Go got right). Also, Eric S.Raymond's "informed rant" on C++ is relevant: http://esr.ibiblio.org/?p=7724 http://esr.ibiblio.org/?p=7724 I'd really like to see a simple language which fixes C's (very few) flaws succeed, but C++ ain't that.
- jensa1948 9y ago
  Eric S. Raymond's article is indeed interesting, but it doesn't contain a lot of real arguments. I find most of them to be anecdotes and they are not very convincing. The most convincing one is that people who are not proficient in C++ write code with horrible errors, and that is because the language contains so many subtle (and obvious) ways to shoot yourself in the head. Most of the problems C++ has are coming from being backward-compatible with outdated language features, explicitly the C-subset. Even the problems with the toolchain are more less inherited from the C compile-link model and its use of the preprocessor as a "module" system. If you use the language as intended, e.g. in the C++ core guidelines, you will se very nice language emerging which enables to write very efficient and elegant code, sometimes doing things that C cannot do, such as expression templates.
  - sjellis 9y ago
    "If you use the language as intended, e.g. in the C++ core guidelines, you will se very nice language emerging which enables to write very efficient and elegant code, sometimes doing things that C cannot do, such as expression templates." JavaScript is also an ongoing effort to extract and evolve a good working language out of a mass of features. It's obviously doable, but not easy, and there are a lot of problems in practice.
sanxiyn 9y ago
> There's really very little reason to ever use C over C++ with modern toolchains. Formal verification is one reason. There is still no formal model of C++ and C formal tools are light years ahead.
billfruit 9y ago
Yes and effortless ease of using user defined types provide much more type safety, compared with C.

naasking 9y ago

> Basic memory management and error handling, for example, are radically easier and less error prone in C++ than in C. Microkernels don't need memory management. Dynamic memory management in a kernel is a denial of service attack vector. Fuschia is built on a microkernel, so I expect they will follow the property of every microkernel since the mid 90s: no dynamic memory allocation in the kernel, all memory needed is allocated at boot. Furthermore, you don't want exceptions in kernel code. That carries huge and surprising runtime execution and space costs. Simply put, there is no reason to choose C++ for a microkernel, and many, many reasons not to.

stouset 9y ago
Let’s say I take your assertions at face value. Supposedly qualified, intelligent engineers who were no doubt aware of these points still decided C++ was an appropriate language to implement this microkernel. Surely there’s a reason. Why?
- naasking 9y ago
  > Supposedly qualified, intelligent engineers who were no doubt aware of these points Are they aware of them? That's not so clear. There's a lot of literature in microkernel design. Lots of things have been tried which sound good but haven't worked out, and some things didn't work out well before would work well now. As usual, security also rarely gets the attention it deserves and it's doubly important at the kernel level.
  - s2g 9y ago
    Ah, so basically anyone who doesn’t agree with you just doesn’t understand.
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]
    - naasking 9y ago
      That would be the principle of charity in action. I would hope those who disagree would approach disagreements the same way, and one or both of us will learn the truth. Should I be assuming people who disagree with me as idiots or evil?
      - stouset 9y ago
        The principle of charity would have you assume there do exist good reasons to write a microkernel in C++. Perhaps not ones that you would agree outweigh the downsides, but at the very least I suspect there’s some argument to be made in favor that isn’t simply staggering ignorance.
        michaelmrose 9y ago
        Wouldn't it be easy enough to assume that c++ has the necessary features, performance to do the job and the authors were presumably very familiar with c++ and decided existing expertise outweighed perceived advantages of other options? This does not seem incredibly complicated.
        naasking 9y ago
        > The principle of charity would have you assume there do exist good reasons to write a microkernel in C++ Except this was tried. More than once for different kernels (EROS and L4 at least), and they regretted it and then switched back to C. Both projects made many excellent arguments against C++ in a microkernel that haven't suddenly disappeared in modern C++. So I think I am being charitable in this case because the weight of evidence suggests otherwise. It's charitable to assume that the developers are well meaning but aren't familiar with the history. This isn't staggering ignorance, just ordinary run of the mill ignorance.
kllrnohj 9y ago
> Microkernels don't need memory management. Of course they do. It takes memory to hold metadata about a process. It takes memory to hold resources about other services. It takes memory to pass data between them. Just because that memory is reserved at boot doesn't mean it suddenly has no lifecycle of any kind. > Furthermore, you don't want exceptions in kernel code. Nobody said anything about C++ throw/catch exceptions. > Simply put, there is no reason to choose C++ for a microkernel, and many, many reasons not to. If you want to avoid C++ that's great, but to argue for C over it is insanity rooted in nostalgia.
- naasking 9y ago
  > Just because that memory is reserved at boot doesn't mean it suddenly has no lifecycle of any kind. Yes it does. The "lifecycle" is: allocate at boot, machine halts. All of the memory you describe for other purposes is allocated at user level and booked to processes. This is how you make a kernel immune to DoS. > Nobody said anything about C++ throw/catch exceptions. That's the only meaningful difference in error handling between C and C++. Since you mentioned error handling as a reason to choose C++, what else could you possibly mean? > If you want to avoid C++ that's great, but to argue for C over it is insanity rooted in nostalgia. Sure, you keep believing that. It's clear you're not familiar with microkernel design. The advantages C++ has for application-level programming are useless in this domain.
  - mortdeus 9y ago
    how about we argue the impossibility of most people ever being able to understand what's going on in C++ code (even their own code) and the cataclysmic consequences of using an over convoluted language? I mean there is a reason why the original pioneers of C don't use C++. (i mean other than the fact that dmr is dead)
    - paulhilbert 9y ago
      So goto spaghetti is understandable? And dropping those isn't an argument since proper C++ usage also implies agreeing on a proper subset of the language to use. Modern C++ with sane restrictions is way more easy to understand. Especially w.r.t. resource ownership and lifetimes (as pointed out).
muizelaar 9y ago
There's dynamic memory allocation in the kernel: https://fuchsia.googlesource.com/zircon/+/master/kernel/kernel/thread.c#131 https://fuchsia.googlesource.com/zircon/+/master/kernel/kern... https://fuchsia.googlesource.com/zircon/+/master/kernel/object/message_packet.cpp#31 https://fuchsia.googlesource.com/zircon/+/master/kernel/obje...
- naasking 9y ago
  Well that's a shame! Unless we're missing something in the control path leading to these points, this kernel has trivially exploitable DoS problems. Creating threads doesn't require a capability, so at least the thread allocation is a clear DoS.
petters 9y ago
Surely constructs like scope guards etc. are useful in kernel development as well?
- rjeli 9y ago
  C compilers have scope guard extensions. http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html http://echorand.me/site/notes/articles/c_cleanup/cleanup_att... Systemd uses it: https://github.com/systemd/systemd/blob/5809f340fd7e5e6c76e229059c50d92e1f57e8d8/src/basic/alloc-util.h#L50-L54 https://github.com/systemd/systemd/blob/5809f340fd7e5e6c76e2...
  - pjmlp 9y ago
    Language extensions is the keyword here. Some people rather use official language features.
    - auvrw 9y ago
      part of making a new operating system could be getting to muck with the language features ... ... i suppose this project is locked into G-standard C++ and with lots of good reasons (e.g. toolchain). although i'm an anti-C++ person, i suppose the sorts of tools available internal to Alphabet make it much more manageable. anyway, for an example of the original premise: i'm slowly learning some things about plan 9 C via 9front.. there are some departures from ANSI C, including additional features like (completely undocumented, except for the relatively compact source) operator overloading. equally important for the type of person that finds C++ too busy, some features (e.g. certain preprocessor features) are removed.
- naasking 9y ago
  Exceptions and even RAII should never be used in a microkernel. This might be useful in a monolothic kernel, but that's not the context here.
  - jensa1948 9y ago

coldtea 9y ago

>Basic memory management and error handling, for example, are radically easier and less error prone in C++ than in C You wouldn't be doing much memory management in such a kernel. And where you would, you wouldn't let it to C++.

flohofwoe 9y ago

> There's really very little reason to ever use C over C++ with modern toolchains. - most C code compiles magnitudes faster than most C++ code (unless you don't use templates or the C++ stdlib) - you need C headers anyway for the public API, because the C++ ABI is not standardized (and a mess), trying to do shared libraries with C++ would result in such abominations like COM - about half of features that C++ adds on top of C only make sense if you do OOP and encourage bad practices - C is a much simpler and "complete" language, there's less room for debating about coding style, what C++ subset to use etc... (that's one thing that Go got right). Also, Eric S.Raymond's "informed rant" on C++ is relevant: http://esr.ibiblio.org/?p=7724 http://esr.ibiblio.org/?p=7724 I'd really like to see a simple language which fixes C's (very few) flaws succeed, but C++ ain't that.

jensa1948 9y ago
Eric S. Raymond's article is indeed interesting, but it doesn't contain a lot of real arguments. I find most of them to be anecdotes and they are not very convincing. The most convincing one is that people who are not proficient in C++ write code with horrible errors, and that is because the language contains so many subtle (and obvious) ways to shoot yourself in the head. Most of the problems C++ has are coming from being backward-compatible with outdated language features, explicitly the C-subset. Even the problems with the toolchain are more less inherited from the C compile-link model and its use of the preprocessor as a "module" system. If you use the language as intended, e.g. in the C++ core guidelines, you will se very nice language emerging which enables to write very efficient and elegant code, sometimes doing things that C cannot do, such as expression templates.
- sjellis 9y ago
  "If you use the language as intended, e.g. in the C++ core guidelines, you will se very nice language emerging which enables to write very efficient and elegant code, sometimes doing things that C cannot do, such as expression templates." JavaScript is also an ongoing effort to extract and evolve a good working language out of a mass of features. It's obviously doable, but not easy, and there are a lot of problems in practice.

sanxiyn 9y ago

> There's really very little reason to ever use C over C++ with modern toolchains. Formal verification is one reason. There is still no formal model of C++ and C formal tools are light years ahead.

billfruit 9y ago

Yes and effortless ease of using user defined types provide much more type safety, compared with C.