OSDev.org

Owen wrote:C++ is horribly complex. Unfortunately, nobody seems to have made a language with the same applicability and feature set which is better (I'll even ignore the C interoperability feature if you want - just to give said language the ability to get rid of many of the issues that plague C++).

Objective-C is a language with two personalities: One C, one Smalltalk. It has manual resource management, but it has a very consistent ownership model (primarily thanks to Cocoa) and good tools for dealing with some of the corner cases (primarily NSAutoreleasePool), plus recently added features like Automated Reference Counting (and, interestingly, the recently dropped feature of garbage collection)

I think it's quite telling that Microsoft, who seem to have the most to gain from managed code, recently introduced C++ AMP as their new concurrency system

I've been using C++ for quite some time now too, and even though it's one of my favorite languages and I'm not really fond of managed languages, I must admit that C++ is a beast (not just syntactically). I've also recently acquainted myself with the D programming language, which comes dangerously close to taking my favor away from C++ (native language, with managed features and a GC, but allows disabling the GC for performance-critical area's, such as in games). The only downside is that D doesn't really seem to be being picked up (although I've heard that GDC, the GCC front-end of the D compiler, is planned on being merged into GCC 4.8 ), nor there aren't a lot of GUI libs (there was an initiative of adding D bindings for Qt, but it seems to be dead). IMHO this is really a shame! I've written a couple of simple tools in D and it feels like it has the potential to come close to C++' raw power (or work with it, for that matter), adding a lot of neat features in the meantime.

Some of this neat features aren't really needed in C++ (we have RAII, so we don't need that scoped thing, for example), or are going to be introduced (like static if, it's 100% cadidate for C++1x), but are possible to easily implement in current C++ (SFINAE). To conclude this short post: D is a bit less powerful than C++ language that is trying to do C++'s job, but fails hard (C++ has never had a problem with two different versions of "standard" library, WTF).

Griwes wrote:Some of this neat features aren't really needed in C++ (we have RAII, so we don't need that scoped thing, for example), or are going to be introduced (like static if, it's 100% cadidate for C++1x), but are possible to easily implement in current C++ (SFINAE). To conclude this short post: D is a bit less powerful than C++ language that is trying to do C++'s job, but fails hard (C++ has never had a problem with two different versions of "standard" library, WTF).

Well, of course you can argue that most of D's features that C++ doesn't have are "unnecessary", since C++ is already an awesome language in se and has been proven to work well time and time again. The question is therefore not so much "what does D do that C++ can't?", but it's more "what can we change and add to C++ to make it better, without compromising the power it already offers too much?". I'm not trying to say that D is better than C++, nor invoke a religious war or anything, I'm merely stating that D has some neat features that might be interesting for people looking for a C-like language that is still native and performant (I'm not sure as to how well D performs at this time, as it hasn't been around for an incredible long time and there may still be more optimization possibilities) and can offer some "newer" features, like garbage collection, built-in copy-on-write in the standard library (i.e. for classes like string and arrays), a standard library containing a lot of useful stuff (like path manipulation, XML, zipping, etc.), etc. It's best to just look at the [url=dlang.org]D site[/url] and browse through the library and language functions. C++11 however has brought a lot of neat features to C++ too (I'm especially fond of the new std::thread and other functions), although this doesn't take away that C++' standard library is IMHO still a bit awkward (not necessarily hard) compared to recent languages. Also: ignore the "D is better than C++" propaganda on the D site, it's really an OK language but stating it's better than C++ at this point is just plain bollocks.

Back on-topic: I agree that native languages will be here for quite some time. As said before, most managed languages require some sort of virtualization platform to run on, so even if an OS was to be built entirely around that platform, a native language would still be usable for replacing that OS. Perhaps this is exactly the same as what "happened" to assembly, is it still being used in modern desktop applications? No, barely. But is it still useful? I think this community knows better than anyone that the answer is yes, it is!

OSwhatever wrote:I think there is thread previously about this but I don't want bump it.

Most of us here are developing on kernels that use MMU but since the trend towards managed code continues this will eventually sneak down to system code. I wonder how redundant creating kernels in C/C++ is right now. As I see it, the fundamental change is the protection granularity, you go from protection on process level to protection to object level. There is very little HW support for object protection so it must be handled by SW. Despite the performance hit of run-time checks you automatically get other advantages.

There is still a huge difference. The public/protected/private in C++ is a compile time check done by the compiler and easily violated accidentally or purposefully. That is why C++ programms still segfault. On the other hand the MMU is controled by trusted software (the kernel) outside the influence of the programm and does runtime checks. Unless you want new() to involve a syscall for every instance to create the object you will still need the MMU.

OSwhatever wrote: There is ~1.3 as many memory references with MMU on.
HW page table walkers are quite expensive silicon wise, if we just could avoid them the cpu will become simpler.
Programming productivity increases

We Singularity which is an R&D experiment but there are a few Java based OSes out there that has found its way into some commercial embedded systems. I wonder if there is anybody here have any experience with these OSes when it comes to performance, porting and development speed.

So I ask you, are most of us tinkering with already redundant technology? Will the MMU, be just like the hardware task switcher found in several CPUs that usually end up being unused?

Maybe you are looking for an exokernel. In recent years there have been several developed for use in the cloud (or other virtual machine environments). Forget about having kernel, userspace and applications. Your application is the kernel and you start it as VM. You want a second application then it gets its own VM.