A whole minute!? Oh my gosh, how do you put up with it!?!?
In Australia, especially with evening TV, you can expect the start of shows to be shifted around by a good 15-20 minutes from their scheduled times on some channels from time to time. That is when the scheduled times aren't shifted around from week to week to accommodate the latest sport/reality TV/final episode/crime drama/fad event. I'm already in the habit of setting up my VCR to record 20 minutes before and after the scheduled times, because my old padding of 15 minutes actually wasn't enough on one occasion. And I start recording manually every few weeks because they are screening the show half an hour earlier or later.
I swear, they air the good shows in the evening and screw with the times frequently so they can claim that no-one watches them, thus allowing them to pimp the latest reality TV show where backstabbing football-playing forensic scientists, lawyers and police officers are voted off an island in the final episodes of the series.
Assuming EA is deserving of the wrath by which so many speak, I imagine a combination of the two approaches might be effective. Don't buy or play it as the parent says, but if you find anyone who plans to buy it, talk them out of it. If _that_ doesn't work, point them to a "pirate" copy as the grandparent suggests.
An organisation that shows blatant legal and moral disregard for their employees shouldn't expect to be shown regard by their customers in return. And conversely, if an organisation treats its customers and employees well, make damn sure that you support them. Weed out the exploiters and reward the ones with social responsibility.
ISP Subscription: $25
Second-hand PC: $200
Receiving a +5 Funny on a comment deliberately mentioning making an alternate post aiming for a +5 Funny moderation thus obtaining the nirvana of meta-humour...
Here I was thinking I could make some quip about this new service recording and inserting additional ads into your recorded content, and tag a fast "5:Funny". Something like this:
"I hear Microsoft plan to go for an untapped market niche neglected by the TiVo. This new recorder records just the ads around the program, as well as inserting a few of its own."
Surefire positive moderation and reassurance for my meaningless existence centered around Slashdot karma right? Well, it seems the comedians at Microsoft have already stolen my thunder. From the Microsoft Foundation page...
Sell and secure HDTV homes. Promote offerings with targeted ads and recommendations. Insert ads and promotions... Control and customize your viewers' experience.
It seems that they have they thought of all my best gags and implemented them as actual features. Dammit. What a sad day when a monolithic company can spent thousands on marketing a product whose primary purpose is to deny a Slashdotter the simple pleasure of a two-line quip. *runs and cries*
You don't have to sell me on the benefits of using exceptions versus setjmp/longjmp. The majority of my software development is at the application level using C++, and as mentioned in my initial posting it is my favoured (least detested) language. I could provide very long-winded arguments for C++ over C at this level, and I'm sure you'd be backing me up.:)
I feel the code fragments you've provided are a touch on the strawman side. You're asking for a comparison between C code specifically modelled around exception use, and C++ using exceptions. Between those two, the C++ solution is considerably more elegant. Realistically, the same code could be rewritten so that process has a return value indicating error return, with explicit cleanup of resources. With the C code you would know exactly what is cleaned up, and when. If you can cut certain corners, you may.
Now forgive me for jumping a step along in the argument, but I presume a response to the above would be "What if there were (considerably) more resources to manage?". In this case the C code would maintain the advantage of explicit control, but would have the following disadvantages relative to C++:
- considerably more complex resource management.
- longer development cycle.
- more repetitive code, thus a greater chance of introducing bugs.
- harder to read and thus develop and debug for.
You would agree? Now what would I rather write this in? C++ without a doubt. However, you do retain the explicitly control when using C. So there is a tradeoff: more control versus greater elegance.
Granted different C++ compilers will generate different code to implement the specifics of C++ semantics. This is also true of C compilers generating different code to implement the specifics of C semantics. If the semantics are implemented differently and produce the expected results with no side-effects then they are functionally the same. It is also true that the run-time efficiency will likely be a consideration in the selection of the C++ compiler but for linux is is for all intrinsic purposes it is the GNU C++ tool chain.
A single compiler toolchain makes things much easier. I couldn't really see C++ gain much ground if one had to argue the benefits across multiple toolchains. It would be a hard sell.
That is the same argument made 15 years ago that in order to develop a device driver you had to use assembly language.
And fifteen years ago it would have been a good argument. Resources were much tighter then. You wouldn't want to use this silly upstart C that doesn't explicitly let you set up your own call stacks and choose which arguments are held in which registers. Let a compiler choose which arguments will be kept in registers and which in memory without understanding the problem domain? Preposterous!;) And here we are today debating letting C++ into the kernel. C is already a core part of the kernel, and the costs of letting the compiler decide register allocation and build its own stack frames is considered acceptable. As mentioned in another post on this topic, competitive pressure will push C++ into this role at some point. My argument is merely that it should not be today. C is a considerably more mature language than C++, both in terms of standardisation and compiler reliability. It wasn't that long ago that I was explicitly initialising global constructors in C++. I have just rewritten a chunk of code that used ifstreams back to use C FILEs to read data as the STL implementation included with the gcc of FC2 and mingw being too buggy to sensibly use (readsome() not working, eof() not returning true at end of file, in_avail() returning the wrong value, etc). I have found definite compiler bugs when using C++ (g++), but can't say the same about C (gcc). C++ is considerably more complex and younger than C. The instability of C++ is going to be a thorn for some time.
It would be prudent to code a C++ program that actually bench
Wow, I never thought a post of mine would gather so many responses.:) I guess my original post must have been either insightful or inciteful.;)
C++ does allow you as fine a degree of granularity when managing resources as C. The statement "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." is not necessarily a true statement.
Memory and resource management can be made to do exactly what the kernel developer needs. Placement new and custom memory managers that replace the standard memory memory management will give the kernel developer precise control over where and how memory is managed.
Okay, I'll hit this from two angles. I both agree and disagree with you.
On the memory management side, as Corngood highlighted earlier, you can explicitly specify allocation parameters when creating a new class. The notation is, IMHO, no more complex than the current C-equivalent. So from this angle, I agree.
I do contend that C++ however does not have as explicit control over resource allocation as C does. When you add exceptions, virtual functions, global constructors, template instantiations and so forth, the C++ language expects the compiler to magically sort out the details and just make it work. It took some time for compilers to actually get this right, and different compilers achieve the magic required in different ways. C relies on considerably less magic, and is a less powerful language than say C++. Its advantage, however, is that whilst it is painfully explicit, it is painfully explicit.;) I would contend that a language with less magic is a better fit to a problem where resource use and allocation must be tightly controlled. When you call a function in C, it runs and returns something (or longjmps over you, or exits). In C++, it runs, possibly throwing an exception, or maybe not. You can't be entirely sure how the exception will be handled... when do we push some return info on the stack, does the called function handle this, so forth. The general mystery (magic) is the problem to which I refer.
Classes and structs in C++ are abstractions with bindings to the correct function. With C++ a vtable is not required unless virtual functions are used.
Correct, they are not required, and probably won't be generated, and type information probably won't be generated. You are thus probably safe. I'm not sure if it mentions in the C++ standard if the compiler must not generate this information? Someone will surely point me to a mention here. In C though, you know you are safe.
Templates can and should be used over macros when creating inline code. You have the benefit of typechecking. With use of Metaprogramming techniques tables that would have to be calculated during initialization can be created as a result of compiling the code (C++ Gems [Lippman 1997]).
Templates do have strong benefits (eg. typechecking as you quote), although they are not without their problems. They tend not to behave too well relative to macros when you attempt to use features that fall outside of their scope... eg. explicit value initialisation, operations directly on the type name, so forth. And let's not forget the mess that is passing structures containing helper functions to a template as an argument. Additionally, error messages relating to template use tend to be absolutely hideous and undecipherable. And there is no standardised explicit initialisation. Templates are considerably easier to understand in source code form than macros though, and I do not deny the advantages that they bring.
Thus I would disagree with the above statement being a general rule, but it is certainly a go
Okay, thanks for the additional information. I have not used the placement syntax of new before (heck, I wasn't aware of it). For the curious, it lets you pass separate arguments to the allocator, even during construction, which does appear to solve the problem I originally mentioned reasonably well. My original implication that passing this flag would be difficult to do is thus incorrect. Corngood is quite correct.
Could I trouble you for some more detail on your suggestion? I may be unfamiliar with the technique you are trying to use and would rather not make an uninformed reply.
And the kernel, at more than 4 MLOC isn't large enough?
A good point.:) Perhaps if one were to develop a Linux-like kernel from scratch, and we were prepared to tolerate potential C++ inefficiencies (eg. exception setup, see other posts) slipping through, we would see a kernel developed using considerably less resources and containing greater modularity than the present one. I'd wager that, once you got over the steeper C++ learning curve, that it was easier to develop for. It wouldn't be anywhere near as fast, but for the same effort it would probably have considerably more features.
Unfortunately, this nice theoretical case looking at code size only isn't exactly what we have here. We have an architecture which requires careful and controlled use of resources. We also have (borrowing your estimate) 4 MLOC of mostly-C code already in use. Bolting on C++ code is going to add additional dependencies and resource requirements to the kernel. There would be some debate over which C++ features were considered acceptable. And in each case there are going to be people (justifiably) wanting to know what the benefit will be for the cost that must be paid.
Having said all that, I think the use of additional languages in kernel and operating system code is inevitable, eventually. As processor power increases and hardware costs decrease, the limited resource argument becomes weaker and weaker. Eventually competitive pressure is going to push tools that are easier to use into development roles for these entities. My argument is merely "not yet". I expect to be wrong in x years, I just have no idea what x is.
> You can apply C++ without pulling in the STL and the standard memory management. For the most part new can very easily be re-written (and I have done it in userland in order to demonstrate memory profiling and a couple other features that can be integrated in a transparent manner to the developer through control of memory management in C++).
Of course. Bringing in the STL would probably cause a lot of friction, for the reasons I have been discussing. And the "new" memory allocation absolutely must be changed... you can't use ordinary memory allocation functions in kernel-land. Also, how would you get the properties argument of kmalloc into new? Write a per-class new method? It would get messy fast.
> A little understanding of the language specifications go a long way to be able to write good code for it,
Of course. There is far less mystery in C though, and a fair bit more magic involved in C++, eg. in linking.
> and avoiding constructs that don't make sense in a kernel environment (I don't see why you need an overloaded a==b for objects in a kernel environment...).
Different people would see different benefits to different language features. I would for example not have such a problem with overloaded operators, you might, and everyone else would have their opinions too.
> You could write some sort of 'super-recovery' mechanism into the kernel which could recover in the case of some major uncaught exception... at least partly. Of course that is more theoretical, and not something I have time to experiment with.;)
This might just raise the ire of those who really don't want C++-isms polluting the code. And the question begs, how would one go about writing such a beast?
Wish I had a bit more time to debate this (rotten tax return), so please excuse my brevity.
> >C allows this kind of control, C++ does not.
> Err... can you show me anything that you can do in C that you can't do in C++? No one forces you to use any of the features you seem to find troublesome - you can be a "close to the metal" in C++ as in C. For starters, you could just recompile your C code with a C++ compiler;)
Only use the C features in C++? Hehe, well, it goes without saying that they would be of comparable efficiency and use comparable resources then. A Bentley Arnage 4WD is just as fuel efficient as a Honda Insight if you leave them both stationary in a garage. I think the point of getting the C++ into the kernel is to use C++ features. The article talks about exceptions and dynamic type checking, so I think this is the case.
If I had to answer your first question though (which is hard, C is (sorta-kinda) a subset of C++), I would probably mention that you can't just bolt on code in C++ using certain features (exceptions, global destructors) etc onto the C code base, whereas there are no such issues with C. Of course, you could limit the subset of C++ you use to C, in which case refer to the prior paragraph. Saying "let's use C++", and justifying potential problems with "we'll only use the C bits" isn't a terribly good argument; I presume you're not trying to do that?
> > (memory use, exception setup, excess copying, dynamic checking) > Exceptions and dynamic checking are features that you choose to use if appropriate; they don't add overhead if you don't use them. One of the key design principles of C++. > Memory use is not inherently higher in C++ than in C, and neither does the language force excess copying on you - that's more likely due to bad programming than the language.
I'm not sure I can effectively debate the first point, so I'll have to leave that to someone more knowledgeable in compiler development than myself. I do think that leaving out those two things would somewhat cripple C++. Bear in mind my comment about C++ being my favoured language, I'm not kidding about that. But I do stand by my assertion that there are places where it suits, and places where it does not.
It is much easier to lose track of where and when memory is being allocated and calls are made in C++ than C. This is particularly true when using the STL. Unless you are advocating using C++ in the kernel without RTTI, templates, exceptions, constructors, destructors, so forth, in which case there isn't a lot of C++ left.:) Blaming inefficiencies on "bad programming" is like me saying anyone who doesn't like the way I cut my hair has "bad taste". It is particularly untrue for C++, which is (IMHO) harder to write optimised or deliberately controlled code for. I've lost count of the number of times I want to bust into one of the STL containers because I know it is going to go about things the slow way. Things are a lot more explicit in C, part of the reason why it doesn't scale too well (and I know I'll get shredded for that last sentence, but hey).
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.
I need a new computer, can you show me a price list?
You need a new computer? That's great! Price lists are so 1990s btw. Just spec out the machine, give me your bank account details, and I'll draw out the appropriate amount from your account. I can then send you the legals, and if you accept them I will send you your shiny new PC!
Can I interest you in a free quote on lawn-mowing?
The thing is most spyware installs itself *without* you knowing...
Funny you should mention that. I've been thinking about branching out into a lawn-mowing service. The plan is to offer free quotes, all the customer has to do is send me their address. When they do, after dropping around and giving them a quote (I am a legitimate business after all), I come back later that evening and install the pop-up rock flingers anyway. I just have to come up with a suitable message for the hidden speaker for this market. I'm thinking something like:
"Buy computer hardware from OverflowingBitBucket Inc! OverflowingBitBucket Inc. is a legitimate business. You have been added to out rock-flinging list by some unspecified action you might have performed in the past. If you would like to to opt-out of future rock-flingings, please write a letter to our office in Heremettica."
Of course I don't actually _have_ an office in Heremettica, since I just made up that name then. But that's okay, I don't plan to respond to any mails there anyway.
Really? Well, me personally, I'm not so sure what the problem with spyware. It's just another legitimate way of doing business. They did agree to the EULA allowing it after all, didn't they?
Take me for example. I sell preassembled computer systems. As part of the package I include a short, 83-page EULA that fires up when they first boot the system. After accepting the EULA (which they don't see until after I've cashed their cheque btw) I drop around to the customers house and install a series of automatic pop-up rock flingers in their front garden. At 3am the rock flingers pelt their bedroom windows with small rocks... generally not enough to break the glass, but I'm working on it. When they come out to see what the problem is, a hidden speaker blares out "Buy computer hardware from OverflowingBitBucket Inc!".
Thankfully the supplied EULA allows me to do this, so it's all legal. In fact, I'm anticipating an increase in business, as several customers have called me _personally_ and said they'll be dropping around to see me real soon now.
J++ was not a Sun product and it wasn't called Java.
Exactly, that was my point. It still caused them enough problems by merely being "Java-like".
In the end, they can't have it both ways.
Quite true, they certainly can't have it both ways.
Perhaps the way they see the situation is that on one extreme they have complete control over Java, and on the other they have no control but all of the benefits of open source development. It seems they are looking for a middleground that will get them enough of the benefits of both extremes to be worth the compromises they have to make. They needn't choose one or the other. Maybe they can have most of their cake and nibble a little bit of it too.
I would have to say that my first impression is that your solution sounds like a great idea.
However...
Remember that Sun did get stung a bit back by a little Java-like offshoot that wouldn't have passed their test suites. Remember Visual J++? Trademark protection wouldn't have helped there, J++ != Java.
They are probably looking to avoid a repeat of the same "mistake".
Shall we take it as given that MS want to control the level specification themselves?
Okay, minimum CPU specs (ignoring different architectures of course), amount of RAM, maybe disk space, hardware acceleration, sounds good so far! Minimum OpenGL extensions...
... oh hang on, let's be realistic. Minimum Direct3D extensions.
And you'll need an operating system with that PC... oh my, it seems level x+1 requires Longhorn.
Oh, the PC isn't shipped with the latest Windows operating system? No level y certification for you!
Slashdot Mirror
A whole minute!? Oh my gosh, how do you put up with it!?!?
In Australia, especially with evening TV, you can expect the start of shows to be shifted around by a good 15-20 minutes from their scheduled times on some channels from time to time. That is when the scheduled times aren't shifted around from week to week to accommodate the latest sport/reality TV/final episode/crime drama/fad event. I'm already in the habit of setting up my VCR to record 20 minutes before and after the scheduled times, because my old padding of 15 minutes actually wasn't enough on one occasion. And I start recording manually every few weeks because they are screening the show half an hour earlier or later.
I swear, they air the good shows in the evening and screw with the times frequently so they can claim that no-one watches them, thus allowing them to pimp the latest reality TV show where backstabbing football-playing forensic scientists, lawyers and police officers are voted off an island in the final episodes of the series.
Assuming EA is deserving of the wrath by which so many speak, I imagine a combination of the two approaches might be effective. Don't buy or play it as the parent says, but if you find anyone who plans to buy it, talk them out of it. If _that_ doesn't work, point them to a "pirate" copy as the grandparent suggests.
An organisation that shows blatant legal and moral disregard for their employees shouldn't expect to be shown regard by their customers in return. And conversely, if an organisation treats its customers and employees well, make damn sure that you support them. Weed out the exploiters and reward the ones with social responsibility.
And here I thought it'd be an expose, or at least somewhat cynical...
I think it's damage control.
ISP Subscription: $25
.... Priceless.
Second-hand PC: $200
Receiving a +5 Funny on a comment deliberately mentioning making an alternate post aiming for a +5 Funny moderation thus obtaining the nirvana of meta-humour...
Here I was thinking I could make some quip about this new service recording and inserting additional ads into your recorded content, and tag a fast "5:Funny". Something like this:
"I hear Microsoft plan to go for an untapped market niche neglected by the TiVo. This new recorder records just the ads around the program, as well as inserting a few of its own."
Surefire positive moderation and reassurance for my meaningless existence centered around Slashdot karma right? Well, it seems the comedians at Microsoft have already stolen my thunder. From the Microsoft Foundation page...
Sell and secure HDTV homes.
Promote offerings with targeted ads and recommendations.
Insert ads and promotions...
Control and customize your viewers' experience.
It seems that they have they thought of all my best gags and implemented them as actual features. Dammit. What a sad day when a monolithic company can spent thousands on marketing a product whose primary purpose is to deny a Slashdotter the simple pleasure of a two-line quip. *runs and cries*
AFAIK, da Vinci (and other inventors of the time) placed errors and flaws in the schematics of their inventions on purpose.
I'm a software engineer, and I've been doing this for years. I didn't realise da Vinci also had job security issues.
You don't have to sell me on the benefits of using exceptions versus setjmp/longjmp. The majority of my software development is at the application level using C++, and as mentioned in my initial posting it is my favoured (least detested) language. I could provide very long-winded arguments for C++ over C at this level, and I'm sure you'd be backing me up. :)
;) And here we are today debating letting C++ into the kernel. C is already a core part of the kernel, and the costs of letting the compiler decide register allocation and build its own stack frames is considered acceptable. As mentioned in another post on this topic, competitive pressure will push C++ into this role at some point. My argument is merely that it should not be today. C is a considerably more mature language than C++, both in terms of standardisation and compiler reliability. It wasn't that long ago that I was explicitly initialising global constructors in C++. I have just rewritten a chunk of code that used ifstreams back to use C FILEs to read data as the STL implementation included with the gcc of FC2 and mingw being too buggy to sensibly use (readsome() not working, eof() not returning true at end of file, in_avail() returning the wrong value, etc). I have found definite compiler bugs when using C++ (g++), but can't say the same about C (gcc). C++ is considerably more complex and younger than C. The instability of C++ is going to be a thorn for some time.
I feel the code fragments you've provided are a touch on the strawman side. You're asking for a comparison between C code specifically modelled around exception use, and C++ using exceptions. Between those two, the C++ solution is considerably more elegant. Realistically, the same code could be rewritten so that process has a return value indicating error return, with explicit cleanup of resources. With the C code you would know exactly what is cleaned up, and when. If you can cut certain corners, you may.
Now forgive me for jumping a step along in the argument, but I presume a response to the above would be "What if there were (considerably) more resources to manage?". In this case the C code would maintain the advantage of explicit control, but would have the following disadvantages relative to C++:
- considerably more complex resource management.
- longer development cycle.
- more repetitive code, thus a greater chance of introducing bugs.
- harder to read and thus develop and debug for.
You would agree? Now what would I rather write this in? C++ without a doubt. However, you do retain the explicitly control when using C. So there is a tradeoff: more control versus greater elegance.
Granted different C++ compilers will generate different code to implement the specifics of C++ semantics. This is also true of C compilers generating different code to implement the specifics of C semantics. If the semantics are implemented differently and produce the expected results with no side-effects then they are functionally the same. It is also true that the run-time efficiency will likely be a consideration in the selection of the C++ compiler but for linux is is for all intrinsic purposes it is the GNU C++ tool chain.
A single compiler toolchain makes things much easier. I couldn't really see C++ gain much ground if one had to argue the benefits across multiple toolchains. It would be a hard sell.
That is the same argument made 15 years ago that in order to develop a device driver you had to use assembly language.
And fifteen years ago it would have been a good argument. Resources were much tighter then. You wouldn't want to use this silly upstart C that doesn't explicitly let you set up your own call stacks and choose which arguments are held in which registers. Let a compiler choose which arguments will be kept in registers and which in memory without understanding the problem domain? Preposterous!
It would be prudent to code a C++ program that actually bench
Wow, I never thought a post of mine would gather so many responses. :) I guess my original post must have been either insightful or inciteful. ;)
;) I would contend that a language with less magic is a better fit to a problem where resource use and allocation must be tightly controlled. When you call a function in C, it runs and returns something (or longjmps over you, or exits). In C++, it runs, possibly throwing an exception, or maybe not. You can't be entirely sure how the exception will be handled... when do we push some return info on the stack, does the called function handle this, so forth. The general mystery (magic) is the problem to which I refer.
C++ does allow you as fine a degree of granularity when managing resources as C. The statement "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." is not necessarily a true statement.
Memory and resource management can be made to do exactly what the kernel developer needs. Placement new and custom memory managers that replace the standard memory memory management will give the kernel developer precise control over where and how memory is managed.
Okay, I'll hit this from two angles. I both agree and disagree with you.
On the memory management side, as Corngood highlighted earlier, you can explicitly specify allocation parameters when creating a new class. The notation is, IMHO, no more complex than the current C-equivalent. So from this angle, I agree.
I do contend that C++ however does not have as explicit control over resource allocation as C does. When you add exceptions, virtual functions, global constructors, template instantiations and so forth, the C++ language expects the compiler to magically sort out the details and just make it work. It took some time for compilers to actually get this right, and different compilers achieve the magic required in different ways. C relies on considerably less magic, and is a less powerful language than say C++. Its advantage, however, is that whilst it is painfully explicit, it is painfully explicit.
Classes and structs in C++ are abstractions with bindings to the correct function. With C++ a vtable is not required unless virtual functions are used.
Correct, they are not required, and probably won't be generated, and type information probably won't be generated. You are thus probably safe. I'm not sure if it mentions in the C++ standard if the compiler must not generate this information? Someone will surely point me to a mention here. In C though, you know you are safe.
Templates can and should be used over macros when creating inline code. You have the benefit of typechecking. With use of Metaprogramming techniques tables that would have to be calculated during initialization can be created as a result of compiling the code (C++ Gems [Lippman 1997]).
Templates do have strong benefits (eg. typechecking as you quote), although they are not without their problems. They tend not to behave too well relative to macros when you attempt to use features that fall outside of their scope... eg. explicit value initialisation, operations directly on the type name, so forth. And let's not forget the mess that is passing structures containing helper functions to a template as an argument. Additionally, error messages relating to template use tend to be absolutely hideous and undecipherable. And there is no standardised explicit initialisation. Templates are considerably easier to understand in source code form than macros though, and I do not deny the advantages that they bring.
Thus I would disagree with the above statement being a general rule, but it is certainly a go
Okay, thanks for the additional information. I have not used the placement syntax of new before (heck, I wasn't aware of it). For the curious, it lets you pass separate arguments to the allocator, even during construction, which does appear to solve the problem I originally mentioned reasonably well. My original implication that passing this flag would be difficult to do is thus incorrect. Corngood is quite correct.
Could I trouble you for some more detail on your suggestion? I may be unfamiliar with the technique you are trying to use and would rather not make an uninformed reply.
And the kernel, at more than 4 MLOC isn't large enough?
:) Perhaps if one were to develop a Linux-like kernel from scratch, and we were prepared to tolerate potential C++ inefficiencies (eg. exception setup, see other posts) slipping through, we would see a kernel developed using considerably less resources and containing greater modularity than the present one. I'd wager that, once you got over the steeper C++ learning curve, that it was easier to develop for. It wouldn't be anywhere near as fast, but for the same effort it would probably have considerably more features.
A good point.
Unfortunately, this nice theoretical case looking at code size only isn't exactly what we have here. We have an architecture which requires careful and controlled use of resources. We also have (borrowing your estimate) 4 MLOC of mostly-C code already in use. Bolting on C++ code is going to add additional dependencies and resource requirements to the kernel. There would be some debate over which C++ features were considered acceptable. And in each case there are going to be people (justifiably) wanting to know what the benefit will be for the cost that must be paid.
Having said all that, I think the use of additional languages in kernel and operating system code is inevitable, eventually. As processor power increases and hardware costs decrease, the limited resource argument becomes weaker and weaker. Eventually competitive pressure is going to push tools that are easier to use into development roles for these entities. My argument is merely "not yet". I expect to be wrong in x years, I just have no idea what x is.
Sorry, s/kmalloc/kalloc/g.
> You can apply C++ without pulling in the STL and the standard memory management. For the most part new can very easily be re-written (and I have done it in userland in order to demonstrate memory profiling and a couple other features that can be integrated in a transparent manner to the developer through control of memory management in C++).
;)
Of course. Bringing in the STL would probably cause a lot of friction, for the reasons I have been discussing. And the "new" memory allocation absolutely must be changed... you can't use ordinary memory allocation functions in kernel-land. Also, how would you get the properties argument of kmalloc into new? Write a per-class new method? It would get messy fast.
> A little understanding of the language specifications go a long way to be able to write good code for it,
Of course. There is far less mystery in C though, and a fair bit more magic involved in C++, eg. in linking.
> and avoiding constructs that don't make sense in a kernel environment (I don't see why you need an overloaded a==b for objects in a kernel environment...).
Different people would see different benefits to different language features. I would for example not have such a problem with overloaded operators, you might, and everyone else would have their opinions too.
> You could write some sort of 'super-recovery' mechanism into the kernel which could recover in the case of some major uncaught exception... at least partly. Of course that is more theoretical, and not something I have time to experiment with.
This might just raise the ire of those who really don't want C++-isms polluting the code. And the question begs, how would one go about writing such a beast?
Wish I had a bit more time to debate this (rotten tax return), so please excuse my brevity.
;)
:) Blaming inefficiencies on "bad programming" is like me saying anyone who doesn't like the way I cut my hair has "bad taste". It is particularly untrue for C++, which is (IMHO) harder to write optimised or deliberately controlled code for. I've lost count of the number of times I want to bust into one of the STL containers because I know it is going to go about things the slow way. Things are a lot more explicit in C, part of the reason why it doesn't scale too well (and I know I'll get shredded for that last sentence, but hey).
> >C allows this kind of control, C++ does not.
> Err... can you show me anything that you can do in C that you can't do in C++? No one forces you to use any of the features you seem to find troublesome - you can be a "close to the metal" in C++ as in C. For starters, you could just recompile your C code with a C++ compiler
Only use the C features in C++? Hehe, well, it goes without saying that they would be of comparable efficiency and use comparable resources then. A Bentley Arnage 4WD is just as fuel efficient as a Honda Insight if you leave them both stationary in a garage. I think the point of getting the C++ into the kernel is to use C++ features. The article talks about exceptions and dynamic type checking, so I think this is the case.
If I had to answer your first question though (which is hard, C is (sorta-kinda) a subset of C++), I would probably mention that you can't just bolt on code in C++ using certain features (exceptions, global destructors) etc onto the C code base, whereas there are no such issues with C. Of course, you could limit the subset of C++ you use to C, in which case refer to the prior paragraph. Saying "let's use C++", and justifying potential problems with "we'll only use the C bits" isn't a terribly good argument; I presume you're not trying to do that?
> > (memory use, exception setup, excess copying, dynamic checking)
> Exceptions and dynamic checking are features that you choose to use if appropriate; they don't add overhead if you don't use them. One of the key design principles of C++.
> Memory use is not inherently higher in C++ than in C, and neither does the language force excess copying on you - that's more likely due to bad programming than the language.
I'm not sure I can effectively debate the first point, so I'll have to leave that to someone more knowledgeable in compiler development than myself. I do think that leaving out those two things would somewhat cripple C++. Bear in mind my comment about C++ being my favoured language, I'm not kidding about that. But I do stand by my assertion that there are places where it suits, and places where it does not.
It is much easier to lose track of where and when memory is being allocated and calls are made in C++ than C. This is particularly true when using the STL. Unless you are advocating using C++ in the kernel without RTTI, templates, exceptions, constructors, destructors, so forth, in which case there isn't a lot of C++ left.
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.
I need a new computer, can you show me a price list?
You need a new computer? That's great! Price lists are so 1990s btw. Just spec out the machine, give me your bank account details, and I'll draw out the appropriate amount from your account. I can then send you the legals, and if you accept them I will send you your shiny new PC!
Can I interest you in a free quote on lawn-mowing?
The thing is most spyware installs itself *without* you knowing...
Funny you should mention that. I've been thinking about branching out into a lawn-mowing service. The plan is to offer free quotes, all the customer has to do is send me their address. When they do, after dropping around and giving them a quote (I am a legitimate business after all), I come back later that evening and install the pop-up rock flingers anyway. I just have to come up with a suitable message for the hidden speaker for this market. I'm thinking something like:
"Buy computer hardware from OverflowingBitBucket Inc! OverflowingBitBucket Inc. is a legitimate business. You have been added to out rock-flinging list by some unspecified action you might have performed in the past. If you would like to to opt-out of future rock-flingings, please write a letter to our office in Heremettica."
Of course I don't actually _have_ an office in Heremettica, since I just made up that name then. But that's okay, I don't plan to respond to any mails there anyway.
Really? Well, me personally, I'm not so sure what the problem with spyware. It's just another legitimate way of doing business. They did agree to the EULA allowing it after all, didn't they?
Take me for example. I sell preassembled computer systems. As part of the package I include a short, 83-page EULA that fires up when they first boot the system. After accepting the EULA (which they don't see until after I've cashed their cheque btw) I drop around to the customers house and install a series of automatic pop-up rock flingers in their front garden. At 3am the rock flingers pelt their bedroom windows with small rocks... generally not enough to break the glass, but I'm working on it. When they come out to see what the problem is, a hidden speaker blares out "Buy computer hardware from OverflowingBitBucket Inc!".
Thankfully the supplied EULA allows me to do this, so it's all legal. In fact, I'm anticipating an increase in business, as several customers have called me _personally_ and said they'll be dropping around to see me real soon now.
I notice Harrison Ford won it in 2000. So Han (sorry Ford) won it first.
Give it a few years, and they'll release a special edition of the award, where Lucas wins first.
J++ was not a Sun product and it wasn't called Java.
Exactly, that was my point. It still caused them enough problems by merely being "Java-like".
In the end, they can't have it both ways.
Quite true, they certainly can't have it both ways.
Perhaps the way they see the situation is that on one extreme they have complete control over Java, and on the other they have no control but all of the benefits of open source development. It seems they are looking for a middleground that will get them enough of the benefits of both extremes to be worth the compromises they have to make. They needn't choose one or the other. Maybe they can have most of their cake and nibble a little bit of it too.
I would have to say that my first impression is that your solution sounds like a great idea.
However...
Remember that Sun did get stung a bit back by a little Java-like offshoot that wouldn't have passed their test suites. Remember Visual J++? Trademark protection wouldn't have helped there, J++ != Java.
They are probably looking to avoid a repeat of the same "mistake".
Before I became allergic to alcohol (really!) I found that a few beers would both decrease the detail levels and increase the apparent framerate.
I stand corrected. It seems you have found a way to overclock life. Well, apart from caffeine, anyway.
That's a harsh allergy to live with. For your sake I hope you also have an allergy to being the designated driver too often.
But you can't turn the detail levels down to make it run faster.
I can just see groups of people hanging around outside computer stores waiting for the Level 12 PC to spawn so that they can take it out.
Hmm... I can't see where this is going.
... oh hang on, let's be realistic. Minimum Direct3D extensions.
Shall we take it as given that MS want to control the level specification themselves?
Okay, minimum CPU specs (ignoring different architectures of course), amount of RAM, maybe disk space, hardware acceleration, sounds good so far! Minimum OpenGL extensions...
And you'll need an operating system with that PC... oh my, it seems level x+1 requires Longhorn.
Oh, the PC isn't shipped with the latest Windows operating system? No level y certification for you!