OSDev.org

Posted: **Wed Jan 28, 2009 9:54 pm**

C# has pointers, but they are often overlooked. You can only use them in methods or code blocks marked as "unsafe", and you have to use a "fixed" statement (IIRC) to pin memory so the GC doesn't move it before you can get a pointer to it.

IMO, if an OS kernel (Singularity) can be written in C#, then it's just a matter of time before it becomes more broadly applicable to systems programming. The language need not (and does not) drag the entire .NET environment around with it.

Posted: **Wed Jan 28, 2009 10:09 pm**

Love4Boobies wrote:I find it a bit ackward that everyone's talking about the death of C++ but (AFAIK) no one has ever mentioned the death of C. Why's that?

People have already given good reasons as an answer to this, but I figured I'd chime in with Linus Torvalds and his opinion.

There's actually quite a bit of 'pro-c, anti-c++' sentiment, which I am admittedly a part of... the previous posters covered the topic pretty well, I think.

Posted: **Thu Jan 29, 2009 12:45 am**

Colonel Kernel wrote:IMO, if an OS kernel (Singularity) can be written in C#, then it's just a matter of time before it becomes more broadly applicable to systems programming. The language need not (and does not) drag the entire .NET environment around with it.

Maybe. IMO that wouldn't be the best move. Perhaps it would be most wise (and fast) to just come up with a CIL CPU (don't forget that there are already Java CPUs out there). I'm aware of the compatibility issues raised by this, but if we really reach that point, even x86 could execute CIL running say, CIL Mode, instead of pmode or long mode or whatever... Hardware is finally starting to be software-driven these days (look at what they're doing at PARLAB, Berkeley).

Posted: **Thu Jan 29, 2009 1:35 am**

steveklabnik wrote:People have already given good reasons as an answer to this, but I figured I'd chime in with Linus Torvalds and his opinion.

Personally, when I look for a good piece of BS to laugh about, I take The Linux Kernel Mailing List FAQ, chapter 15-3. Those guys are a serious case of xenophobia, and don't know bollocks about C++. I mean, it would be OK if they said "we're mostly C guys here, and don't know C++ really, so we stick to C". I could totally relate to that. But the FUD I see in that post of Linus, and in the FAQ, would be a crying matter if it weren't so funny.

Let's see. What are Linus' points?

C++ coders are crap and C coders are great.
Coding in C++ "invariably" leads to using the STL and Boost libraries.
Coding in C++ "invariably" leads to bad abstractions your code depends on, so you have to rewrite your object model sooner or later. Coding in C doesn't.
C++ code is less maintainable than C.

That's what he says, between all that "BS" and "piss off" he seems so fond of. I won't even honor that list with a reply.

The LKML FAQ is even better:

Writing C code so it can be compiled by a C++ compiler results in performance loss. (Hint: You don't have to compile everything in g++, it's about being able to do so.)
Drivers cannot be written in C++ because the kernel headers don't support it. (See next point.)
We won't make the kernel headers support C++ because there aren't any C++ drivers around. (See previous point.)
We won't make the kernel headers support C++ because it's (insert smartass find-and-count) so many lines of code and we are too stupid to do a find-and-replace of C++ keywords using a similar technique as we used for counting code lines.
C++ coders are too stupid to accept a limitation like -fno-exceptions.

That, together with the general attitude that C++ coders are somehow less brilliant than C coders because they do not follow the true path (hallowed are the Ori), originally convinced me that the Linux kernel maintainers are simply another bunch of arrogant twits.

Posted: **Thu Jan 29, 2009 6:06 am**

Hi,
All the so called hacker 'demi gods' are arrogant . I have met one of them , I was one of the starting members of the open source community in my college . I have already told you in pm what happened , that had a big impact on my carrier desicion later .

Regards
Shrek

Posted: **Thu Jan 29, 2009 8:59 am**

Love4Boobies wrote:Maybe. IMO that wouldn't be the best move.

"Maybe" it will take the world by storm, or "maybe" it's possible? I can tell you that it's possible because it's already been done.

Why don't you think it's the best move?

