4 ms·

> A desktop OS done in C++ instead of C. Which part? IOKit, for writing kernel drivers for Darwin's xnu kernel is C++. Cocoa is mostly Objective-C and not pl

> A desktop OS done in C++ instead of C. Which part? IOKit, for writing kernel drivers for Darwin's xnu kernel is C++. Cocoa is mostly Objective-C and not plain C. What would C++ improve there? So… which other part would redoing in C++ improve? The kernel filesystem layer? The internal kernel exec implementation? I'm not seeing what C++ brings to the table in any of these cases. Maybe the POSIX layer itelf? That could be new and interesting, but the C++ ABI isn't really compatible with much beyond C++ itself. The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs. Now a kernel written Rust… that's something I'd like to see. But then again, what would the userspace interface layer for such a kernel look like? POSIX?

pjmlp 12y ago
> Which part? IOKit, for writing kernel drivers for Darwin's xnu kernel is C++. Everything. > I'm not seeing what C++ brings to the table in any of these cases. Making C move out of the scene and moving into safer languages for systems programming. Even though C++ also has its issues, but at least it is way safer than C. There are C++ OS like Symbian, OS/400, Genode and also Windows is moving into that direction. However having a desktop OS to point out to as example, would be nice to the C++ community. > The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs. This is a consequence of C ABI being the OS ABI. Outside the UNIX world there are a few OS were this wasn't true. > Now a kernel written Rust… that's something I'd like to see. But then again, what would the userspace interface layer for such a kernel look like? POSIX? Me too. POSIX is tied to C, the API should be something modern.
- __david__ 12y ago
  > Making C move out of the scene and moving into safer languages for systems programming. Even though C++ also has its issues, but at least it is way safer than C. I guess I don't see as being "way" safer than C. I see it as being marginally safer [1], but with an arbitrary and rigid object model. > > The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs. > This is a consequence of C ABI being the OS ABI. Perhaps. But a non-OO interface layer makes a lot of sense anyway (or at least OO agnostic ones). The problem with making your main OS interface be C++ is that now every other language has to contort its object model to match the C++ one. How do you write Go code that interfaces with the C++ OS objects? C++ and Go are remarkably different. Ruby and C++ are different, as is Perl, Obj-C, Python, and Java. Either you have to use barely anything from C++ (really light inheritance, no STL, no RIAA, etc.) or you have to have extremely severe wrappers for every non-C++ language. The former means you give up on a lot of the safety that C++ gives you and the latter means that every language binding is 100% different. Neither of those is a good option. An idiomatic C++ OS interface sounds good on the surface, but I think it's really only a good idea if you want all the user code to be written in C++, too. [1] Everything you can do wrong in C you can also do in C++: Good old "((void(*)())0)();" compiles in both.
  - pjmlp 12y ago
    > I guess I don't see as being "way" safer than C. Agree. But at least C++, the language, gives you the tools to write safer code, when you stick to what STL offers or similar libraries. With C, only third party tools that aren't available everywhere. Not to mention that back in 80's, C already felt primitive and its success is only a consequence of UNIX spreading into the enterprise out of research labs. The best would be to have both gone. But until that doesn't happen C++ is way better than C. > Perhaps. But a non-OO interface layer makes a lot of sense anyway (or at least OO agnostic ones). C++ usage does not imply OO. The language has a lot more to offer. > The problem with making your main OS interface be C++ is that now every other language has to contort its object model to match the C++ one. I fail to see how this is different from OS where C isn't the OS ABI, like the mainframes, almost all of the 80-90's home market OS, for example. Languages have to use the OS ABI. The fact that in most OS C ABI == OS ABI is a side effect of writing the OS in C.
72deluxe 12y ago
IOKit drivers are written in Embedded C++, which is C++ with all the decent bits removed.

pjmlp 12y ago

> Which part? IOKit, for writing kernel drivers for Darwin's xnu kernel is C++. Everything. > I'm not seeing what C++ brings to the table in any of these cases. Making C move out of the scene and moving into safer languages for systems programming. Even though C++ also has its issues, but at least it is way safer than C. There are C++ OS like Symbian, OS/400, Genode and also Windows is moving into that direction. However having a desktop OS to point out to as example, would be nice to the C++ community. > The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs. This is a consequence of C ABI being the OS ABI. Outside the UNIX world there are a few OS were this wasn't true. > Now a kernel written Rust… that's something I'd like to see. But then again, what would the userspace interface layer for such a kernel look like? POSIX? Me too. POSIX is tied to C, the API should be something modern.

__david__ 12y ago
> Making C move out of the scene and moving into safer languages for systems programming. Even though C++ also has its issues, but at least it is way safer than C. I guess I don't see as being "way" safer than C. I see it as being marginally safer [1], but with an arbitrary and rigid object model. > > The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs. > This is a consequence of C ABI being the OS ABI. Perhaps. But a non-OO interface layer makes a lot of sense anyway (or at least OO agnostic ones). The problem with making your main OS interface be C++ is that now every other language has to contort its object model to match the C++ one. How do you write Go code that interfaces with the C++ OS objects? C++ and Go are remarkably different. Ruby and C++ are different, as is Perl, Obj-C, Python, and Java. Either you have to use barely anything from C++ (really light inheritance, no STL, no RIAA, etc.) or you have to have extremely severe wrappers for every non-C++ language. The former means you give up on a lot of the safety that C++ gives you and the latter means that every language binding is 100% different. Neither of those is a good option. An idiomatic C++ OS interface sounds good on the surface, but I think it's really only a good idea if you want all the user code to be written in C++, too. [1] Everything you can do wrong in C you can also do in C++: Good old "((void(*)())0)();" compiles in both.
- pjmlp 12y ago
  > I guess I don't see as being "way" safer than C. Agree. But at least C++, the language, gives you the tools to write safer code, when you stick to what STL offers or similar libraries. With C, only third party tools that aren't available everywhere. Not to mention that back in 80's, C already felt primitive and its success is only a consequence of UNIX spreading into the enterprise out of research labs. The best would be to have both gone. But until that doesn't happen C++ is way better than C. > Perhaps. But a non-OO interface layer makes a lot of sense anyway (or at least OO agnostic ones). C++ usage does not imply OO. The language has a lot more to offer. > The problem with making your main OS interface be C++ is that now every other language has to contort its object model to match the C++ one. I fail to see how this is different from OS where C isn't the OS ABI, like the mainframes, almost all of the 80-90's home market OS, for example. Languages have to use the OS ABI. The fact that in most OS C ABI == OS ABI is a side effect of writing the OS in C.

72deluxe 12y ago

IOKit drivers are written in Embedded C++, which is C++ with all the decent bits removed.