Like Tree27Likes

interview with Linus

This is a discussion on interview with Linus within the General Discussions forums, part of the Community Boards category; Originally Posted by Elysia Are you basing this on that when you use C++ you suddenly have to start using ...

  1. #61
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,670
    Quote Originally Posted by Elysia View Post
    Are you basing this on that when you use C++ you suddenly have to start using polymorphism and exceptions?
    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".
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  2. #62
    Registered User antred's Avatar
    Join Date
    Apr 2012
    Location
    Germany
    Posts
    255
    Quote Originally Posted by Yarin View Post
    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.
    But why? What is it about C++ that makes it unsuitable for kernel development? And also, I've already asked you this two pages ago, in what way is exception handling broken in C++?

  3. #63
    Registered User antred's Avatar
    Join Date
    Apr 2012
    Location
    Germany
    Posts
    255
    Quote Originally Posted by Yarin View Post
    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?
    Last edited by antred; 07-04-2012 at 03:13 PM.

  4. #64
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,823
    Quote Originally Posted by Yarin View Post
    ...I don't think it would be fair to call a project written in said manner, a "C++ project".
    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.

    Quote Originally Posted by antred View Post
    But why? What is it about C++ that makes it unsuitable for kernel development? And also, I've already asked you this two pages ago, in what way is exception handling broken in C++?
    Considering Yarin's latest posts, I'd assume at least polymorphism and exceptions are considered unsuitable by Yarin.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #65
    Registered User
    Join Date
    Oct 2006
    Posts
    2,511
    [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.

  6. #66
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,670
    Quote Originally Posted by Elkvis View Post
    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?
    Said abstractions can very easily be implemented in C without using the OOP features provided by C++.
    Quote Originally Posted by Elysia View Post
    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.
    Yes, you're technically right (but not necessarily so), but I've been talking in practical terms.

    Quote Originally Posted by Elysia View Post
    Considering Yarin's latest posts, I'd assume at least polymorphism and exceptions are considered unsuitable by Yarin.
    Those provided by C++, for kernel development, I would say that's right.

    Quote Originally Posted by Soma
    I have built a kernel.
    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
    The "Linux" kernel, and in fact all modern kernels, are riddled with polymorphisms and other abstractions besides.
    Yes, but (obviously) not in the language itself. Design polymorphism and language polymorphism isn't the same thing.

    Quote Originally Posted by Soma
    You clearly do not know anything about the C++ exception mechanism.
    Please, educate me.

    Quote Originally Posted by Soma
    Almost all of his points in every rant he has ever made about C++ are devoid of actual criticism, argument, or supporting rationale.
    Isn't that the point we're debating? You're just repeating yourself.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  7. #67
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,344
    Said abstractions can very easily be implemented in C without using the OOP features provided by C++.
    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.

    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.

    Isn't that the point we're debating?
    "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."

    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
    Last edited by phantomotap; 07-05-2012 at 03:31 AM.
    antred likes this.

  8. #68
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,823
    Quote Originally Posted by Yarin View Post
    Said abstractions can very easily be implemented in C without using the OOP features provided by C++.
    Tell me how to implement classes in C without wasting lots of memory and execution time with function pointers.
    I would be very interested.

    Those provided by C++, for kernel development, I would say that's right.
    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 Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #69
    Registered User antred's Avatar
    Join Date
    Apr 2012
    Location
    Germany
    Posts
    255
    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.

  10. #70
    Registered User
    Join Date
    Oct 2006
    Posts
    2,511
    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.
    antred likes this.

  11. #71
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,670
    Quote Originally Posted by phantomotap View Post
    The only difference is how much the C++ compiler does versus how much the programmer must code.
    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.

    Quote Originally Posted by phantomotap View Post
    "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."
    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.

    Quote Originally Posted by phantomotap View Post
    There is no debate.
    That makes me feel like I'm talking to the wind... ?
    Quote Originally Posted by phantomotap View Post
    You are just a silly fan with a foolish mentality.
    Now you're just resorting to insults. That doesn't help your argument any.

    Quote Originally Posted by Elysia View Post
    Tell me how to implement classes in C without wasting lots of memory and execution time with function pointers.
    Quote Originally Posted by Elysia View Post
    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.
    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.
    manasij7479 likes this.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  12. #72
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,670
    Quote Originally Posted by Elkvis View Post
    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.
    [ ^ ]
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  13. #73
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,823
    Quote Originally Posted by Yarin View Post
    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.
    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++?

    Remember, when developing a kernel, there's hardly a such thing as premature optimization.
    There is always premature optimization, in kernels above all due to their incredible overall complexity.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #74
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,670
    Quote Originally Posted by Elysia View Post
    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++?
    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.

    Quote Originally Posted by Elysia View Post
    There is always premature optimization, in kernels above all due to their incredible overall complexity.
    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.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  15. #75
    Registered User
    Join Date
    Oct 2006
    Posts
    2,511
    Quote Originally Posted by Elysia View Post
    There is always premature optimization, in kernels above all due to their incredible overall complexity.
    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.

Page 5 of 6 FirstFirst 123456 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. linus c client program
    By bazdagirl in forum Linux Programming
    Replies: 1
    Last Post: 01-21-2011, 11:22 AM
  2. Basic Linus Shell
    By Josh_Dude83 in forum C Programming
    Replies: 11
    Last Post: 09-19-2010, 07:43 PM
  3. Interview???
    By verbity in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 08-09-2007, 07:47 AM
  4. linus svm
    By axon in forum Tech Board
    Replies: 2
    Last Post: 01-16-2004, 06:38 PM
  5. Linus VS. Bill
    By Yoshi in forum A Brief History of Cprogramming.com
    Replies: 31
    Last Post: 12-25-2001, 08:28 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21