Love4Boobies wrote:Perhaps it would be most wise (and fast) to just come up with a CIL CPU (don't forget that there are already Java CPUs out there). I'm aware of the compatibility issues raised by this, but if we really reach that point, even x86 could execute CIL running say, CIL Mode, instead of pmode or long mode or whatever... Hardware is finally starting to be software-driven these days (look at what they're doing at PARLAB, Berkeley).

CPUs are designed the way they are for a lot of good reasons of which software people are usually ignorant. Java CPUs are slow because they're stack machines and can't take advantage of techniques like out-of-order execution, at least not without translating the bytecode into some internal register-based machine code. What's the point if x86 CPUs already do this? The decoding logic to do this is no longer such a big overhead compared to all the other pipeline stages in a modern x86 CPU.

steveklabnik wrote:People have already given good reasons as an answer to this, but I figured I'd chime in with Linus Torvalds and his opinion.

Linus' opinion doesn't count for much around here.

As Solar said, a lot of what he has to say on the subject is uninformed FUD. His personal style (bombastic, rude, arrogant) makes it difficult to take anything he has to say very seriously. Too bad for him IMO.

Posted: **Thu Jan 29, 2009 10:00 am**

@CK: Then maybe a new design will help: a safe bytecode that can take advantage of different techniques that boost performance. I'm fairly sure it can be done but I'm just as sure it won't...

Posted: **Thu Jan 29, 2009 10:14 am**

Tao Group has a mechanism where code is compiled for a virtual processor, which gets translated to native on-the-fly by the executable loader. That way, you have fully portable executables which still benefit fully from native CPU architecture. The loader was faster at this translation than the hard drive in loading the code, or so they claimed.

All of this heavily patented and IP'd, of course...

Posted: **Thu Jan 29, 2009 10:23 am**

Colonel Kernel wrote:Linus' opinion doesn't count for much around here

Well, I don't take what Linus says as gospel, either. And I certainly don't want to hijack this thread, and turn it into the C vs C++ thread...I also don't even 100% agree with what Linus is saying. I just figured that I'd add in another, slightly different opinion.

I personally feel that C++ doesn't add anything that I feel is really useful over C. I prefer really low level, simple languages, or really high level, complicated languages. The middle ground ones, not so much. This is one reason I don't really like Java, either...

Posted: **Fri Jan 30, 2009 2:14 am**

steveklabnik wrote:I personally feel that C++ doesn't add anything that I feel is really useful over C.

Hard to answer to that without completely hijacking the thread. I think different.

Posted: **Fri Jan 30, 2009 5:11 am**

I had the opportunity to use a pure C project (no C++) and it was certainly different.

I know you could imitate C++'s behaviour since this class:

Code: Select all

class MyClass
{
public:
       MyClass();
       ~MyClass();
       int DoStuff(int param);
private:
       float IAmAFloat;
};

as

Code: Select all

typedef struct sMyClass
{
       float IAmAFloat;
} MyClass;

MyClass *MyClass_New();
void MyClass_Destroy(MyClass *this);
int MyClass_DoStuff(MyClass *this, int param);

Which I found myself doing a lot. And the code became untidy - but I believe that's just my perception after being so use to classes.

Posted: **Fri Jan 30, 2009 5:13 am**

You could make function pointers members of that struct...

But that's beside the point. In the big bag of classes, exceptions, templates, namespaces, function overloading, and type safety, there should be something for anybody.

Posted: **Fri Jan 30, 2009 9:37 am**

Love4Boobies wrote:@CK: Then maybe a new design will help: a safe bytecode that can take advantage of different techniques that boost performance. I'm fairly sure it can be done but I'm just as sure it won't...

What makes you think that such a thing doesn't exist already? Take a look at Bartok, a compiler project by MS research. It is able to apply very powerful interprocedural optimizations to IL and compile it to very efficient native code.

I think you may be conflating performance issues and IL in your mind.

Think more carefully about where you think the bad performance is coming from....

Posted: **Fri Jan 30, 2009 12:16 pm**

Colonel Kernel wrote:
Love4Boobies wrote:@CK: Then maybe a new design will help: a safe bytecode that can take advantage of different techniques that boost performance. I'm fairly sure it can be done but I'm just as sure it won't...
What makes you think that such a thing doesn't exist already? Take a look at Bartok, a compiler project by MS research. It is able to apply very powerful interprocedural optimizations to IL and compile it to very efficient native code.

I think you may be conflating performance issues and IL in your mind. Think more carefully about where you think the bad performance is coming from....

I know of Bartok. Disadvantages:

Some overhead, as you suggest, maybe not large.
Another layer between software and hardware. That can mean trouble (read: bugs).

Posted: **Sat Jan 31, 2009 5:34 am**

Another layer between software and hardware. That can mean trouble (read: bugs).

BS. The same amount of layers as Java or .NET or LLVM has: source->bytecode->native code.

Some overhead, as you suggest, maybe not large.

It has a larger setup cost, yes. But after that the win is much larger than any other language since using bartok results in the privilege to run completely unprotected, and thus, without the repeated overhead incurred by protection layers.

As Colonel Kernel would say: go read the research papers.

OSDev.org

Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++

Re: Moving from Java to C++