Aalto Talk with Linus Torvalds [Full-length] - YouTube Listen to what he has to say about Linux and NVIDIA.
Printable View
Aalto Talk with Linus Torvalds [Full-length] - YouTube Listen to what he has to say about Linux and NVIDIA.
The man is like a child. When something doesn't go like the way he wants, he start pointing fingers and starts shouting foul words at them.
It is as if the man does not understand that all companies cannot--and will not--use Linux's open source model, which does bring about delays at times.
::shrug::
I have a lot of respect for the guy...
Someone, I'm not saying who, did not bother to understand the complaints.Quote:
It is as if the man does not understand that all companies cannot--and will not--use Linux's open source model, which does bring about delays at times.
Soma
Someone did not bother understand the complaint because the behavior was inexcusable either way.
Elysia is just a Linux hater. :D
Well, let me put it this way:
I'm not going to comment on whether nVidia have done the right thing or not. I don't really care about what nVidia does concerning Linux. Though, from what I have heard and seen (including above link), it just seems that nVidia cannot open source their drivers due to business secrets, and because of this their support for Linux have been somewhat lacking.
Nevertheless, I still am not going to agree with Linus's methods. That is why I compared him to a child throwing a tantrum.
O_o
Someone still hasn't bothered to understand the complaints.
I think it is kind of funny, but you not liking his methods is fine.
You talking about issues you don't understand in terms you don't understand makes you look foolish.
Because you aren't willing to look at the issues I'll "sum up" without going into a lot of detail: the issue is that "nVidia" did throw support at "Android" (a Linux derivative) embedded devices with their chips in the form proprietary drivers because they wanted the market share but continually refuse to do the same for "Linux" on desktops or laptops where they already have a huge market share.
This isn't about open source software. The proprietary drivers by "nVidia" for "Linux" sucks.
Linus doesn't give a damn if companies want to keep drivers proprietary; he doesn't like it, but he does accept it as do we all who work in the field.
Soma
O_o
And what, I wonder, is your definition of "sucks" that illustrates to you that I might have misunderstood the complaints to which Linus responds so colorfully?
Soma
The problem is not that the desktop drivers 'suck', from the point of view of the consumer. It has great performance(as proven from benchmarks) , and supports new specs..say new OpenGL versions quickly.
They also bother to update the driver at each Xorg version bump. (which AMD refuses to do.)
And their driver, generally just works, without having to do any troubleshooting.
From the point of view of Nvidia and many users (including me, to some extent), this is great Linux support.
The only complaint from an user (only applicable for laptops) would be the lack of optimus support, which Nvidia refuses to fix.
But, technically speaking, it is a poor 'Linux' driver and that is all Linus should and does cares about.
1. It brings tons of security issues and incompatibility due to UMS...(almost everything has moved to KMS for about a decade)
2. Optimus support would be solved too (almost automagically, in fact), if they used kernel facilities instead of reinventing the wheel poorly.
3. Those using that driver can't submit kernel bug reports. (The reson is out of reach of my technical knowledge)
4. And some others I do not have a clear idea of.
They don't really need to open their drivers, only publish some sort of interface to the hardware and let others create drivers from them. That doesn't expose any sort of 'intellectual property' (the term seems a little moronic to me though), afaik.
O_oQuote:
The problem is not that the desktop drivers 'suck', from the point of view of the consumer.
Yes. They absolutely do suck from the point of view of the consumer.
Did you not get that the people making such complaints are consumers?
[Edit]
Just to be clear here, your smooth experience doesn't invalidate all the terrible experiences of others.
Those "others" who are making these complaints are consumers who just want to use the operating system that they want on their own machines.
I don't know where you got the notion that the proprietary drivers from nVidia for "Linux" don't suck.
They are far better than they were four years ago, but they absolutely do still suck.
[/Edit]
o_OQuote:
The only complaint from an user would be the lack of optimus support, which Nvidia refuses to fix.
That's certainly not the only valid complaint from a nVidia user on "Linux".
You seem to be just as poorly informed as Elysia.
[Edit]
I'm not saying that you are just that you seem so because of such nonsense as "The only complaint from an user would be the lack of optimus support".
That's the only complaint a nVidia user on "Linux" may have?
Which Earth do you live on? (I'm 1218.)
[/Edit]
You say that the driver "generally just works" when it absolutely doesn't. Sure, it works "out-of-the-box" often enough to be recommended over ATI, but that isn't saying anything because ATI drivers also suck and we, at the "LFS" "IRC", spend just as much time helping people chase issues with nVidia drivers as we do with wireless network cards.
By the by, that ("Optimus") was exactly the complaint to which Linus was responding.
This is something they've flatly stated that they will never really consider.Quote:
They don't really need to open their drivers, only publish some sort of interface to the hardware and let others create drivers from them.
[Edit]
Which, actually, this wouldn't be nearly sufficient. The community would still need some support in the form of "FAQ" or something because of the ridiculous complexity of modern video cards.
[/Edit]
Soma
^_^
The conversation in IRC was driven towards this same discussion by accident where this was said of me:
Mr. Queermo - YouTube
Soma
Precisely because not having fully understood the complaints, I will not comment on whether what Linus did was good or bad.
So anyway, disregard anything said about what he did. I retract that. But his methods I don't agree with. A child with a tantrum is what sums him up.
O_o
As far as his position in the community weighs his behavior I actually agree with you that his behavior was inappropriate.
Soma
got a link to the rant on C++?
http://kerneltrap.org/node/2067
His comments make perfect sense (I think) from the perspective of a Kernel Developer, though.
in the context of linux, I would agree, since the entire kernel is written in C since day 1. a new operating system kernel would certainly benefit from an object oriented approach with C++. when linux was first created, C++ was not a very mature language, but now is perfectly adequate for the task of writing a kernel.
Absolutely. Developing a kernel in a language that hides memory allocation, is a disaster waiting to happen.
And as much as I like exceptions, I also agree that they're broken (even for generic applications).
I don't think I know what he means by C++ compilers not being "trustworthy", though.
Really, I do like C++, but I still find his opinion of it to be respectable.
I think that so long as you follow good C++ design practices, the memory allocation and de-allocation can happen automatically and transparently without need for concern. if you overload the new, new[], delete, and delete[] operators to work properly in the context of in-kernel memory management, and make sure to document everything clearly where it allocates and frees memory, you should be able to have a very robust and maintainable piece of software. I do agree that C++ exception handling could be a bit too heavy for kernel code, and other means should probably be employed for handling errors.
in 2004 when the article was written, I think I'd agree with him. the standard was still very new at that point, and many compilers did not support it completely or properly.Quote:
I don't think I know what he means by C++ compilers not being "trustworthy", though.
it's a completely different story today, 8 years later, because the 2003 revision of the standard is well implemented and documented in most compilers.
I was actually talking about this little gem. Linus Torvalds on C++
Btw, I quite like this guy's response to Linus' rant. A response to Linus Torvalds on C++
C++ by itself doesn't hide anything. No one says you have to use STL components ... you can always new and delete explicitly. Obviously, if you were to write a kernel in C++ you'd first decide which features of the language should and shouldn't be used. Even if you would merely use C++ as a beefed up C, you'd still end up with a number of extremely useful things you just wouldn't have if you would use C (RAII, better type safety, templates).
RAII alone would be more than worth it.
that guy really just has a chip on his shoulder about a lot of things, and unjustifiably so. he makes a few valid points, but those points - particularly the one about the STL - are now so entirely moot that it's not even worth discussing anymore. he basically says that there is no reason to ever use C++, and he's just simply wrong about that. C++ is a tool, just like C, that has a purpose and an appropriate application. in fact, I'd say that anyone who insists on using C for performance or portability reasons is just as wrong. C++ is both efficient and portable, and saves the programmer from having to do many things that C forces upon its users. in my opinion, anyone who would deliberately start a new project, especially a major commercial project, insisting on C, is wasting time and energy.
Why? I could say the same about insisting on any particular language. You should always use the language that is best suited for the job. I can't say that I can even name a successful kernel that was not done in either C or assembler.Quote:
in my opinion, anyone who would deliberately start a new project, especially a major commercial project, insisting on C, is wasting time and energy.
I don't see where portability is even an issue. You are talking about writing a portable kernel?? Portability is, in my opinion, higher up on the food chain. Directly accessing the hardware is very non-portable. As far as speed, I think either language is acceptable, when properly used.Quote:
I'd say that anyone who insists on using C for performance or portability reasons is just as wrong.
In my opinion, he never said there is no reason to ever use C++. He just stated that trying to use C++ for a kernel, would be using the wrong tool for that job.Quote:
he basically says that there is no reason to ever use C++
Jim
actually, he effectively said exactly that in the link that antred posted: Linus Torvalds on C++
an exerpt from that article:
Quote:
Originally Posted by Linus Torvalds
The man rails against features he clearly doesn't understand how to use.Quote:
Really, I do like C++, but I still find his opinion of it to be respectable.
Would you respect the opinion if it were given by someone who didn't have his position?
No. You wouldn't.
Let's not pretend his position makes him right. Strangely, that would probably offend the man.
If you are going to find any of that "respectable" then at least respect the bit the is unquestionable: the man is passionate about his science.
Soma
I agree. I respect him as a person, and give him all the credit he deserves for creating the third most popular operating system for PC-based hardware (OS Statistics), but he's way off base with many of his opinions. they seem to be based on old wives' tales, superstition, and "that's the way we've always done it."
Yeah, it's not his choice of C over C++ for the kernel that I have a problem with, its his superficial dismissal of C++ as a horrible language. I'm definitely NOT suggesting that the Linux kernel be rewritten in C++!
but if I were writing a new OS kernel from scratch, C++ would be at the top of my list of languages to use.
This is another thing I have a problem with the man for.
It is as if his love for C is like a cult or religion. That is enough for me to dislike the man.
Although, I cannot fault him to such a big degree. Though he has his faults, I see no harm in the work it does. In fact, it is good work.
no programming language should be a religion. ever single one (with the exception of visual basic ;) ) has its place and its purpose.
C certainly has its place. many embedded systems don't have any C++ compiler support, so C is the only option aside from assembly. for just about any environment that you're likely to encounter with a keyboard and monitor, though, C++ is readily available, and I'd say it should be used for any new project, because, at the very least, it provides a level of safety that today's insecure technology world demands. C provides no safety of any kind. it is entirely up to the programmer to avoid mistakes that C++ will warn about by default, or simply refuse to compile.
O_oQuote:
has its place and its purpose
Well yeah, but that's a far to forgiving measure.
Intercal is a spectacular language in "its place", but the gods forgive the man that ventures down that road for anything other than "........s and giggles".
Soma
Well this thread turned out to be fun.
In world history, you learn about how men in funny hats and their antics shaped our lives.
In computer science, you learn about how every notable figure and their antics are shaping our technology, and a lot of other people will think they're the worst for the job.
I don't think anyone is saying that Linus is the worst for the job. he's done many great things, and certainly deserves respect for it. the issue at hand is more that he's an arrogant, closed-minded jackass.
I don't think he's a jackass. He might be more forthright that Ted Tso or Greg Krone-Hartman on the issue of C over C++, but they all seem to share the same reasons for their preference of around the issues of simplicity (code in relation to machine code produced) and having to be explicit on every single memory allocation. You might disagree with these guys, but between them they have a project that values at over 1 billion dollars and its used in pretty much everything these days - not bad for a bunch of backward thinking dinosaurs!
If you all feel so strongly on how wrong these guys are, I cannot wait to see what you can produce in competition.
https://github.com/torvalds/linux/pu...omment-5654674
Forthright is hardly the proper description of him. I would say aggressive and demeaning:
If this was anyone other that Linus Torvalds, nobody would give him even an ounce of attention. If you can't get your point across without resorting to silly ad hominem attacks like this, chances are your opinion is not worth spending time on.Quote:
Originally Posted by Linus
...
Hmm, after writing out this reply i realized i just called the management at nVidia for morons in this very thread a few pages back, oh well, i guess i don't live up to my own standards on this matter :D
O_oQuote:
I don't think he's a jackass.
His behavior doesn't make him a jackass?
Out of curiosity, would it make me a jackass?
They started the ball rolling, but the avalanche of financial, developer, and vendor support made "Linux" such a monster.Quote:
You might disagree with these guys, but between them they have a project that values at over 1 billion dollars and its used in pretty much everything these days - not bad for a bunch of backward thinking dinosaurs!
"Linux" didn't become the monster it is because of anything to do with those men.
It always sets me to despair when I see people giving popularity greater reverence than science.Quote:
If you all feel so strongly on how wrong these guys are, I cannot wait to see what you can produce in competition.
Oh yes, science! He is provably wrong in most of his rants against other languages; which to me always makes it slightly worse that he duplicated some of those same problems in the kernel code.
*shrug*
Well, someone did; I actually don't know all the authors responsible of course.
Soma
and nickelback sells millions of albums. does that make their music more valid than mine, when my last band sold about 20 copies? no, it does not.
the monetary value of something does not determine its importance or its intrinsic value. Linux is certainly an achievement, but Linus needs to get off his high horse and realize that his opinion is not the only valid one.
^_^;Quote:
Linus needs to get off his high horse and realize that his opinion is not the only valid one.
Well, to be fair, if I had so many telling me how awesome I was I would absolutely start believing the hype.
Soma
>>Out of curiosity, would it make me a jackass?
You?...Never! ;)
^_^
So long as a I get a pass as well...
Soma
>>and nickelback sells millions of albums. does that make their music more valid than mine, when my last band sold about 20 copies? no, it does not.
Validity in this context is purely relative, so I cant argue against the proposition you have made. For the greater number of people in the world probably wont see it in so narrow a context.
>>the monetary value of something does not determine its importance or its intrinsic value.
You might not like that I used a financial value/cost measure to assess the project's validity, but for me its a decent yardstick (BTW my career is finance based so maybe I have a tendency towards this way of thinking :( ). I can also suggest the kernel's usage in all different types of systems from super computers to tiny £25 gadgets, the amount of exposure we all have to it in our day to day lives or the way its licensed for usage.
Still, the measure of validity of the project itself is itself not a perfect way to measure the validity of the opinions of the people involved - I accept that. Ultimately its an issue of preference based on individual experience - and arguing with others who have different preferences based on individual experience rarely ends in consensus. I should know that by now, and I should know never to post an opinion after opening a bottle of wine! :)
-_-
This isn't exactly "on topic" as much as it might be anyway so I feel justified in asking, what kind of wine?
Soma
Chianti - I like Italian & Spanish reds. I had a bottle of it left from Xmas - shows how often I open a bottle as I prefer beer & whiskey. I never usually open a bottle mid-week as it usually gives me a rotten headache the next day - not today I'm glad to say.
bleehhck...Quote:
Spanish reds
Now that I can agree with.Quote:
whiskey
Soma
I have read several rants against C++ in the past, by people I know nothing of, and ended in agreement. So, no, I don't find his distaste for C++ respectable because of who he is.
I do, however, think his opinion carries more weight than most others, because of who he is. How is this a bad thing?
Because he hates C++, that must mean he doesn't know how to use it?
I'm very comfortable with the OOP and polymorphic models of C++, but whenever I start using it too much, I realize just how much it sucks. This is probably in part due to the fact that I hold the opinion that OOP is overrated. But, in spite of C++'s monstrous warts, I do actually like the language; it's not my intention to flame it.
And?Quote:
I have read several rants against C++ in the past, by people I know nothing of, and ended in agreement.
No, really, do you have a point with this?
C++ has a lot of flaws. There are a lot of real reasons to choose a different language.
Certainly, if any other cleaner language offered me the same facilities without also getting in my path every step of the way I'd be using that language instead of C++.
You reading a rant against C++ with real and valid complaints by people using a modern compiler who actually know C++ well and finding that you agree is no issue.
You reading an insulting rant against C++ with very few real or valid complaints by a person which had a bad experience with an ancient compiler who clearly doesn't know C++ well and finding that you agree for no other reason than his position makes you look foolish.
Hitler. Pol Pot. Charlie Manson.Quote:
How is this a bad thing?
No. I'm not comparing Linus to these people. This is an issue of perception not person.
Allowing yourself to be influenced by a person and not by an argument is clearly extremely dangerous.
Here it is obviously not a big deal in the comparison, but the fact remains.
That's not what I intended, but I can see how you may have interpreted the statement that way.Quote:
Because he hates C++, that must mean he doesn't know how to use it?
That man clearly does not understand how to use many parts of C++ as evidenced by the complaints in his rants, refusal to revisit the language, but most crucially the fact that he has admitted he doesn't have but a few direct experiences with C++. You see, he hates C++ because of the way he was exposed to the language. I don't blame him for that. However, that fact also means he has steadfastly refused further exposure to the language. You'll have to forgive the mutated expression: he doesn't understand the language simply because he doesn't understand the language, and he doesn't understand the language because he doesn't want to understand the language.
So, he hates C++ because of his experience with it, and because of this experience has little actual knowledge of programming with it; do to the nature of these things, "The man rails against features he clearly doesn't understand how to use.".
Soma
Just read the next sentence I posted. I've agreed with unpopular people complaining about C++, and likewise can find Linus' agreeable. His popularity in this sense, is irrelevant. Your accusation is false, is what I'm saying.
He's an experienced and professional kernel programmer. When he says something about kernel programming, I listen. I'm surprised that distresses you so much.
Your statements suggest that my "accusation" is spot on.Quote:
Your accusation is false, is what I'm saying.
Okay.Quote:
When he says something about kernel programming, I listen.
Which of these statements have anything to do with kernel programming?
"I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to ........ off, so that he doesn't come and screw up any project I'm involved with."
"C++ leads to really really bad design choices."
"the whole C++ exception handling thing is fundamentally broken."
Oh, wait, none of those things have anything to do with kernel programming; those are sweeping generalizations that aren't even intended to be limited to kernel implementation.
So, for you to find those opinions respectable ("So,Really, I do like C++, but I still find his opinion of it to be respectable.") because he is a great kernel programmer is incredibly foolish.
[Edit]
To be clear, it is this steadfast "I listen." even when he is talking out of his ass about things he is admitted not knowing anything about that distresses me.
[/Edit]
Soma
I would think that since he said those things on a kernel mailing list (or other kernel focused environments), it's an understood thing that it does in fact have something to do with kernel programming.
He wants to annoy people who use a language he doesn't like, because he doesn't want them using it around him. Make sense.Quote:
"I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to ........ off, so that he doesn't come and screw up any project I'm involved with."
Introducing polymorphism into kernel primitives is just looking for trouble.Quote:
"C++ leads to really really bad design choices."
Kernel error handling is very tight, in part because it's the one generating most of them, and in part because it should only abort due to an error as a very last resort.Quote:
"the whole C++ exception handling thing is fundamentally broken."
Whereas the whole point of exceptions is to provide a very loose error handling mechanism.
Even if it was his intention to speak beyond kernel programming, I'm not going to suddenly disregard his opinion regarding kernel programming.
You forgot to show me that quote.
Personally, I'm guessing your adamant views against Linus' opinions are largely from your own ignorance to kernel development. I've never built a kernel, but I have studied kernels a lot, and just from what little I know, I can easily say that I would never use C++ for a kernel, even though I do like the language.
Are you basing this on that when you use C++ you suddenly have to start using polymorphism and exceptions? That's silly. C++ can also be seen as a "better C," with things such as stricter type system that allows for more bugs to be found at compile time.
Also, don't forget that there have been successful kernels built around C++. In fact, Symbian, while now old, was built with C++ and it was darn good in its day. Heck, it was even an operating system meant for mobiles that were nowhere near the beasts we have today.
I think you are being blinded, just as Linus is.
O_OQuote:
Introducing polymorphism into kernel primitives is just looking for trouble.
Quickly you must Hurry!
Report this immediately! You must tell Linus and the kernel crew this as soon as is possible!
Oh, no!
It is worse than I though, "POSIX" is plagued with bloody bastards!
O_o
Are you serious?
The "Linux" kernel, and in fact all modern kernels, are riddled with polymorphisms and other abstractions besides.
In fact, the "Linux" model of devices is one of the finest abstractions ever conceived.
Who asked you to?Quote:
Even if it was his intention to speak beyond kernel programming, I'm not going to suddenly disregard his opinion regarding kernel programming.
At what point has anyone in this thread said that Linus doesn't know what he is talking about with regards to kernel programming?
His classic "debate" with developers of other kernels is probably more instructive than entire books on the subject.
But his expertise in one field doesn't imply expertise in any other field.
You clearly do not know anything about the C++ exception mechanism.Quote:
Whereas the whole point of exceptions is to provide a very loose error handling mechanism.
I didn't forget.Quote:
You forgot to show me that quote.
Almost all of his points in every rant he has ever made about C++ are devoid of actual criticism, argument, or supporting rationale.
I'm spoiled for choice.
O_oQuote:
I've never built a kernel, but I have studied kernels a lot, and just from what little I know, I can easily say that I would never use C++ for a kernel, even though I do like the language.
I have built a kernel.
So, I must necessarily be right, right?
I wouldn't use C++ for a kernel either, but then, I wouldn't assume that a C++ programmer would ruin any project I worked on so the comparison isn't quite the same is it?
Soma
Actually, I sort of am. When someone says something is written in C++, I assume they took advantage of most of it's features, including said ones. If you take OOP, polymorphism, RAII, and exceptions away from C++, then you have nothing more than a slightly improved C. I don't think it would be fair to call a project written in said manner, a "C++ project".
But why would you take RAII away? That makes no sense.
EDIT: In fact, I don't even see the point in taking polymorphism away. If you have a need for runtime polymorphism, why not just use virtual methods and be done with it? What exactly is the advantage of coming up with some obscure function pointer table approach and basically reinventing what C++ gives you for free?
Perhaps, perhaps not (C++ consists of way more than that). But the fact still remains that you would be using C++ as the programming language.
Considering Yarin's latest posts, I'd assume at least polymorphism and exceptions are considered unsuitable by Yarin.
[QUOTE=Elysia;1114243Considering Yarin's latest posts, I'd assume at least polymorphism and exceptions are considered unsuitable by Yarin.[/QUOTE]
I can't imagine why. why would it be disadvantageous to have classes like SCSIHardDisc, derived from HardDisc, derived from BlockDevice, derived from StorageDevice, etc? it seems very straightforward to me, not to mention readable and maintainable.
Said abstractions can very easily be implemented in C without using the OOP features provided by C++.
Yes, you're technically right (but not necessarily so), but I've been talking in practical terms.
Those provided by C++, for kernel development, I would say that's right.
Mmm. I've successfully built and run a "hello world" kernel, that admittedly had more code that wasn't mine that was. I don't think that really counts. The kernel you've built, is it an actual, somewhat functional kernel? (Note: If you have, I would actually like to see what you came up with)Quote:
Originally Posted by Soma
Yes, but (obviously) not in the language itself. Design polymorphism and language polymorphism isn't the same thing.Quote:
Originally Posted by Soma
Please, educate me.Quote:
Originally Posted by Soma
Isn't that the point we're debating? You're just repeating yourself.Quote:
Originally Posted by Soma
Sticking your head in the sand and pretending that Linus knows what he is talking about with respect to C++ is apparently more draining on the intellect than I thought.Quote:
Said abstractions can very easily be implemented in C without using the OOP features provided by C++.
Such abstractions can't be implemented in any language in the family without using the "OOP" features provided by C++. The only difference is how much the C++ compiler does versus how much the programmer must code.
Make no mistake, the polymorphisms and other abstractions that make the foundation of the "Linux" kernel is built on the same concepts a C++ compiler uses to provide those facilities. There is no magic here.
"It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it."Quote:
Isn't that the point we're debating?
Is a statement containing no actual criticisms of C++ (There are plenty of real complaints about C++ to consider.), no valid argument (If a statement of prejudice was a valid argument the world would be a terrible place.), and no supporting rationale (There can be no supporting rationale for this because it is such a mindbogglingly stupid sweeping generalization.).
There is no debate.
You are just a silly fan with a foolish mentality.
Soma
Tell me how to implement classes in C without wasting lots of memory and execution time with function pointers.
I would be very interested.
Mmm. So describe to me how you would implement these features in C, in such a way that they would be better than the code generated by a C++ compiler.Quote:
Those provided by C++, for kernel development, I would say that's right.
Well, I can see why exceptions might not be something you want in a kernel, but I cannot for the life of me find anything wrong with built-in runtime polymorphism.
I'm starting to think that there is a serious fundamental misunderstanding, in a lot of minds, about the way C++ works. after compilation, it's all just machine code. equivalent programs in both C and C++ will produce equivalent machine code. both will likely perform and function identically, within a certain tolerance, assuming they were both built with compilers from the same vendor (gcc/g++, etc). the only difference is in the interface that the programmer sees. I really don't understand why people think that C++ is some bloated, inefficient language.
one of the guiding principles of C++'s implementation is the concept there should be no penalty for an optional feature that you don't use. so even if you think that C++ exceptions are bad to use in a kernel, then just don't use them. if you don't have code that throws exceptions, you'll never need to catch them, and therefore there's no overhead. and if you're really anal about it, most compilers have an option to disable features like RTTI and exceptions.
C++ offers many features of value to kernel programmers, even if you throw out polymorphism, object orientation, and exception handling. strict type safety is a huge benefit of using C++, and should be enough just by itself to justify the use of the language.
I find it hard to believe that it's as simple as that. Of course I may be wrong, the Linux kernel is much bigger than it ought to be. You'll have to show me one of these commonplace instances you speak of.
I wouldn't agree with this statement. But then, it wasn't included in the post that I said I found respectable, either. You act as if though I take everything Linus says as gold.
That makes me feel like I'm talking to the wind... ?
Now you're just resorting to insults. That doesn't help your argument any.
Maybe you're missing my point. I'm not suggesting that one implement C++ features for use in C, but rather implement less generic, more specialized solutions for the kernel. Remember, when developing a kernel, there's hardly a such thing as premature optimization.
But who says you can't implement these specialized solutions using C++?
If you want to object-orient your kernel code, or embrace abstractions and encapsulation, how is it that C can do it, but not C++?
There is always premature optimization, in kernels above all due to their incredible overall complexity.Quote:
Remember, when developing a kernel, there's hardly a such thing as premature optimization.
If one wants their kernel to run according to their envisioned C++ paradigm, then of course they should code it in C++.
I think though, that the kernel should run closer to the bare metal than literally any other software in the OS, including drivers. And to best do that, one should avoid the C++ mindset. Embedded devices and kernels are where C shines the brightest, I think, for the very bare bones qualities that you ridicule.
I really don't think so. Literally the whole system relies on it, and I imagine it's routines are traversed way more than any other in a normal computing session. You'd want it to be fast.
agreed. all of the most common compilers are made to know how to optimize for a given processor, and they do a very impressive job of it. trying to circumvent that is just wasting the compiler's time and yours. that being said, if, after profiling a block of code, you find an area that could be optimized better, because certain assumptions can be made that the compiler cannot make, then it may be appropriate to fine tune it with some inline assembly or some other type of optimization. only after profiling compiler-generated machine code reveals a bottleneck should you consider hand optimization.
how is C++ any further from the bare metal than C? C++ is (essentially) a superset of C, in the context that we're talking about, and given a block of pure C code, both a C and a C++ compiler will generate nearly identical results. your argument holds absolutely no water.
Imagine how I feel; you've been asked several times for anything that supports your view and you've posted nothing beyond "I think", "I feel", and "Linus says".Quote:
That makes me feel like I'm talking to the wind... ?
*shrug*
Still, troll slaying is best left to "Orcs Must Die"...
Soma
Oh, but this isn't about the C++ mindset. Obviously going awry with OOP design with heavy reliance on virtual functions and temporary objects is going to hurt performance. No, I agree with you that one has to be careful inside a kernel.
However, we are trying to convey the message of C++ as the language. C++ is a better C in many ways. As long as one is aware that one is working with hardware, one can use any language suited to the task.
Heard of Microsoft's little research project Singularity? It's not written in C. And yet, it works, and it works well, I'd probably say. For a research OS anyway.
The point is that you must separate the mindset from the language. Separate design from language. Just because you use C++ doesn't mean you have to use OOP, exceptions, polymorphism, etc.
You can just use, say, templates and the better type system. What you need, or should, use depends on the requirements of the project. Naturally you also base the choice of language around this.
But that doesn't mean you have to squeeze every little imaginable piece of speed out of it. Many functions are rarely called.Quote:
I really don't think so. Literally the whole system relies on it, and I imagine it's routines are traversed way more than any other in a normal computing session. You'd want it to be fast.
The principle of avoiding premature optimization is a good one, even in kernels.
First you build your system so that it works. Then you start profiling it. Then you start optimizing.
Heh, I have given reasons, including asking for examples contrary to what I'm saying, and you've failed to produce as well. So you're argument is the pot calling the kettle back.
End point: C++ is a higher level paradigm language than C, by enough that makes it less suitable for kernel development than C. I don't know if I can make it any more succinct than that.
If you code C++ like it's C, then of course it will, and then what's the point of using C++ in the first place? The debate of C++ vs C for the kernel, is assuming both languages are used normally, so your point is off track.