Forgot your password?
typodupeerror
Programming Operating Systems Software Technology Linux

C++ In The Linux kernel 850

Posted by timothy
from the kitchen-sink-and-jacuzzi dept.
An anonymous reader submits "A researcher at Reykjavik University Network Laboratory (netlab.ru.is) has just released a Linux patch allowing for complete kernel-level run-time support for C++ in the Linux kernel, including exceptions, dynamic type checking and global objects (with constructors and destructors) The implementation is based on the C++ ABI in GNU g++, but contains various kernel level optimizations, that reduces the cost of throwing exceptions by an order of magnitude, thus making C++ exceptions viable in several scenarios. Furthermore, the Linux module loader is extended to handle weak symbols in C++, so that dynamic type checking is reduced to a pointer comparison, in contrast to string comparison."
This discussion has been archived. No new comments can be posted.

C++ In The Linux kernel

Comments Filter:
  • nice (Score:5, Funny)

    by Anonymous Coward on Wednesday October 27, 2004 @04:48PM (#10647303)
    how long until c# is supported?
    • Who cares? (Score:3, Funny)

      by Anonymous Coward
      My VB kernel works just fine for me.
  • by OverlordQ (264228) * on Wednesday October 27, 2004 @04:49PM (#10647309) Journal
    So what will we say the kernel is written in . . C? C+? CKernelRun?
    • by M51DPS (757403) on Wednesday October 27, 2004 @05:03PM (#10647465)
      The kernel will be written in Java for more cross-platform compatibility.
      • by frostfreek (647009) on Wednesday October 27, 2004 @10:48PM (#10650048)
        And why not???

        With the GNU Compiler Collection able to generate machine code for Java, we'd be able to leverage all the things that Java excells at!
        Such as:



        umm....


        well,
        Oh forget it then.

    • by Tumbleweed (3706) * on Wednesday October 27, 2004 @05:06PM (#10647509)
      CKernelRun?

      a) CKernelCrash
      b) CKernelPatchNotGetAcceptedByLinus

      One or the other, I'm sure.
  • C++? (Score:5, Funny)

    by Anonymous Coward on Wednesday October 27, 2004 @04:49PM (#10647315)
    Good now I can fire up my good old visual basic and hack the kernal with COM.
    • Re:C++? (Score:3, Funny)

      by npietraniec (519210)
      and I was just thinking... I wonder how long until someone makes a "I want to use visual basic" comment. That didn't take long. hilarious.
      • Re:C++? (Score:3, Funny)

        by Kethinov (636034)
        Imagine the enormity of newbie kernel hackers if such a thing were beieved to be possible...

        I can imagine a post to usenet now...

        Subject: this damn thing wont compile

        omg why are none of my win32 api calls working this sucks this will never be better than windows

        And the ensuing reply...

        Subject: Re: this damn thing won't compile

        Uh huh. Well. It won't compile because your api calls are, uhm, frozen. Yeah. You need to unfreeze them. There should be a blue liquid in the trunk of your car called antifreeze.

  • Alright!! (Score:5, Funny)

    by 21chrisp (757902) on Wednesday October 27, 2004 @04:50PM (#10647326)

    I'm sure the kernel developers will LOVE the idea of putting C++ in the kernel.
    • Re:Alright!! (Score:5, Insightful)

      by Bloater (12932) on Wednesday October 27, 2004 @06:10PM (#10648125) Homepage Journal
      Why ever not? C++ allows for much better code, you just need a compiler that's up to the task, and runtime ABI that is predictable. Granted, standard C++ may not be appropriate, but with some features disallowed, it is ideal (better than C).

      All you need is policy that covers use of various features, just like the Linux kernel requires policy on use of C.

      multiple platform support becomes template specialisation, locking rules can actually be enforced by the language (ie, to get member functions to access an object, you can require that you call a member function to return a mutex object which has the members, and when that mutex is destroyed naturally, the lock is freed. fast, safe, secure.

      The question is how customisable is the compiler for how virtual functions, etc, are implemented. Those are the only issues to be concerned about because C++ is plain better than C.
      • by metalogic (445469) on Wednesday October 27, 2004 @07:16PM (#10648717)
        I see your ID isn't a coincidence.
        • Re:Alright!! (Score:5, Informative)

          by Bloater (12932) on Wednesday October 27, 2004 @08:46PM (#10649311) Homepage Journal
          I think that deserved +1 Funny.

          Although the idea that C++ compiled object code is bloated is incorrect. It's normally either due to inexperience with the language or due to a poor compiler implementation. Part of the problem is that on old compilers, template instatiations were actually included once for every object file that refered to one. More recent compilers can identify and remove duplicates at link time, or can save templates in a separate file and link it in at the end of the build. (For some templates, though, you can actually be better off with one in each file if each file uses inline member functions, and each uses a different one).

          Sure C++ has it's faults, but bloatedness is not one of them - although a standard library may be bloated, but that's not an issue for the kernel.
  • Yay! (Score:3, Insightful)

    by stonecypher (118140) * <stonecypherNO@SPAMgmail.com> on Wednesday October 27, 2004 @04:51PM (#10647337) Homepage Journal
    It's about fucking time. Now maybe we're on the path to a bullet for killing those shallow arguments about C++ somehow being majorly slower than C, as opposed to people just not knowing the costs of C++ features.
    • Re:Yay! (Score:5, Informative)

      by apankrat (314147) on Wednesday October 27, 2004 @05:09PM (#10647532) Homepage
      It's not the slowliness, it's the obscuirty and the lack of control over the binary code size it introduces. Something as simple as 'a == b' may easily add few KB to the kernel.

      If you think it's OK, you obviously haven't been involved in kernel or embedded development. If you say one should be careful what features of C++ he uses and not to use this and that, I say one should learn proper C skills instead.

      • Re:Yay! (Score:5, Insightful)

        by Lally Singh (3427) on Wednesday October 27, 2004 @05:18PM (#10647621) Journal
        Embedded dev is now often C++ based. It's all about making sure you have devs who have a clue.

        Anyone writing a == b should notice that a & b aren't primitive types.
        • Re:Yay! (Score:3, Insightful)

          by SpaceLifeForm (228190)
          It doesn't matter if the developers have a clue. Linus has repeatedly said no.

          Go fork your own kernel then. Good luck.

          • Re:Yay! (Score:5, Insightful)

            by bobv-pillars-net (97943) <bobvin@pillars.net> on Wednesday October 27, 2004 @11:23PM (#10650247) Homepage Journal
            Go fork your own kernel then. Good luck.

            Unless I misunderstood when I RTFA, that is exactly what the authors intend to do. And I, too, would like to wish them "Good luck." Linus obviously believes that C++ in the kernel is undesirable, but we'll never find out for sure until somebody like these people have the guts to actually try it, and the persistence to maintain a current patchset (or fork) long enough for the idea to catch on.

        • Re:Yay! (Score:3, Funny)

          by apankrat (314147)
          Assuming you are looking at integer_t type, is it primitive ?
          Made you look in header :-p

          Agreed about developers though, however the number of
          those who have a clue is drastically lower than those
          who think they have a clue. Everyone's a freaking C++
          senior these days.

        • by amightywind (691887) on Wednesday October 27, 2004 @06:22PM (#10648236) Journal

          Embedded dev is now often C++ based.

          Too bad too. I am developing FAA Level A avionics software using C++, I am sorry to say. What a debocle. For starters, the compilers for non-gcc supported platforms uniformly suck. Typical compilers for DSP's lag the C++ standard by 10 years, and crash frequently. And my project is proof that if a language feature exists it will be used, no matter how pointless. For example:

          /* Rational person sets a control register in C */
          *SOMEREG_ptr = BIT_A | BIT_B;

          or

          // C++, is this really better?
          Register_set<std::uint16_t> regset(base_address);
          regset.write(SOMEREG_OFFSET , Register_set<>::BIT_A | Register_set<>::BIT_B);

          Gross. Please keep C++ out of the Linux kernel!

          • by Chemisor (97276) on Wednesday October 27, 2004 @06:48PM (#10648481)
            > // C++, is this really better?
            > Register_set regset(base_address);
            > regset.write(SOMEREG_OFFSET , Register_set::BIT_A | Register_set::BIT_B);

            Only a complete novice would write code like this. Your code setting *SOMEREG_ptr = BIT_A | BIT_B will work just fine in C++ too. In fact, you could transparently support multiple types of registers by overloading operator= of SOMEREG_ptr, which could be a polymorphic class. And if you think that is going to bloat your code, you obviously have never looked at the output of a good compiler like gcc. A good C++ design is FAR more readable than any C hack you can come up with.

            > Typical compilers for DSP's lag the C++ standard by 10 years

            That is the problem of your compiler, not the language. Stop bashing C++ when you should be blaming your vendor for not being able to write a decent compiler, or even port gcc to their platform.
      • Re:Yay! (Score:4, Insightful)

        by Frizzle Fry (149026) on Wednesday October 27, 2004 @05:46PM (#10647889) Homepage
        Something as simple as 'a == b' may easily add few KB to the kernel.

        Only if you've overloaded operator==. But in that case, this is just a function call. A function call in C could just as easily add a few KB. The only difference between the languages here is that C++ gives you the "syntactic sugar" option of creating functions with the same names as operators. You can choose not to do that if you perfer and just use a regular function name, as in C. In no way does the ability to create a function named "==" instead of "Equals" show any more "lack of control" over code size than in C (exceptions might have been a better example).
      • Re:Yay! (Score:5, Informative)

        by myg (705374) on Wednesday October 27, 2004 @06:06PM (#10648090)
        I'm an embedded developer. I've done some projects as C only and some as C++. With proper discipline C++ can actually generate smaller, more compact code than straight C. But getting the infrastructure done is a bit harder.

        In fact, eCos, a very nice (GPL) embedded operating system has its kernel written in C++. eCos performs well and is cleaner than a competing straight C RTOS which has to build its object system by hand (VxWorks' WIND kernel).

        The real difficulty in using C++ for embedded development comes from the toolchains themselvs. Frequently new processor architectures don't have very functional C++ back ends but C is somewhat stable.

        In fact, I worked on porting some C++ TV middleware to a specialized "media DSP processor." The GCC back-end for C was rock solid but C++ constructs would give me constant ICEs.

        C++ does fix some dumb things in C, but when it comes to shooting yourself in the foot, C++ is like an AK-47 while C is more like a .38 special.
        • Re:Yay! (Score:3, Funny)

          by Martin Blank (154261)
          C++ does fix some dumb things in C, but when it comes to shooting yourself in the foot, C++ is like an AK-47 while C is more like a .38 special.

          This should be good news to the NRA's development division...
  • by apankrat (314147) on Wednesday October 27, 2004 @04:52PM (#10647355) Homepage
    Java on other hand ...

    Or better yet - Brainf*ck, my personal favourite :)
  • Great news, I hop (Score:4, Interesting)

    by Anonymous Coward on Wednesday October 27, 2004 @04:53PM (#10647371)
    That's really awesome news, but I just can't imagine it being accepted in the mainline branch. Many figureheads in the linux kernel group are anti-C++ enough to probably veto this effort. (If "anti" is too strong, then at least I'll safely claim they're not "pro C++".)

    It'd sure be nice though...
  • RMS (Score:5, Funny)

    by zoeith (785087) on Wednesday October 27, 2004 @04:54PM (#10647381) Homepage Journal
    RMS is probably turning over in his grave... oH! wait he's not dead!
  • Progress (Score:5, Interesting)

    by caseih (160668) on Wednesday October 27, 2004 @04:54PM (#10647384)
    Say what you will about C++ being slower and more bloated than C, but I think this is a huge leap forward. I doubt Linus will accept it anytime soon as an official patch, though. If they have succeeded in making exceptions quick, I think C++ has a real place in the kernel. C++ offers the ability to have better type safety and more modular apis and interfaces to the kernel. For example being able to develop a new device driver inheriting from a nice base class is a good idea.

    Anyway, this is a neat hack and I look forward to seeing what comes of it.
    • Re:Progress (Score:4, Informative)

      by alienw (585907) <alienw.slashdot@gm a i l . c om> on Wednesday October 27, 2004 @05:05PM (#10647488)
      Nothing will come out of it, for the simple reason that C++ does not belong in any kernel. In a kernel, all the code needs to be transparent, and you definitely don't want to hide implementation and the usual abstractions.

      The simple reason for that is that otherwise the kernel would be unpredictable. Let's say the error logging function used the string class (which likes to allocate memory behind your back). If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash. This is why the kernel is significantly more difficult to program than, say, a word processor.
      • Re:Progress (Score:5, Insightful)

        by fitten (521191) on Wednesday October 27, 2004 @05:14PM (#10647585)
        In a kernel, all the code needs to be transparent, and you definitely don't want to hide implementation and the usual abstractions.

        Yeah, who wants a common driver API for video, network, or sound cards...

        Not to mention that drivers are all about abstracting the hardware and interface implementation from the OS itself anyway...

        The simple reason for that is that otherwise the kernel would be unpredictable. Let's say the error logging function used the string class (which likes to allocate memory behind your back). If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash. This is why the kernel is significantly more difficult to program than, say, a word processor.

        Yes, a kernel is more difficult than a word processor, but that doesn't mean that implementors must implement stupid C++ code. You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.
        • Re:Progress (Score:3, Informative)

          by 12357bd (686909)

          Yes, a kernel is more difficult than a word processor, but that doesn't mean that implementors must implement stupid C++ code.

          No, the problem is not if it's difficult or not, is the fact that C++ implies the existence of an intrinsic memory management behaviour (new/delete), that is not really compatible with the strict memory management a kernel must implement.

      • Re:Progress (Score:5, Insightful)

        by IceAgeComing (636874) on Wednesday October 27, 2004 @05:27PM (#10647691)
        In a kernel, all the code needs to be transparent,

        That got a chuckle from me. I know what you meant, but after looking at the following (randomly chosen :) block from the device driver grip.c, I wonder just how "transparent" it is:

        if ((((u ^ v) & (v ^ w)) >> 1) & ~(u | v | w) & 1) {
        if (i == 20) {
        crc = buf ^ (buf >> 7) ^ (buf >> 14);
        if (!((crc ^ (0x25cb9e70 >> ((crc >> 2) & 0x1c))) & 0xf)) {
        data[buf >> 18] = buf >> 4;
        status |= 1 > 18);
        }


        The simple reason for that is that otherwise the kernel would be unpredictable.


        Point taken, but I hope you're open to the idea that C++ classes can be written that avoid these problems. In particular, it's relatively easy to define your own memory management scheme. This could be confusing to some (redefinition of new and delete would not be obvious in other parts of the code), but C++ has some nice features that facilitate scalability. I'm sure you'll agree that maintaining such a complicated thing as a cross-platform kernel can use some more sophisticated tools for software development than what C provides.
      • Re:Progress (Score:5, Insightful)

        by geg81 (816215) on Wednesday October 27, 2004 @06:21PM (#10648225)
        The simple reason for that is that otherwise the kernel would be unpredictable.

        Complex code becomes predictable by building layered abstractions with well-defined interfaces. C++ supports that better than C.

        Let's say the error logging function used the string class (which likes to allocate memory behind your back).

        The kernel almost certainly wouldn't be using "the" string class, but its own string class, adapted specifically to the needs of the kernel. Right now, the C-based kernel doesn't use the user mode C library either, after all.

        If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash.

        Quite to the contrary. Not only would the kernel not crash, with a properly designed string class, out of memory conditions would actually be guaranteed to be handled correctly in all string operations everywhere in the kernel. No more case-by-case checking and handling of whether the memory allocation happened to succeed this time or not. In this particular case, the string class would throw an out-of-memory exception in the error handler and the stack would unwind up to the point where there is a handler.

        Furthermore, the error logging function can decide to intercept such exceptions and print an emergency error message on the console, and it can do so reliably without ever having to worry about checking a single status or return value.

        Altogether, this is a big improvement over C-based handling of such situations. But if you want to keep this situation from occurring in the first place, there is no more reason for the error logging function to allocate memory in C++ than there is for it to do so in C.
    • Re:Progress (Score:3, Insightful)

      by Salamander (33735)

      It's not so much that C++ itself is so bloated etc. but that some of the common C++ programming idioms - full of templates, overloading, deeply nested class hierarchies with virtual methods, etc. - can lead to bloat. It's never good to have what looks like a simple assignment statement turn into thousands or even tens of thousands of instructions, but it's particularly dangerous in the kernel. Templates are particularly bad because they get re-instantiated for every type they're used with and that can ver

  • by RAMMS+EIN (578166) on Wednesday October 27, 2004 @04:55PM (#10647392) Homepage Journal
    Linux doesn't want any C++, so as long as he's at the top, it likely won't get far. And I think that's good, given the state of C++ in gcc (hint: slow and memory-intensive compiles, generating subobtimal code).

    But I'll shut up. I've pretty much turned my back on C and C++ anyway.
  • Who cares? (Score:5, Informative)

    by Percy_Blakeney (542178) on Wednesday October 27, 2004 @04:57PM (#10647407) Homepage
    I really don't see the use in porting these features to the Linux kernel -- they'll never be used in any mainstream kernel release. Linus has stated many times that he doesn't particularly care for C++ in the kernel [tux.org]:

    In fact, in Linux we did try C++ once already, back in 1992.

    It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

    The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

    * the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
    * any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
    * you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

    In general, I'd say that anybody who designs his kernel modules for C++ is either

    * (a) looking for problems
    * (b) a C++ bigot that can't see what he is writing is really just C anyway
    * (c) was given an assignment in CS class to do so.

    Feel free to make up (d).

    • Re:Who cares? (Score:3, Interesting)

      by Kethinov (636034)
      I agree entirely. C++ in the Linux kernel is a largely bad idea.

      I am all for the kernel remaining C forever, but just for the sake of curiosity's fancies, I wonder how much better Objective-C would be as a high level yet still high performance solution as opposed to the messier C++?
    • Anyone who claims with a straight face in 2004 that "C++ compilers are untrustworthy" is trolling. Sorry, rabid penguin lovers.

      I love it when language bigots forestall any reasonable discussion by preemptively accusing anyone who disagrees with them of being a language bigot. Slashdot, of course, believe that Linus can do no wrong, so none of it ever applies to him...

      After having conversations with him myself, I can state my honest belief that Linus doesn't understand how to use C++, and will simply

    • Re:Who cares? (Score:5, Insightful)

      by slashdot.org (321932) on Wednesday October 27, 2004 @06:03PM (#10648058) Homepage Journal
      Boy oh boy, where do we start.

      Please people, I know Linus is God, and I have a lot of respect for the man. But I don't care who it is, if people make statements like this, I'd like to see some back up.

      It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

      When someone says 'trust me' it either means "I'm too lazy to explain" or "I haven't really got something to prove it".

      The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

      Well, I don't want to start a flamewar here, but while this may be true for the GNU compiler, it certainly is NOT true for, for example, the Microsoft compiler. (I know, how dare I say that...) It has produced code from C++ source for a _very_ long time and even the optimizer works very well.

      * the whole C++ exception handling thing is fundamentally broken.

      Why?

      It's _especially_ broken for kernels.

      Why? Maybe for the Linux kernel, because it wasn't designed with C++ exceptions in mind. And I'm not even say that that's bad, but why is it in gerenal broken for kernels?

      * any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.

      Well, that's really implementation and as such is your choice, it's not the language. Furthermore, no-one forces you to use _all_ possible language features. I personally stay away from many C++ language features such as overloaded operators.

      * you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

      But why would you if you can do it cleaner in C++ and have the compiler generate the same quality code? What is crap about C++?

      What Linus needs to do is go back to the old days where he looked at assembly output. I still do that and have compared C++ with C many times and I can't see why anyone would not use C++.

      You don't have to use all the bells and whistles, shit, you can write plain ANSI-C and still use a C++ compiler for it's superior type checking etc.

      Anyways, to each his own, I guess...
    • My pet peve: the gaping hole in the standard regarding the use of virtual functions from constructors and destructors and routines that serve them.

      If a member object's constructor, or a routine it calls, somehow gets hold of a pointer to the containing object and calls a virtual function, IMHO it should be performing a legal operation and should get the BASE CLASS version of the function. Ditto in the destructor. (At this stage of construction the base class is fully functional, while the derived class is
  • by Anonymous Coward on Wednesday October 27, 2004 @05:00PM (#10647432)
    what an incredibly awesome idea!!!

    i can't wait to try and debug virtual functions, copy constructors, and polymorphism over JTAG or BDM!!!!

    man thats gonna be fun ... my hats definitely off to this academic you have definitely spent your time wisely!!!!

    i always found C causes to much clutter in the linux kernel ... a real language will do us all good ...

    keep an eye for this in 3.0 ...

    Jim
  • C++ (Score:5, Interesting)

    by bsd4me (759597) on Wednesday October 27, 2004 @05:02PM (#10647455)

    I'm not sure if many people remember, but there was a short time when the kernel source was compiled with g++, even though the source was plain C.

    IIRC (memeory very hazy, though), it lasted about a month in 1992 or 1993, and it had something to do with type-safe linking(?).

    • Re:C++ (Score:3, Funny)

      by Lally Singh (3427)
      C++ wasn't standardized until 1998. Should I talk trash about C99 by referring to the original K&R version?
  • by Le Marteau (206396) on Wednesday October 27, 2004 @05:02PM (#10647458) Journal
    Support, within the kernel, for IE^H^HMozilla! It'll be perfectly safe! Trust us!
  • by Monkius (3888) on Wednesday October 27, 2004 @05:03PM (#10647468) Homepage
    Kernel aside, I wonder if G++ developers out there have any comments on these guys' exception-handling changes?

    Would they be applicable to the user-space runtime?
  • by cout (4249) <curlypaul924@gmail. c o m> on Wednesday October 27, 2004 @05:05PM (#10647487) Homepage
    Any kernel project that uses C++ is most likely doomed to be an experimental project and will most likely never be included in the kernel. IMO, there's good reason for that, too. The added complexity just doesn't outweigh the benefits of using C++ over C.

    In fact, there was a good post on kerneltrap not to long ago about C++ inside the linux kernel:

    http://kerneltrap.org/node/view/2067

    Worth a read if you've got a few minutes to burn.
  • by kompiluj (677438) on Wednesday October 27, 2004 @05:16PM (#10647595)
    C++ was designed to be the language of choice for modern operating systems, meant to replace C. This is main reason why every decision was made with efficiency in mind (no automatic virtual functions, no garbage collection, and, oh yes!, the infamous: pointers and goto). And of course C++ is fast. Maybe it loses by hair's breadth with C but surely wins with Java by great margin. And don't tell me about JIT, do some homework.
    I think trying to incorporate C++ into Linux kernel is a good decision, giving more vitality to Linux and allowing it to differentiate better from the traditional UNIX systems - but that's only my 0.02 Euro.
  • by master_p (608214) on Wednesday October 27, 2004 @05:19PM (#10647628)
    The article says that they managed to support C++ in the kernel. Well, that's sweet as an accomplishment. But what are the benefits? many parts of the kernel are already object-oriented, in the form of manually written vtable structs and object structs that have pointers to those vtables. I just don't see a reason for C++ in the kernel. Maybe someone that knows more on this can enlighten us.
  • by TheKubrix (585297) on Wednesday October 27, 2004 @05:25PM (#10647676) Homepage
    Or at least drive him (more?) insane! [gnu.org]
  • by ari_j (90255) on Wednesday October 27, 2004 @05:27PM (#10647690)
    The good news is that we have a new renewable power source. What you do is wrap Linux in wires and place him in a magnetic casket. Putting C++ in the kernel will cause him to roll fast enough to generate enough electricity to power North America.
  • Oh god, WHY? (Score:3, Interesting)

    by melted (227442) on Wednesday October 27, 2004 @05:29PM (#10647701) Homepage
    Haven't they read "Exceptional C++"? C++ is a fucking disaster. It kind of constantly conspires against you to shoot you in the foot in some kind of massive manner where you'd least expect. Sure, non-exception enabled code is ugly (check the return values all the time, etc), but any non-trivial exception-enabled code is nearly impossible to write if the requirement is that it works correctly in all situations (which is what the requirement is for the kernel).

    Don't get me wrong, C++ is an OK language, but I'd think twice before using its exceptions.
  • C++ in the kernel? (Score:4, Insightful)

    by OverflowingBitBucket (464177) on Wednesday October 27, 2004 @05:36PM (#10647761) Homepage Journal
    Now I'm a big fan of C++ and all, being both my language of choice and my favoured (or at least, least detested) language. However, there is the matter of using the right tool for the right job. When I need a quick, disposable tool, I don't fire up a new C++ file and work it into my project. I slap together something in ruby, and use that. Now, C++ in the Linux kernel?

    The value of an OO language in larger projects is enormous. Basically there are simply too many things that could go wrong at any point, and the overhead associated with C++ (memory use, exception setup, excess copying, dynamic checking) is a small price to pay for the additional benefits it provides. As you get closer to the metal though, and you have to watch what you are doing more closely. You want to know exactly when memory is being allocated, when something may go wrong, and only want to set up to catch exceptional circumstances if you know they may occur. Resources in kernel-land are expensive. C allows this kind of control, C++ does not.

    My former boss would love to see me defending C over C++ like this. The irony.

    Having said that, the capability to run C++ code in the kernel would certainly be nice, provided it didn't impact the existing code. I'm not sure how this one could be pulled off though. There'd be too much code that would need to be made aware of exceptions, destructors, so forth.
  • by Karma Farmer (595141) on Wednesday October 27, 2004 @05:41PM (#10647820)
    If we're going to add exceptions to the kernel, lets go all the way and add "call-with-current-continuation." Imagine how much cleaner the resulting code would be!
    • Re:call/cc (Score:5, Funny)

      by Dr. Photo (640363) on Wednesday October 27, 2004 @06:38PM (#10648412) Journal
      Clean, but not clean enough. For true conceptual purity, you need lexical closures, call-by-name, monads, lambdas, cooperative microthreads (though of course these could be simulated by call/cc), message passing, introspection and serialization, nongenerative record types, one-shot and partial continuations, maybe a little prototype-based OOP for flavor, and of course if you add prototype-based OOP, you'll need generics that are specializable by object rather than class (as well as consider the case of whether a method specialized for a particular prototype object still applies to its descendents), not to mention considering how that would affect the implementation of a meta-object protocol and multiple inheritance.

      Once you've done all this, Linux will truly be ready for the desktop. (Assuming you axiomatize your language definition first, to get rid of unnecessary features like for loops).
  • by noselasd (594905) on Wednesday October 27, 2004 @05:49PM (#10647910)
    Linux made his view on C++ in the kernel a while ago here [kerneltrap.org]
  • C vs C++ (Score:4, Insightful)

    by steinnes (774991) on Wednesday October 27, 2004 @05:57PM (#10647996) Homepage
    These guys didn't do this with hopes of it being accepted into mainline, they did it to use with their pronto project (some sort of dynamic multicasting project, using the Linux kernel).

    Personally, I think mixing C++ into the kernel is not a good idea, generally, in my experience certain aspects of C++ are messy to debug, and if you're gonna skip using them, then perhaps you should've stuck to C.

    Also these guys used to distribute their pronto project in one tarball, a modified version of the Linux kernel, and the website for downloading it made you have to accept *their* license. When the issue of whether this was possibly in violation of the GPL, and if they should rather distribute a clean patch, came up on the local GLUG mailing list (www.rglug.org) their response was rather shocking, they absolutely refused to acknowledge that they should perhaps distribute their code in another way, and even reverted to speculations about the legitimacy and enforcability of the GPL. To their defense, the original 'article' on the matter was very inflammatory and made some rather derogatory remarks, and IIRC they changed their website some time later.

    Multicasting is a cool technology, and dynamic multicasting routers such as RU is researching and developing with the Pronto project, may well be the key to using the internet as a single infrastructure for 95% of our content-delivery and communication needs (digital TV through the internet, without exponentially increasing bandwidth load, etc), so I hope RU keep on, and their work be fruitful :-)

    Also, to everyone who refers to the creator of Linux, as 'Linux'... his name is 'Linus', get it through your heads, this is slashdot.org not mouthbreathers.org ;-)
  • by Baldrson (78598) on Wednesday October 27, 2004 @06:54PM (#10648538) Homepage Journal
    If you want to optimize exception handling then choose an exception-based execution model. Most people -- particularly Perl programmers -- are familiar with the short-circuit "or" and short-circuit "and" style of programming. "and" binds more tightly than "or" so that a sequence of "and" looks like a normal execution thread with no exceptions, whereas a sequence of "or" looks like a cascade of exception handlers (if all the prior expressions in the "or" sequence fail then you take the next one as an exception handler).

    When I say "thread" above I'm not just throwing around an ad hoc term -- you can use this to provide the basis for parallel execution in an OS or language.

    There is an entire school of thought built around this idea called logic programming and it is based on the most widely used foundation for mathematics -- the predicate calculus.

    I don't know why people spend so much time and energy optimizing things that are less powerful.

    As for object oriented programming, As I've said before [slashdot.org]:

    Almost all the Object Oriented stuff people layer on predicates are, at best, an ad hoc, and poor, means of optimizing execution speed.

    Let me explain.

    One of the principles of polymorphism is that the same method has the same abstract meaning regardless of the kind of object. A predicate considered as a method subsumes such polymorphism by simply trying the various possible implementations of the method and committing to only those that succeed. If more than one succeeds then so be it -- that's the whole idea of relations as opposed to functions.

    So, one reason you want all this OO stuff is the inheritance hierarchies keep you from going through all possible interpretations of a given method when the vast majority of them will fail for a given object.

    Another, related, problem is that inheritance provides defaults without requiring a lot of thinking on the part of the computer. What I mean by "thinking" here is the sort of thing that is done by statistical imputation of missing data via algorithms like expectation maximization (EM) [clusty.com] [clusty.com] or multi-relational data mining [clusty.com] via inductive logic programming [clusty.com] .

    So, the other reason you want all this OO stuff is so you can avoid mining a background database to provide reasonable defaults for various aspects of the data.

    Some might be concerned that over-riding isn't absolute in such a system -- that you don't absolutely block, say, more generic methods when you have more specific ones present, and they're right. You don't block those methods -- you lower their priority by lowering the probability of those implementations via the statistical methods of imputation and/or induction. In a microthreading environment they most likely won't get any resources allocated to them before other higher priority implementations have succeeded. In a single threaded/depth-first environment they will be down the list of desired alternatives -- but they won't be discarded until something equivalent to a prolog cut operation kills them off.

    However, and this is the important point, the work that has been expended toward OO facilities has vastly outstripped the effort that which has been put toward more parsimonious ways of optimizing predicate systems.

    One of the better predicate calculus systems out there -- more promising due to its use of tabling to avoid infinite regress on head-recursive definitions and its optimization of queries using some fairly general theorems of predicate calculus -- is XSB [sourceforge.net] . It has an interface to odbc and a direct interface to Oracle, but it would be better if it had something like a

  • by Peaker (72084) <`gnupeaker' `at' `yahoo.com'> on Wednesday October 27, 2004 @06:59PM (#10648577) Homepage
    Shapiro is the guy working on a research Operating System project (The EROS [eros-os.org] system).

    EROS was originally implemented in C++, but then
    it was reimplemented in C [iu.edu].

The major difference between bonds and bond traders is that the bonds will eventually mature.

Working...