Slashdot Mirror
Object Oriented Linux Kernel With C++ Driver Support
An anonymous reader writes: An effort underway called BOSS-MOOL, the Minimalistic Object Oriented Linux, is designing the Linux kernel with OOP and C++ driver support. Linus Torvalds' opinions on C++ have long been known while developers at the DOS Lab IIT Madras and CDAC Chennai feel redesigning the kernel with object oriented abstractions and C++ driver support will increase maintainability while reducing complexity of the kernel. It doesn't appear though the group will try to mainline these changes.
BeOS used C++. Microsoft Windows uses C++ -- albeit with the CRT (C Run Time) library separated.
Linus hates C++ for kernel development because C++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling. The C++ committee would rather add a 2D graphics API that no one cares about to the language libs then focus on binary compatibility.
I started .NET development about 12 years ago and stopped following C++ for that time; previous to that I coded purely in C, both professionally and in my off-time. At that time, I got the impression that C was faster and less prone to quirky, inscrutable API's than C, so I was in agreement with Linus on the decision to remain pure-C.
How is C++ doing these days with respect to compiler optimization and complexity of available API's?
Burn these heathens at the stake!!
any language that does things like hiding parameters being passed is not good for an OS kernel.
Interesting information.
And I wouldn't say that C++ adds much to maintainability - it rather contains both the bad sides from C and the bad sides from Java.
What would be more interesting is if part of the kernel was written in a language like Ada. I have already encountered operating systems where part of it was written in Cobol...
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
You're making that up. Linus's actual arguments against C++ for kernel is mainy rhetoric about "substandard programmers". The real issue is that Linus has no real experience with C++, therefore does not deeply understand its organizational advantages. Speaking as a longtime C hacker who did make the effort to figure out what C++ is all about. It's true, C++ is far from perfect, but on the whole it beats the crap out of good ole C along multiple dimensions.
When all you have is a hammer, every problem starts to look like a thumb.
C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)
I *do* like the ability to free up resources in a c++ destructor, but as he points out, that's not something you want to rely on in system software. The c++ committee has java envy.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
For a short while, the Linux kernel could be compiled as C++. Some developers, I believe Linus included, felt that the stricter type checking offered by C++ would help kernel development. There was no attempt to actually use C++ features though.
The effort did not last long.
Finally! A year of moderation! Ready for 2019?
There is (or rather i should say there's been a lot of progress towards) a standard C++ ABI. G++ has been following it since 3..0 days, and it really got stable around 3.4.
It's a bit off to be angry at the name mangling Name mangling incompatibility is actually a feature. It's purposely different to make things not link up because the real things (static function initialization, object layout, including virtual table layout, etc) are incompatible. Be angry that those things aren't standardized, or not enough.
If you want to know why C++ sucks for operating systems design, look at COM.
A fool and his hard drive are soon parted.
I wonder how much kernel they can throw out. There's tons of stuff in the Linux kernel that should't be there. If it can be done in a user space driver, it should be done there. USB devices, printers, etc. have no performance need to be in the kernel.
I'm sure everyone will believe your theory that linus just can't grasp C++'s advantages and that's the reason why he doesn't want to rewrite the entire kernel in C++
In a world with only C and C++, then C++ is undoubtedly the better language on balance.
In the real world, you can use C for stuff that it excels at, such as low-level components with clearly defined roles and easily sketched interfaces, where C++ only adds needless complexity. For everything else, you can take your pick of the dozen-plus, widely popular, well maintained languages which run circles around C++ for the things that C++ does better than C.
Okay, but why would you write an operating system in Javascript?
Get free satoshi (Bitcoin) and Dogecoins
If you want to know why C++ sucks for operating systems design, look at COM.
If you want to know why C++ is great for operating systems design, look at the Amiga Exec.
Which actually was written in C, but mapped flawlessly onto C++.
COM isn't object-oriented. You never actually had a handle on the object itself, just an interface.
The Windows kernel APIs are all C, there is no C++ in it. You can use a subset of C++ that doesn't require runtime support, but it is unsupported.
Linus hates C++ for a lot more reasons than ABI, and the majority of them are completely uninformed and show a lack of C++ experience.
All the understandability and maintainability worries people have about C++ in the kernel would be easily controlled by standard patch review. Don't like giant template metaprograms? Don't accept the pull request. That easy. Perhaps one of the valid reasons to keep C++ out of the kernel right now is purely that Linus would be unable to review such patches with authority.
Even simple things like classes, RAII, basic templates, and exceptions would do wonders for development.
That's what __attribute__((cleanup(function))) is for. Thank you, GNU C extensions!
I'd argue, that the primary usefulness of C++ is for large developer-groups, where at least some programmers have vastly lower experience. It helps compartmentalize various things and hide internals. This is not all that useful, when the software project at hand is an operating system kernel — newbies should not be messing with that to begin with.
The other benefit of C++ — stricter compiler, which will flag various problems at compile time — is rather marginal, because commonly used C-compilers (clang, gcc) can be (and are) asked to do the same flagging as well. For example, here are the warning-flags used by my FreeBSD system to build its kernel: -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -Wmissing-include-dirs...
In Soviet Washington the swamp drains you.
Heh. In my java programming I more often have C++ envy; I would _love_ to have real destructors. Most of my other gripes with C++ libraries are probably more a matter of familiarity than of real shortcomings. However, I cannot disagree with the point that for a kernel in particular, small/focused beats heck out of generalized libraries and behind-the-curtain operations.
In a world with only C and C++, then C++ is undoubtedly the better language on balance.
I would still pick C, and use it to write a higher level language compiler / interpreter.
C++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling
IIRC from Stroustrup, non-standardized name mangling is considered a feature because it acts as a public interface for many other non-standardized incompatibilities under the hood. Without it, it would be possible to link code emitted from different C++ compilers that would fail to interoperate properly in subtle and difficult-to-debug ways.
So it isn't quite fair to imply that if only name mangling were standardized the problem would go away: it would really require a very large enhancement to the standard that would deal with all the different ways that compilers do things now. That potentially involves a vast amount of work on understanding current compiler technology, much of which would likely be obsolete by the time the standard shipped. Ergo: compiler compatibility is unlikely to ever happen.
I'm not saying this is a good thing, just that it's a thing. I currently code in C, C++ and Python, and C++ is by far the most difficult, dangerous and awkward of the three (or of any language I've ever coded in, really) but the additional power does make it worthwhile in certain circumstances.
Blasphemy is a human right. Blasphemophobia kills.
> Linus hates C++ for kernel development because C++ can't guarantee a binary API from one compiler to the next due
He's should love it then, given Linux's driver API is as bad.
Back in the 1990s I worked on a large ATM networking driver written in C++ for OS/2. The driver was around 100,000 lines of code. It was quite fast and reliable code and fairly easy to work on. We also had a driver for Windows NT written in C. The C driver had fewer features and was a lot buggier, slower and was 360,000 lines of code. It was also harder to work on since C++ provided a lot of nice abstraction.
Now the C++ code only used a subset of C++ and it kept the data path fairly flat to help optimize speed. The actual overhead from using C++ vs C was fairly minimal as well.
The ATM driver was quite complex since it supported the full signalling stack and switched virtual circuits and ATM LAN emulation for both Ethernet and tokenring and classical IP over ATM using switched circuits.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
The next Netscape 6. C++ killed Netscape and will kill this idiotic project
Can anyone really argue with this:
Yes, mostly because it's crap filled with logical fallacies and a staggering ignorance of C++. I would respond, but someone already did it better:
http://ridosandiatmanto.wordpr...
I *do* like the ability to free up resources in a c++ destructor, but as he points out, that's not something you want to rely on in system software.
Don't see why not. Would you ever want to forget to unlock a mutex? Why not let the compiler guarantee correctness rather than have to do it by hand every time.
SJW n. One who posts facts.
Virtually all kernel functions return either NULL, true/false, or -errno for errors. No need nor desire for exceptions.
Just how would you do an exception inside an ISR, if you could even find a [credible/safe] way to implement them inside a kernel?
Uncaught exception === kernel panic?
Like a good neighbor, fsck is there
All the understandability and maintainability worries people have about C++ in the kernel would be easily controlled by standard patch review. Don't like giant template metaprograms? Don't accept the pull request.
Yeah, it will make developers more productive by making them spend time reviewing every single bit of code that gets submitted.
Oh, you mean like Linux does with Device Drivers...
I would still pick C, and use it to write a higher level language compiler / interpreter.
All the major C compilers which offer any kind of useful optimizations are written in C++. So you'd still be making heavy use of C++ under there.
SJW n. One who posts facts.
You should not free up resources in a c++ destructor. I guess that is exactly what Linus meant with his quote.
http://c2.com/cgi/wiki?BewareO...
http://www.codingstandard.com/...
C++ destructors can be used to deallocate any memory, or do other stuff that cannot go wrong. But they cannot be used to release any resources, like sockets, streams, files, connections, etc.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
If you want to know why C++ sucks for operating systems design, look at COM.
And if you you want to see why C sucks for operating systems, look at Windows ME.
Your point?
SJW n. One who posts facts.
With the limitation that C++ destructors cannot throw exceptions, why would you need them in Java? a close() method is just fine in Java, because you don't need to deallocate any memory. So what would you do in Java with destructors?
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
C++ is an enormously powerful and comprehensive language, and it relies on the programmer or organization to use a reasonable subset of it and use good judgement in applying any given feature. I would grant that poorly written C++ is probably much worse to detangle than poorly written C. However, well written C++ is just as usable and maintainable as well written C. More critically, C++ interfaces and methods can be written in such a manner as to provide much better protection to the programmer from his own mistakes. It's much harder to do that in C. In today's security-conscious world, where a single mistake can mean a critical OS vunerability, that's a real issue.
Essentially, C++ is C plus the ability to create powerful abstractions, typically expressed in objects/classes and templates, but not necessarily limited to those. Those abstractions put more of a burden on the compiler rather than the programmer, and as a result, is much safer than anything one could write by hand. All raw memory buffer manipulation, for instance, can be done through carefully protected wrapper objects or other user-defined primitives, and there's no reason in modern C++ to manipulate object lifetime through raw pointers, as it now has standardized smart pointers. Any resource - memory, file, locks, handle, etc, should be lifetime managed by objects - and so modern C++ should feel a lot like a garbage-collected language. In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management (e.g. IDisposable in C#).
It's certainly not a language suitable for all tasks, and it arguably requires more expertise than C to use it well. However, systems programming is absolutely one of those things it's well suited for. Binary compatibility would be great to have, but is not a real hurdle. To work around it, you can simply fall back to a C-like API at module boundaries, and avoid passing any objects across. That's what I typically do when I have to write C# C++ interop layers, and it's worked pretty well for me. While it brings along a lot of cruft, C compatibility, including it's binary compatibility, is one of C++'s great strengths as a language.
Irony: Agile development has too much intertia to be abandoned now.
One of the real powerful things about C, especially for writing an operating system, is that a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated. In the presence of C++ inline functions, implicit type converters, copy constructors, and assignment operator overloads that ability goes right out the window. If you were managing a project that involved lots of small contributions from a large and widely distributed group of developers that inability to see what a small patch does would be fatal.
On a more subtle level, C++ rewards a well-thought out design that doesn't change very much, and mercilessly punishes a design that is produced incrementally in an evolutionary fashion. Given how Linux has developed over the years, C++ would have been a brutally punishing language for Linux.
I like C++, I've used C++ in quite a few projects. I will probably use C++ again. But I can easily see why the Linux kernel is not a great place to use C++.
You're making that up. Linus's actual arguments against C++ for kernel is mainy rhetoric about "substandard programmers". The real issue is that Linus has no real experience with C++, therefore does not deeply understand its organizational advantages. Speaking as a longtime C hacker who did make the effort to figure out what C++ is all about. It's true, C++ is far from perfect, but on the whole it beats the crap out of good ole C along multiple dimensions.
I take it that only luddites and sycophants are moderating this thread. Look, Linus has many great qualities for which I admire him, but sometimes he just drops the ball. Other examples: initial refusal to use any form of source control. Initial refusal to allow an in-kernel debugger. Plenty of other examples. Eventually he usually figures these things out eventually, but it can take time. Sometimes ridiculous amounts of time.
When all you have is a hammer, every problem starts to look like a thumb.
I cannot see how introducing something like C++ will improve the situation. Changing the langauge doesn't get rid of evolutionary code, nor does it fix people's thinking. I can't fault the guys who evolved the musb driver into a working piece of code - the crux of the problems originate with the original Mentor documentation: Unavailable, poorly coverage of errata, poor detail on what the hardware block is doing.
What is required for good drivers are:
If hardware vendors wish to compete for embedded linux systems, then they should promote their performance on how well they do on the open test suite with their linux drivers - not just on their arm core's performance.
-bms
Uncaught exception === kernel panic?
That's one way to force device driver writers to get their shit in order...
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Correction:
, is that a good C programmer can look at a piece of well written C code and have a pretty good idea of the machine code
I've had to maintain some real winners of C code where the programmer went hog-wild with macros. UGH. It was easier to rewrite everything than to understand what was being done.
I think we've pushed this "anyone can grow up to be president" thing too far.
So C++ sucks for OS design because the team that designed COM sucks at OS design?
Microsoft Windows uses C++ -- albeit with the CRT (C Run Time) library separated.
The source to ntoskrnl.exe, and the *.sys files it loads, is primarily C++, not C?
So what would you do in Java with destructors?
There's more resources than just memory. Files, sockets, database handles, mutexes, unlocking mutexes and so on and so forth.
SJW n. One who posts facts.
Java handles unicode much better than does C++. It also handles strings better. And synchronization between threads.
N.B.: You *can* do all those things in C++, or even in C, but they're much nicer in Java.
OTOH, I despise the UTF-16 coding used by Java. Enough so that I generally prefer Python or Ruby. though if I don't need specialized libraries my real choice is D (Digital Mars D). See http://dlang.org/index.html .
This, however, doesn't mean that I think Java, Python, Ruby, or D are appropriate languages to write an OS in. For I deem that the best choices are C or Ada. You *could* do it in D, but you'd need to disable many of it's more desireable features for much of the code. (There are times when you really don't want garbage collection or the layers of indirection that make objects flexible. In D that means you don't use classes, but you can use structs.)
I think we've pushed this "anyone can grow up to be president" thing too far.
The name's just factually incorrect . What they really should have named it is ++C.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
The Linux kernel makes heavy use of big ugly, hard to maintain or read macros that generate arbitrary machine code. No matter how good you are, you won't know what code is being generated without extensive analysis. In any case, the exact same ugly macros can be used by C++, if you are really wedded to that kind of bad taste. C in fact has no addtional features in this area, it only lacks features that C++ has.
If you want to point at features that C has which C++ does not then you get a very small set, which in the case of the kernel consists mostly of designated initializers.
When all you have is a hammer, every problem starts to look like a thumb.
Which is why you call close() as the parent mentioned. Really, C++ developers who have to manager all their memory complaining they don't know how to close an open resource when they're done. Even in C++, you shouldn't leave things open when you're done with them.
That easy. Perhaps one of the valid reasons to keep C++ out of the kernel right now is purely that Linus would be unable to review such patches with authority.
Sounds like someone needs to send Linus some free C++ training <EG>
Actually, there's a proposal being put together by Herb Sutter for providing a standardized ABI.
Are not for systems programming. Sure, you can make it work and you may even come up with a largely elegant design, but for those of us who are well versed in C and assembly, and in systems programming in general, the best abstractions are structs, unions, typedefs and preprocessor macros, etc. They are simple enough to be useful abstractions, but not so complicated as to obscure what the code is actually doing (such as cout vs kprintf() ). I would rather try to understand and maintain someone's C code than C++ code anyday.
The c++ committee has java envy.
Other way around.
In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management
The importance of this is underestimated. With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.
I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion. In C++, you can just monitor heap size, and alarm based on values and trends and all that good predictive jazz. In Java, even with the better garbage collector designed for servers, "bouncing off the roof" is the norm, and it's quite hard to tell when danger is approaching.
I'd be interested in any /.er advice here - is there some dependable way with Oracle Java to measure "real heap size" - the total size of objects actually in use? The better garbage collector for servers (G1) never pauses the world to free everything it can, so it's not like you can look at post-collection heap size or anything.
Socialism: a lie told by totalitarians and believed by fools.
Alan Perlis said:
Everything should be built top-down, except the first time.
The work on the Linux kernel by Linus is essentially the "first time" which is why he prefers C. It can be used as a bottom-up language. OOP and C++ are top-down. The BOSS-MOOL group are rewriting something that already exists so they are using a top-down approach. Both Linus and the BOSS-MOOL group are using the right tool for the job. The jobs are different so the right tool is different.
We don't see the world as it is, we see it as we are.
-- Anais Nin
Like gcc, oh wait, not that is written in plain and simple c.
Every sufficiently large C project re-invents key portions of C++, poorly. I've been involved with a couple such efforts myself. There's just no excuse for the NIH-ism. The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
Socialism: a lie told by totalitarians and believed by fools.
Most of what people want to do in C++ could be done in C if they just thought it through better. True you don't have the same level of fake(because we don't really know behind the seens if it the compiler isn't making holes but we don't know this with C either) protection of class inner variables vs structs inner variables. But structs exist in C and can more or less be thought of as objects. You don't have the is a relations but much of that can be done with has a relations. C++ does have a lot of nice features if they ever do fork linux it would be Linux++.
Linus hates C++ for kernel development because C++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling.
extern "C"
According to Linus' logic a Ferrari with 600 HP is better than one with 700 HP because he doesn't use the extra 100 HP. In addition some people he knows would crash a 700 HP Ferrari. I think Linus is full of shit and bad drivers shouldn't be given Ferrari's to drive.
With the limitation that C++ destructors cannot throw exceptions, why would you need them in Java?
To explicitly reclaim the memory immediate on a small memory footprint requirement environment, instead of waiting until "the GC fucking feels like it, at the worst possible time", which is when I need more memory for something else.
It's one of the reasons I dislike some of the Objective C changes to use autorelease pools as well. Any language which requires GC'ing to reclaim unused memory is totally unsuitable for small memory footprint applications.
One of the real powerful things about C, especially for writing an operating system, is that a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated
Do people not debug through object code any more? I've done that so many times when trying to understand a bit of cryptic C++ code or C macrology. There's no mystery possible - just look at the generated object directly if there's any doubt at all what's going on!
Socialism: a lie told by totalitarians and believed by fools.
I'd have things automatically close()d when they leave scope instead of requiring the programmer to remember that this item needs a close(). The new automatic close feature in try blocks is close, but the project I'm working on isn't using that version of java yet.
Like gcc, oh wait, not that is written in plain and simple c.
You misspelled "was". The compiler was switched over to C++ a few versions ago and they're now using C++ features.
SJW n. One who posts facts.
Hold on - you're saying that you'd currently trust unreviewed patches in a kernel? Are you fucking insane?
How is adding an extra debugging step better than just not needing it in the first place?
- Michael T. Babcock (Yes, I blog)
TLDR: Linus is right.
Looking at the project, I stumbled over the fact they did rewrite an ethernet driver and have rewritten it in C++ with a 2% performance overhead.
Well, this does not sound much but (a) it is a regression in performance in a perfectly well functioning component - so basically unacceptable, and
(b) if a single driver already shows such measurable overhead, this raises question whether the whole approach is suitable at all.
"If you want to point at features that C has which C++ does not then you get a very small set,"
The biggest feature of C is simplicity. The C language standard is literally less than 1/10th that of C++ when you exclude library specifications.
The Linux kernel maintainers are constantly battling with GCC, because GCC takes what little rope the standard gives them and runs with it. If the kernel maintainers were dealing with C++, the problems would be 10x worse.
And the things that the kernel uses macros for wouldn't be solved by C++. Have you actually analyzed all the areas of complexity in the Linux kernel today? Look at, for example, run-time code generation, where macros insert NOP instructions to be replaced by dynamically generated code for optimization or debugging. Not only wouldn't C++ address that, it would make it more brittle and fraught with problems. Or RCU. How the heck is C++ going to make RCU easier to use and still be performant?
You might think that C++ would at least make writing drivers easier, given templates and OOP syntax support. But once you factor in all the present complexity--DMA, memory management--and the need to refactor core assumptions in the future, what's vastly more preferable than syntactic sugar is simplicity, simplicity, simplicity. And while C++ can make code look more concise, that doesn't necessarily equate to more simple.
The C++ dream of writing a small bit of code which can be reused through inheritance or templatization, allowing the code and the caller to evolve independently, is a pipe dream. Somebody on ycombinator analogized this dream of creating the perfect type hierarchy with the pursuit of ontologies generally in the 1990s and 2000s. Once you understand that, the value of C++ is seriously diminished.
Use the best tool for the job; for kernels the best tool for the job is today is C. If you find yourself "needing" C++ to address some problem, you're almost always better off rethinking the problem. Look at Plan 9. They solved the issue of growing complexity not by changing the language. Plan 9 uses C (many C99 features came from Plan 9). Instead, they made system engineering easier through message passing, a la 9P, leaving language-level OOP and templates in their dust.
Parent poster here. You know what, you just stumbled on the perfect solution to force code and security audits. Make everyone write things in C++. Everyone will HAVE to review the code. Truly, the open source "many eyeballs looking at code" in action.
> Don't accept the pull request. That easy
Until someone's on a deadline, and accepts it anyways because "I'm on a deadline, my manager needs this now." And then a few years later, you're right where C++ inevitably leads you: a pile of horrible-to-maintain gobbledygook. The slippery slope of C++ features is too simple to get started down, and too easy to climb back up once you've been down it. The fact is, the only sane set of C++ features that exist all exist in C, so you're better off using C to begin with.
I don't really think the Linux kernel does badly, and it does not need C++ to do better.
Considering that most new phones are being released at 2 GB+ configurations, I care less and less about 'small embedded systems that are becoming more and more niche and obscure'. Sure memory optimization is good, but when resources are short GC's work harder and more often. If anything embedded systems are suited for GC language runtimes just fine, but they waste more CPU cyles for the privilage. The advantage with GC runtimes being that you don't get memory leaks (in the C sense of never being able to reclaim the allocated ram except for restarting the app, sure people can hold ram in allocated by forgotten places, but that's nothing specific to GC runtimes).
Bye!
And I wouldn't say that C++ adds much to maintainability -
Actually, it does, by giving you abstractions instead of you having to write them yourself as you do in C. In the embedded world, there's a term: "C with classes": this is when C++ is used on embedded systems, but only a small subset of C++. The code looks pretty much just like C, but there's classes and inheritance, but many other things are specifically omitted, such as exceptions. In aviation (DO-178), there's standards for using C++ in avionics systems, and here again, they specifically forbid the use of many C++ features which prevent determinism, such as exceptions.
If anyone's going to write a kernel in C++, they should just follow the FAA DO-178 standards.
The C++ dream of writing a small bit of code which can be reused through inheritance or templatization, allowing the code and the caller to evolve independently, is a pipe dream.
Rubbish. You don't need to look any further than the "max" function to falsify that claim.
When all you have is a hammer, every problem starts to look like a thumb.
Unless the problem domain is quite simple, you need complex code to solve complex problems. And complex code always evolves into mysterious cruft, given sufficient time and coders involved.
Sure, sure, some "code base" that one guy wrote in a few months? Very obvious and clear results are possible. But a real project with a few programmer-centuries of code? I've worked on assembly code where looking at the object was the only way to be sure of what it did (to see what the macros expanded into). And C is no angel when it comes to clarity of poorly-written code!
Socialism: a lie told by totalitarians and believed by fools.
Worse, his counter-example is broken, since most if the code is missing - even when you look at the page in source view.
And I've seen c++ programmers make the same mistake about putting strlen() in a conditional test. More efficient code wouldn't use either strlen() or a for() loop, but take advantage of the fact that strings in c are null-terminated.
As for the ending:
The fact is: Look at almost any complicated data structure made in C, and it will almost invariably be a horrible mess which is very error-prone and extremely hard to understand and maintain.
I’m not saying that many such data containers made in C++ aren’t a mess. However, C++ at least offers you the tools to make it cleaner. C doesn’t offer you anything (after all, it’s a “sparse” and “straightforward” language) and thus C constructs tend to look like a huge mess.
Have you looked at the mess that is the string class in the stl? Even that is fugly. When I use c++, I write my own classes, not because I can, but because I want code that I know will behave the way I expect it to. The extra time to hack together a minimal string class and debug it is more than paid back when trying to figure out where something is going wrong. And that goes for pretty much any container class. If you can't write your own basic c++ containers, how the heck can you be expected to design (or even understand) something more complex?
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
You never actually had a handle on the object itself, just an interface.
I believe that's called abstraction.
C++ is an enormously powerful and comprehensive language, and it relies on the programmer or organization to use a reasonable subset of it
I use a reasonable subset of C++, I call it C :)
Well strictly speaking, C is not a subset of C++ but I consider it good form when writing C to also make if valid C++.
And what you are saying about memory is true in userland code but in the kernel allocating memory is no trivial task. You have to think about paging, DMAs, etc... and your pointers may point to devices rather then memory. Another problem with C++ is that it is hard to know exactly what code is executed and when. With C you just need to follow the code without worrying about a constructor being called or an operator being overloaded. The kernel is a place where you really want to control such things.
It is possible to do kernel level code in C++. I did. But the code was more like "C with classes" than real C++. You can do it the C++ way (within reason) but it would require extreme levels of expertise.
Because the compiler cannot guarantee correctness. That you think so is what make C++ and C++ developers so dangerous, especially in kernel space.
The only thing C++ solves in kernel development are problems that nobody cares about. Replacing macros with templates and long function names with namespaces buys the kernel developers precisely nothing.
Is C++ going to solve RCU and complex atomicity issues? Is C++ going to make run-time dynamic code generation easier? (That is, replacing NOP instructions at boot time for optimization and debugging.) No. In fact, C++ is worse for these things because C++ does too much implicitly, which makes it harder to reason about the code.
Before you opine on why C++ is better, why don't you download the C++11 and C11 specifications and read them thoroughly. Then contemplate how you'd write implementations for those. Then reassess how much, exactly, C++ simplifies anything.
Too many developers believe that as long as you _hide_ complexity, it has no cost. If it doesn't look complex on its face, how could it possibly hurt? Or by ignoring a feature you think it's magically disappeared. That's wrong on so many levels that it's difficult to even have a rational conversation with people who think that way.
and will the binaries of that compiled C++ be 100% portable? no?
If you're going to OO the kernel -- skip C++, and make it Java. At least you get the type checking, which I'm sure today's kernel devs will hate to the 9's, but could be a huge benefit in cross compatibility AND consistency w/o building gigantic teams to maintain it--I'm looking at you ARM implementations. You all may laugh at that idea, but LLVM is basically the same idea.
C++ destructors can be used to deallocate any memory, or do other stuff that cannot go wrong. But they cannot be used to release any resources, like sockets, streams, files, connections, etc.
More precisely, destructors can't be used to perform any operation which (a) may fail and (b) could be handled by the calling code (retry, communicate it to the user, attempt some thing else, etc.). If the calling code can't do anything about the failure anyway, then it really doesn't matter that the destructor has no good way to communicate it.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
And that works for the vast majority of programming that most programmers are going to be doing. Most of the time where I run into impossible things, it's either due to trying to use threads (UNIX-style signal handling with threads !#%!@T!) or an overly-complicated design that needs to be simplified. Or, sometimes, both.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
unhandled error case === kernel panic?
Compuware APM can enable you to better monitor & diagnose your java processes.
Well, one way, you can monitor heap usage and trend the usage immediately following full GCs.
The free space in absolute numbers only matters if you are allocating very huge things. Arrays can double their size when growing to minimize resizing operations, so that can cause you to run out of memory without... really running out of memory, for example. Say 2gb is used of a 4gb heap. A 1gb array slowly fills up and resizes itself by allocating 2gb to copy itself into, that just filled the entire heap.
Personally I suspect that's more a code problem, but you might have to deal with it just the same.
The other way to look at it is as a function of time.
Sample time spent doing garbage collection over some period and calculate % of time doing GC.
It's like your garage, where absolute space matters only when parking the car, but in general it slowly fills up until you cull the garbage. It's more efficient to throw twice as much stuff out half as often than constantly drag things to the curb. So at maybe a constant 10%+ GC-time consider increasing your heap.
This isn't GC centric advice, firing off rapid mallocs isn't cheap either.
macro is web scale.
For most programs, the proper behavior on an error is to abort, then fix the program logic or repair the busted hardware. Assertions, etc ...
As for why you'd want to allocate a new resource (the 3rd example in your first link) in a destructor, that's such an obvious no-no that I wouldn't even think of it in a million years. That is a very contrived example.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
In the novel Jurassic Park, Dennis Nedry disabled the park's security by disguising a backdoor function call as an object constructor in what was pretty clearly a C++-like language, in an attempt to pull a fast one on anyone who might audit his code. (The novel had screenshots of his IDE and everything; wonderfully geeky.) That C++ enables this sort of behavior makes it complicated and risky to use in certain scenarios. I can imagine kerbnel developers blanching at its use, or keeping it to a restricted subset.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
If there's a platonic ideal of what C with the features everyone re-invents is, C++ itself is a damn poor approximation of it.
Yes the actions of a fictional charactor in a book should dictate technology discisions.
Haha, lol, WAS. gcc is now written in C++. Because, it's better. Oh? What's that? You disagree?
Well, I think the gcc authors probably know what they are doing. Whereas you don't know what they're doing, and you probably don't even know what you're doing.
In the presence of C++ inline functions, implicit type converters, copy constructors, and assignment operator overloads that ability goes right out the window. ... and just do what the author put into them? ... sorry ... I expect a primitive ability of reading C++ code from anyone I would hire for a C job.
Please don't say that in a hiring interview.
You are unable to grasp when a copy constructor or an assignment operator is called?
You are unable to determine if one or both are compiler generated or manually written
Wow
You really honestly want to tell me that you can not understand what is going on just because it is C++ ????
??????????
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
First line of the email is: "*YOU* are full of bullshit."
Well, at least we know for sure that it was really from Linus!
You must be either pretty bad in debugging or stumble over compiler bugs quite often.
There is no difference in debugging source code versus object code, unless there is a compiler bug.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
That assumes you have a nearly unlimited stack.
Try that with a 4k stack...
It is irrelevant what language feature he used. ... directly in C, directly in C++, via a Python wrapper, with Java JNI etc p.p.
If there was a library routine to call to open a door he could have called it in any way
Pulling out a C++ mythical constructor only makes you look pretty dump!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
How about if the kernel was written in Pascal? HP did that with early HP-UX for the HP 9000 Series 500. Like most Pascals of the day, it had extensions, and HP called its flavor "MODCAL". I guess what I'm saying is, this isn't surprising, and if you can satisfy the requirements of the system call interface and section 2 of the manual, the result can be usable (though HP-UX on the series 500 had some userland-visible oddities).
And all those resources are closed just fine by Classes that implement the Closable interface and objects that are used in a
try (object)
statement. ... sigh!
You Java knowledge is 5 to 10 years behind modern Java
And for fuck sake, Java has build in support for multithreading, a mutex is not acquired by a constructor nor is it released by a destructor, for that we have a keyword: synchronized. Since Java 0.7 I believe.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
It still points up problems that make debugging VERY hard.
But you do know that "small memory" VM try to reclaim memory during the 'new' or 'alloc' call and don't have a GC which is waiting till 'all memory is consumed'? ... you have no clue. Sigh, 30 years of computer science wasted in stupid IBM vs MS vs Sun vs Apple vs Oracle wars. ... (yes, that adds up to 40 years, your turn?) /. claim of a 25 year old and say: wrong!
Guessed so
I guess I mentioned often enough that our days computing experience is minimum 20 years behind what *I* learned at my university 20 years ago
You can basically pick a random
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
> You really honestly want to tell me that you can not understand what is going on just because it is C++ ????
Why should the interview candidate be any smarter than the average C++ compiler?
You must be totally unfamiliar with obfuscated code, and its natural emergence in a code base over time. With C macro craziness, you can of course run only the pre-processor on the C code to see what the macros actually expand into, but who knows that command-line argument without looking it up? Seeing the object is a couple of key-strokes in a modern IDE.
With C++, the language is too large for anyone to be familiar with all its dark corners, so when you discover that some oddball thing you're trying to do is already there in the language, but you've never seen that language feature before, and your attempt didn't behave as you expected? You can try reading the standard, if you have it handy and are good at standardese, or again a couple of keystrokes and you see what's up.
And I'd like to see anyone who gets bitten by
if (BIT_FLAG == foo & BIT_MASK)
and doesn't spot the problem right away figure that one out without looking at the object.
Socialism: a lie told by totalitarians and believed by fools.
Java is easy to monitor, easiest is to enable snmp to the JVM, the second is jmx. :-)
C/C++ however aren't limited to a fixed predefined memory segment like Java and why did you even mention java in a C/C++ conversation...
To be fair: So is C.
Who ordered that?
rewrite it in haskell
Well, one way, you can monitor heap usage and trend the usage immediately following full GCs.
The other way to look at it is as a function of time.
None of that applies to modern server-centric garbage collection (GC1). "Stop the world while I collect garbage" makes a server worthless if you have 64 GB and GB takes minutes, which is why the default GC for the server SDK hasn't worked that way since mid Java 7.
Socialism: a lie told by totalitarians and believed by fools.
With C you just need to follow the code without worrying about a constructor being called or an operator being overloaded.
Until your compiler starts optimizing things.
Or anyone mentions "#define".
Or you have to worry about concurrency.
Or interrupts.
Or memory-mapped I/O.
The claim that C++ does lots of magic but C does not is one of those mythical ideas that makes us feel better about deciding to use C for some systems programming job, but really there's plenty of magic that goes on in both. If you're working on things like operating systems or device drivers, you simply have to know how your code is going to compile in all kinds of situations. Next to that, the differences where C++ systematically provides for things like construction/destruction or overloading are relatively minor concerns.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
And, THIS, ladies and gentlemen, is why we live in a computing world of utter shit and garbage.
If, in practice, the whole 'distro' is compiled using the same compiler, i.e. g++, then it matters not about a standardized binary API?
You glossed over the "or resources" part of Greyfox's comment.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
While the project has a nice goal, I'm pretty sure this project will fail in the long term, and will not be able to catch up. And that's because of the fast pace of Linux kernel development.
Linux kernel 3.15 was released in June 8, kernel 3.16 was released in August 3, and already kernel 3.17 is in rc-7. Probably will be released in a week or two at most. That means every kernel is released around 2 months difference. Again, sadly doubt it that company will be able to keep up with the kernel development.
If they want to modernize something that doesn't evolve that fast, they should try BSD instead.
GTK+ and GNOME are great examples of what you're talking about.
They consist of millions of lines of C code that poorly imitates C++.
One of the real powerful things about C, especially for writing an operating system, is that a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated.
For better or worse, that hasn't really been true for a long time now. Modern processors and the related architecture have become so complicated that generating correct, efficient code is an extremely specialist skill. Once you move beyond toy examples with basic flow control and arithmetic, it's common today that what you get out of a C compiler won't seem to bear much resemblance to what you put in, unless you happen to be one of the handful of people in the world who really is an expert in compiler technology and code generation on your particular platform.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Am the only one who things COM is pretty nifty? I like being able to write components in different languages and have them all work together. You just have to get used to thinking in interfaces.
I've had to maintain some real winners of C code where the programmer went hog-wild with macros. UGH.
I sympathise, my first experience writing commercial code in C++ was in the early 90's with the Watcom compiler of the day. Their implementation of C++ was not part of the language, it was a complex layer of C macros that served as wrappers for goto statements, function pointers, etc. I had learnt about OO concepts from smalltalk a couple of years earlier while studying for my degree, the Watcom macros were what I'd call a "sociopathic implementation" of some of those ideas.
The mistake Watcom made back then is the same one many developers are still making today - "object orientated" is not a language feature, a layer of macros, or a bunch of library calls, it's a powerful and ubiquitous design methodology.
For example, if you look carefully at the examples in K&R's "C programming language", most are excellent demonstrations of OO design that were written long before the term "OO" was invented. The elegance that many developer's perceive in K&R's famous examples is not in the syntax, it's in their design.
Next up - "Spaghetti code" is not a language feature.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
and will the binaries of that compiled C++ be 100% portable? no?
Sure they will, just as much as binaries compiled from C source. If you're writing libraries which are distributed in binary form (or used as shared libraries), then you have a bit of a portability challenge, but only a bit: You just have to make sure that all of the entry points follow C conventions. This may be an unfortunate restriction, but it's a restriction that applies to C as well.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I've yet to see any binary for any language, including C, compiled for x86 able to run on an ARM or any other CPU Architecture. portable binaries are an oxymoron.
Oh, close when the scope leaves. It would be great to have that in C++.. oh.. right. I already do have that. The dtor of the FileThingie class does that when it is removed form the scope... so.. I guess you can keep reinventing RAII.
Wow, what horrible observations.
Good thing C++ solved #define's, compiler optimizations, concurrency, interrupts and memory-mapped I/O! Such a difference that language makes.
Hidden mallocs, RTTI, exceptions, these are things that kernel programmers dream of...only not in a good way. ;)
It's not about what Linus wants, it's about what it takes to keep project relevant by attracting talented new developers. There is no way I am doing new work, especially an unpaid hobby project, using plain C in 2014. Automatic destructors and templates would be a step in the right direction, but what we really need is to be able to write user mode device drivers in Java and Python. They will suck, no doubt, but far less than not being able to use the hardware at all. In the end, perhaps Linus should have listened more to Andrew Tanenbaum. With less monolithic OS, people would be able to write key services in any language they want.
Abstractions aren't ever given to you. All code is written and abstractions can be accomplished in C just fine, thank you.
People seem to forget that C++ was originally developed as a preprocessor for C. Anyone who says things can be done in C++ but not in C has an existence proof to the contrary.
It's not just easy to follow standards, your tools have to follow them as well. Unlike C, C++ typically requires linking with mandatory libraries and those libraries mandate things like exception handling. Not everyone has the luxury or resources to fight such problems.
I suspect you haven't probed the dark corners of C++. It does all sorts of useful things. So many people think of C++ as "C with crazy OOP class hierarchies", which isn't the point of the modern language at all, ancient MS GUI crap nonwithstanding.
Some neat things that C++ makes easy: "slab" allocation, strings and arrays that know about page boundaries for explicit page management, a system where whenever you de-reference a pointer to an important struct, you automatically check the validity of the struct (really is the type you think it is, hasn't been freed and/or re-allocated), That's all stuff I've been involved in doing the hard way, which was quite silly of us.
Socialism: a lie told by totalitarians and believed by fools.
Considering that most new phones are being released at 2 GB+ configurations, I care less and less about 'small embedded systems that are becoming more and more niche and obscure'.
Being able to write an efficient program will never become an obsolete skill. If you are using excessive memory, that means your program is wasting CPU cycles. It means you are running my battery down and making me wait for your bloated program to load.
mercilessly punishes a design that is produced incrementally in an evolutionary fashion.
Type hierarchies are not to be taken heavily in such code. Expendable, hierarchical state-machines are more understandable and more easily communicated than a class hierarchy containing one, big truth of the kernel universe. The choice is similar to the one with C programs: make the system more modular, or more like spaghetti of function overrides with a chance of Liskovian meat balls.
What you just wrote is kinda like "if you want to know why C sucks for anything look at IOCCC".
Actually, now that I think about it, it makes even less sense, because COM is a language-agnostic ABI - it doesn't have anything to do with C++.
There is actually an ongoing effort in the ISO C++ committee to come up with an ABI standard.
You realize this is irrelevant to kernel programming, right? Device drivers are not applications.
It's sad that so many people think that memory leaks are the end-all definition of code maintainability.
Can anyone really argue with this:
Nope, and I've been writing both C and C++" since before the STL existed. :)
However the phrase "the STL is stable" does not imply a particular implementation from a particular vendor will be complete....or even work. Same deal with the CRT.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
I hear the "C++ is doing things behind my back" argument all the time, but that pretty much goes against every recommended practice out there. Most programming experts recommend against hiding complex operations behind "hidden" methods (and that's not unique to C++ either). If you call an overloaded operator and it's doing a bunch of crazy things behind your back that you didn't expect, it's a very poor interface, and not necessarily the fault of the language. In fact, C++ gives you a lot of tools to help you know what's going on behind the scenes of a member function, for example. If a function is declared const, you know that it's not affecting the internal state of an object. Likewise, if you're passing in a const reference, you know it can't be modified inside the function. Also, C++ 11, with better support for r-value semantics (think temporary variables), has eliminated a lot of hidden constructor/destructor costs when objects are moved around.
I think it's perfectly fine to use C with classes if that's what suits you personally or the task at hand. The entire point of C++ and it's compatibility with C is that you can use as much or as little of the higher-level abstractions as you need. Simply wrapping a resource inside an object is enormously powerful all on it's own, because it's nearly impossible to then leak that resource or use it improperly since you're protecting access to it, and using the compiler to enforce that proper access.
C++ programmers do tend to be their own worst enemies at times, endlessly looking for clever language tricks to massively over-complicate their code when a simpler if slightly less elegant approach would end up being about 10x easier to read, understand, and maintain in the long run. I'm actually not a huge advocate of using new language features until it's absolutely clear that it makes the code simpler and more maintainable in the long run. Take for instance C++ lambda functions. They're enormously handy for passing first-class member functions as callbacks, say, to a UI system. Any C++ programmer can look at the following code and see exactly what it does (despite the rather ugly syntax):
okButtonParams.clickEvent = [this]() { this->OnClickOK(); };
Even for non C++ programmers, it's probably not hard to guess that this is simply providing an OnClickOk() member function callback to a button (this comes straight from my game code). There's no magic there. The compiler is implicitly creating a small object that stores the object's 'this' pointer, and invokes it's member function on demand. C++ (and C) famously adhere to the zero overhead principle - that is, you don't pay for features you aren't using. In this case, the optimized result of storing and invoking a pointer is exactly the same as if you had passed in a function pointer in the traditional C style, only this is much safer AND more readable.
C++ certainly is a more difficult language to master than C, but I definitely think the payoff, in terms of code safety and maintainability versus performance, is certainly well worth the investment.
Irony: Agile development has too much intertia to be abandoned now.
There's a big difference between "portable binaries" and binaries you've chosen (compiled for x86) that are specifically not portable.
There is such a thing as a portable binary. What do you think a p-code machine is?
I *do* like the ability to free up resources in a c++ destructor, but as he points out, that's not something you want to rely on in system software.
I also like that ability, and I think it would be great to rely on it in system software. Unlike my unreliable brain (squirrel!) the compiler never forgets to call the destructor at the appropriate time.
Perhaps I'm missing some reason why it's not a good idea to automate that task?
I don't care if it's 90,000 hectares. That lake was not my doing.
And I'd like to see anyone who gets bitten by
if (BIT_FLAG == foo & BIT_MASK)
and doesn't spot the problem right away figure that one out without looking at the object.
Never underestimate the power of interrogation-via-printf() ;^)
I don't care if it's 90,000 hectares. That lake was not my doing.
Java has JMX which can be used to do this much better than C++ can ( at least without a ton of effort ).
With Java you get this all out of the box. You can point a JMX console to your Java Runtime and monitor with zero code. Or use java.lang.management package programmatically.
It seems you missed my point. Both C and C++ have huge amounts of non-obvious things going on under the surface with modern compilers and processors/hardware architecture. The parts of C++ that add further implicit behaviours really aren't that big a deal in comparison, and ruling out C++ for systems programming on the grounds of magic happening and expecting C to be much better in that respect is highly optimistic.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Don't get your point.
The code example you gave is pretty clear.
The problems of macros and compiler arguments has nothing to do with C versus C++ programming/reading/debugging. No with any other language. Either you "speak" the language or you don't. Copy constructors or operator= don't add any "obscurity" to C++. ... problem solved.
They are simply shortcuts you would program your own in C with memcpy() if you needed them.
Proclaiming: that can not be grasped because we don't know if there is a copy ctor or an operator= involved is nonsense. Their existence is clearly visible in the header and their implementation in the Cpp/C++ file.
If you want to debug them, you place a breakpoint there
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
No, no, I've seen them leak memory, too. Java seems to inspire some incredibly sloppy programming. "Oh, we don't have to worry about memory anymore! Let's make a 30MB string and pass it around like a... STRING BONG!" And our production MQ server leaks file handles so fast that it's best to just have a cron job that reboots the system once a day :-/
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
NTOSKRNL and Base Drivers are all C and ASM bits my friend. Only WIN32K (Win32 Kernel Mode Graphichs and helper functions core) contains some C++ bits, specially DirectX DXGI/D3D functions.
NTOSKRNL and Base Drivers are all C and ASM bits my friend.
...as I suspected they were.
So "Microsoft Windows uses C++", if it's talking about kernel development (as suggested by the title of the thread), is mostly wrong, with...
Only WIN32K (Win32 Kernel Mode Graphichs and helper functions core) contains some C++ bits, specially DirectX DXGI/D3D functions.
...one exception.
OS X uses C for kernel development, except for I/O Kit and I/O Kit drivers, which use C++, but restricted to a subset that excludes exceptions, multiple inheritance, templates, and run-time type inference. (Well, some stuff outside of there that needs to use I/O Kit APIs might use C++; the AFP and/or SMB client VFSes - I forget which - had, at one point, a small C++ chunk of code to allow the file system to prevent sleep to keep TCP connections to the server from being dropped. The rest was C - not surprising for the SMB client VFS, descended as it was from Boris Popov's SMB client VFS for FreeBSD.)
C++ is an enormously powerful and comprehensive language, and it relies on the programmer or organization to use a reasonable subset of it and use good judgement in applying any given feature. ......
Good judgement... made me giggle.
At this point C and C++ are both just wrong for a long list of reasons....
However there have been advanced in database technology and programming
language design to a degree that one could be optimistic.
Knuth worked with a language subset to craft TeX and Metafont... translators like p2c
took that cautious work and emitted C.
There is almost no assembler left in Linux because of compiler improvements.
In a decade one might say "there is almost no C left".
C++ has power and is an interesting choice but the ability to muddy the
design standards with C is just too easy.
Perhaps it is time to dust off some of the good old languages and make
a short list -- and design the next player.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
To work around it, you can simply fall back to a C-like API at module boundaries
And thus losing the entire reason for using C++ in the first place.
The whole point of this project seems to be that they want drivers as C++ classes.
If you do that then you end up with a giant mess of wrapper functions to translate calls from simple C to C++ object calls.
Seems like a lot of trouble for little to no benefit.
You are unable to grasp when a copy constructor or an assignment operator is called?
I'd say that's not exactly trivial to know. There are entire books that attempt to explain it.
Tracking the frequency/duration of full collections is the usual approach. The GC has to work harder as heap space runs out, a system which is tight will do frequent full GCs vs one which is running with plenty of head room. In particular if you're using G1, seeing full (single thread) GCs at all is a bad sign. I'd also do this out of process, either by monitoring via JMX or simply scanning GC logs. A process trying to monitor itself rarely works out well :)
The better garbage collector for servers (G1) never pauses the world to free everything it can, so it's not like you can look at post-collection heap size or anything.
It's an over simplification to call G1 "the better collector for servers", it's more complicated than that - and G1 certainly can do a stop the world, it just tries to avoid it.
I'd also say this - if you're capable of writing C++ without any resource leaks you're capable of writing Java without any resource leaks. In which case memory usage will be predictable and simple load testing will show you how big a heap you need to allocate.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
But you do know that "small memory" VM try to reclaim memory during the 'new' or 'alloc' call and don't have a GC which is waiting till 'all memory is consumed'? ... you have no clue. Sigh, 30 years of computer science wasted in stupid IBM vs MS vs Sun vs Apple vs Oracle wars. ... (yes, that adds up to 40 years, your turn?) /. claim of a 25 year old and say: wrong!
Guessed so
I guess I mentioned often enough that our days computing experience is minimum 20 years behind what *I* learned at my university 20 years ago
You can basically pick a random
I worked on SVR3 (kernel), SVR4 (kernel), AIX (kernel), FreeBSD (kernel), iOS (kernel). I also worked on ChromeOS/Linux (kernel).
The reason you wait to reclaim memory, rather than doing it on a stupid timer, is that you can't put the CPU into standby mode for much longer times to conserve the battery and thereby extend battery life.
If you reclaim memory explicitly, that's OK, since it means that you're already running, and that won't screw your battery life.
Guess why Windows on a MacBook doesn't have as long a battery life as Mac OS X on the same MacBook? Because Windows *polls* its USB devices, because it can't be sure that the internal USB controller isn't shit, and because it can't know, even if the internal USB controller isn't shit, that the internal devices like the keyboard and trackpad connected via the Qualcomm microcontroller aren't shit, because it doesn't make a distinction between the internal and external USB controllers. It fails here because it has to run on all the crappy hardware that's out there, because it's an off-the-shelf copy that can't make hardware assumptions.
You can basically pick an old fart (who learned before systems incorporated substantial power management technology) or for that matter, a young kid who thinks all computers are Linux boxes plugged into the wall, and then pick any /. claim they make that doesn't take power management into account and say: wrong!
If they're going to waste their time doing this, they should probably target a less hellish language that gives you the benefits of today, and not the benefits of 1990. Re-implement the kernel in say, Rust, and help both projects out. Don't just waste time porting it to a much subtler language with all the same underlying problems anyhow. All for what? Probably an over-designed class hierarchy and a sea of mad templates to compensate for the lack of genuinely useful constructs, like not having any null pointers in system-critical code. And a shit-ton of macros to work around a sea of compiler bugs.
Yeah, Linus mentioned those too. Where does C++ do hidden heap allocations?
The only example I can think of is when throwing an exception (and see below about that), and even then, the compiler rarely actually performs a heap allocation. Small exception classes are stored in a pre-allocated static buffer.
And if you are talking about library use, then you need to realize two things:
1. STL is the most allocation aware library I have ever seen. With a few C++11 related exceptions, it will always allow you to pick an allocator, and will always avoid allocation where one can be avoided.
2. If you think even that level of care is not enough, then you are free to not use STL. Assuming you are correct, your options are "Don't use STL, implement your own implementation in C++" or "Don't use STL, implement your own in C", and I fail to see how option 2 is preferrable to option 1.
As for the other two, RTTI cost you a few extra bytes per defined class (not instance). You are free to tell your compiler not to generate those if you don't use it (for user space, I rarely bother).
Exceptions are a different story. They get a very bad rap, and it's only partially justified. There are two reasons to not like exceptions for kernel code. The first is that exception use is a fundemental design decision. It is not something that can be slapped on to existing code. To do it properly, you must also have RAII and a good structuring of your code. Since those two are a good idea regardless, most good C++ programmers don't mind, but it's hard to migrate existing code to use it properly.
The other reason exceptions are not liked is because of a design decision made by the C++ committee that exceptions have no runtime cost when an exception is not thrown. This leads to the compiler generating the same code twice, and to a very complicated stack unwind code. I don't think either of these will prevent exceptions from working in the kernel (given the proper adaptations), but I do understand how these cause people to be weary of them.
I do agree with Linus about one thing. C++ is a language that is too complex. This leads to good C++ programmers being a minority among C++ programmers.
Shachar
The importance of this is underestimated. With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.
Unfortunately, you can't use any of that in the kernel [overloading create/destroy new/delete operators won't cut it]. Spinlocks, rwlocks, RCU, slab allocation, per cpu variables, explicit cache flush, memory fence operations, I/O device mappings, ISRs, tasklets, kmalloc vs vmalloc, deadlocks, livelocks, etc. are the issues a kernel programmer has to deal with. Nothing in C++ will help with these and some C++ constructs are actually a hindrance rather than a help.
For instance, copy constructors must be disabled. This was part of a proposal a few years back to make a C++ subset suitable for realtime/embedded. It isn't acceptable to have "x = y" invoke an unexpected amount of code simply because you inadvertantly invoked a copy constructor.
Kernels by their nature are messy. Anybody writing kernel code must be fully aware of the implications of doing something and must be aware of the state they're being called in. Abstraction just makes this job harder not easier.
For example, all kernel code must be compiled with -mno-red-zone because of the threat that any base code could receive an interrupt at any time [even between 2-3 machine instructions that comprise the red zone setup code].
Linux already does a pretty fair job of keeping things clean. If you don't believe that, actually go read the kernel source code. And, if something ends up being crufty, it gets cleaned up. Even if that means that some 100 or so modules need corresponding changes.
Like a good neighbor, fsck is there
> C++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling
Wrong.
There's no standardised ABI because no-one has bothered to design one. This isn't the job of the C++ committee; on platforms which have a standardised C ABI, this is due to the OS vendor.
MSVC doesn't even provide compatibility between code generated with different compiler switches (e.g. the /vm* switches which affect how pointer-to-member values are stored). So it's kinda hard for other compilers to be compatible with MSVC when MSVC isn't even compatible with itself.
The differences in name mangling between compilers exist specifically to prevent linking code which would be incompatible for a host of other reasons.
Not just name mangling. Don't forget the fragile base class problem, which (without deliberately working around it) causes all your subclasses to break every time you add a new instance variable or instance method.
Of course, those problems are solvable. Apple has gone through at least a couple of name mangling changes over the years, and managed to maintain binary compatibility by writing a remangling kernel linker. And you can work around the fragile base class problem by declaring padding to leave room for future member variables and instance methods.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I can't tell if your use of the term "bad drivers" in making a point about Linux is silly coincidence, or comic genius. Either way, I salute you!
Vonal Declosion
Copy constructors are called when objects are passed or returned by value. Assignment operators are called when you make an assignment. If you do not provide a copy constructor or an assignment operator, the compiler will synthesize one for you.
What else is there?
The only thing C++ solves in kernel development are problems that nobody cares about. Replacing macros with templates and long function names with namespaces buys the kernel developers precisely nothing.
Replacing macros with templates and long functions names aren't exactly the killer benefits most people think about for C++. It's typically things like avoiding memory corruption and resource leaks, which can both be really bad in an OS kernel. Even so, I'd argue that they DO buy kernel developers something. Macros are completely type unsafe, and can silently generate bugs. More sanely named overloaded functions and namespaces help to make code more readable. Are kernel developers somehow magically exempt from features the rest of the world finds useful?
Still, even as a C++ advocate, I would never really argue that C++ solves all problems, is easier to use, has no hidden costs, or even is the correct language to use in all situations. Good C++ programmers understand the costs of features they are using and the tradeoffs they're making. There are bad programmers in every language, including C++. Personally, I'll probably always choose C++ for my own projects that require high-performance native code because it provides some very significant benefits:
1) Using class based abstractions can virtually eliminate some really dangerous categories of bugs like buffer overruns.
2) It's almost impossible to leak memory or resources with properly designed wrapper/interface classes.
3) Well written C++ interfaces can make it harder to misuse APIs in general
4) These benefits are typically provided at either zero or with minimal overhead. There is no "hidden" overhead if you understand how the language feature or library works.
5) For times that this overhead is critical, you can revert back to C. For all other cases, you can prefer the higher-level abstractions and the safety and convenience they provide.
Generally speaking, I'd say it's harder to write good C++ code and design great C++ interfaces. However, once those interfaces are created, they tend to be far easier and safer to use - even for the person who originally wrote them. Most of my own library classes are designed in such a way that I couldn't cause crashes, leaks, or memory corruptions with them unless I tried really hard to do so using blatantly unsafe techniques (which C++ lets you do, of course, just like with C).
If I had to sum up, the significant benefit of C++ is that it makes it possible to protect the programmer from making mistakes to a much greater degree than in C while retaining most of the performance benefits of C. We've seen it demonstrated quite clearly, time after time after time... programmers are only human, and will always make silly mistakes. Why not take advantage of the language and compiler to help minimize the chances of making those mistakes in the first place? To me, that's the essence of C++.
Irony: Agile development has too much intertia to be abandoned now.
Full disclosure: I have lots of experience with C and almost no experience with C++. (I started to learn C++ but I was suspicious of its complexity. At least, that's what I tell myself, but maybe I was just lazy or too old to learn new tricks. Anyhow, I didn't learn it.)
"Every sufficiently large C project re-invents key portions of C++, poorly."
I have to wonder if that is because every sufficiently large C project is going to have C++ programmers in it who are 'thinking' in C++, and if it was team just of guys like me we would be doing things strictly the 'C' way.
(Incidentally, I realize that C has lots of faults. That's why I'm intrigued by languages like Golang (aka Go) because Ken Thompson is one of the designers, out to fix the faults of his 1st language.)
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
Unfortunately, you can't use any of that in the kernel [overloading create/destroy new/delete operators won't cut it]. Spinlocks, rwlocks, RCU, slab allocation, per cpu variables, explicit cache flush, memory fence operations, I/O device mappings, ISRs, tasklets, kmalloc vs vmalloc, deadlocks, livelocks, etc. are the issues a kernel programmer has to deal with. Nothing in C++ will help with these and some C++ constructs are actually a hindrance rather than a help.
For instance, copy constructors must be disabled. This was part of a proposal a few years back to make a C++ subset suitable for realtime/embedded.
Surely not every line of code in a kernel has to deal with *all* of that, right? C++ allows you to gracefully fall back to lower level abstractions where you need to and use the higher level abstractions where necessary. The fact that portions of the kernel are apparently currently being rewritten in C++ suggests that it's not impossible to do so. Copy constructors, assignment operators, and other overloads are trivially disabled in your own classes, of course. I don't think anyone would sanely suggest that a kernel starts pulling in all parts of the STL library or anything like that. Nor would anyone with sense suggest that code start blindly calling generic 'new' and 'delete' to allocate objects. Hell, in my own codebase (a game / custom engine), every single allocation goes to a custom allocator instead of new. C++ makes possible to do this just like C does.
Even beyond that, what percentage of a kernel would you suspect is so touchy / critical that C++ wouldn't be appropriate for it? I'm taking a wild-ass guess, but I'd be shocked if anyone told me it was greater than 10-20%, with the other 80-90% being more mundane and less-oft executed but still necessary code. I'd imagine C++ could probably be used there to simplify and make safer normal operations in those areas. Maybe people more familiar with the Linux kernel code would have a better idea than my guess.
Even in my own code, for instance, in my custom memory allocator, of course I'm using C-style structs, raw pointers, and all sorts of dangerous, low-level pointer tricks and casts. There are some circumstances that absolutely require that type of low-level code. The point, though, is that you really only have to use that dangerous, low-level code where absolutely necessary, and everywhere else you can use safer abstractions.
Irony: Agile development has too much intertia to be abandoned now.
Good judgment in choosing language features to use is a far lower bar than never making programming mistakes that accidentally stomp all over memory you don't own or leak resources in some corner case.
There are plenty of languages that are arguable "better" than C or C++, but part of C's strength at this point is it's universal / ubiquitous nature. It's literally *everywhere* - the first thing anyone does with a new chip is to make or modify a C compiler to support it. Part of C++'s (admittedly pragmatic) appeal is that you don't have to throw out your entire codebase to start using it, since it's largely backwards-compatible with C. Any suggestions to throw out all legacy code and start fresh with a new language ends up being a completely academic exercise.
A lot of people consider C compatibility a weakness of C++. From a pure design standpoint, sure. From an actual pragmatic, we-need-to-use-this-in-the-real-world standpoint, it's a huge advantage, not a disadvantage, because of the massive amount of C code actually being used in real-world products.
Irony: Agile development has too much intertia to be abandoned now.
Having been on the fence about this for a while, my experiences convinced me that C++ is wrong for the kernel.
The problem is not the extra features. The problem is that the programmer has little control over exactly how they are implemented: the compiler decides how to handle virtual method tables, destructors, multiple inheritence, etc. In the recent past, C compiler bugs have caused serious problems with Linux development. C++ compilation is an order of magnitude more complex, and you can bet it would be less reliable. This also means that C++ compiles much slower: doesn't sound like a big deal, but it is a cost to take into account.
The lack of a standard, clear ABI for C++ is also problematic. While it's true that Linux is monolithic, it still supports modules that interact with each other dynamically. Debugging C++ can be quite painful because of this. But it also means that it would be that much harder to contribute a module if it's not written exactly for the same compiler as the one used to build the kernel. Of course, it would have to be written in C++, too. This lack of flexibility can be quite painful in environments where you are limited to very specialized compilers (embedded). C has the most standard ABI of any language (well, C and Pascal). You can guarantee that *anything* would be able to interface with it.
So if you put the technical cons (losing control, flexibility and debugabbility) vs. the pros (cleaner syntax) then it's right to pick C, on technical grounds. As others have stated here, anything you can do in C++ you can do in plain C. It's a bit clumsier, but then you have complete control over the implementation. I do OOP in C all the time, it's perfectly OK. If anything, a bit more powerful than C++, because I tailor the OOP features to exactly my needs and tastes.
Beyond that, there is the more controversial issue of programmer culture. C++ hides away implementation details, but for kernel development you want programmers who think about every tiny issue of implementation: exactly what is going on with the call stack, what is a pointer and what isn't? The more explicit nature of C encourages a more hard-nosed stickler for technical correctness, which is more important than pretty code for kernel work.
By the way, I'm writing this as a former C++ zealot. I even created something like this in the past, a C++ wrapper for Windows NT networking services. I found out the hard way that C++ takes more than it gives. I write all my code in C these days, and don't feel like I'm missing anything.
G1 DOES stop the world. The pause time target is one of the parameters you give it...
You still measure how much of the heap is used over time, and you still measure GC overhead as a percentage of time.
If you are trending those, you will not run out of memory without warning.
Operating systems fail under memory pressure sort of the same way, you have your big lump allocations that fail real nice and clean and you have your death by a thousands cuts where the system increasingly runs its trytoscroungemorememory() until that's all it does. That's maybe a bit apples to oranges, but I'm saying the symptoms of memory pressure are about the same everywhere, and that's the thing to look for.
You are unable to grasp when a copy constructor or an assignment operator is called?
If all you see is 'a = b' in a few lines of a patch, yes, it's impossible to say.
Dog_slow_Distro:
http://linux.slashdot.org/story/13/11/12/161227/linux-kernel-running-in-javascript-emulator-with-graphics-and-network-support
The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
Unfortunately, C++ includes an explicit non-standard that can inject subtle bugs. This has been present since at least 1988, and has survived at least the first two standards (after which I stopped watching, having moved on to mostly hardware design).
(I DID try to bring it to the attention of the standards committee in both cycles, but it was ignored. Bjarne, in his recent Slashdot Q&A, didn't answer my question on it, either.)
The problem relates to which overriding of a virtual function is called during the initialization of the member variables and the construction of member objects of a derived class (and the corresponding destruction of the member objects during the destructor). The standard permits the calling of the derived class' version of virtual member functions at this time, when the derived class has not initialized, or has dismantled, their underpinning.
Compilers are permitted to cause the call to go to either the base class version (IMHO correct) or the derived class version (IMHO dangerously incorrect). Calling the derived class version is bad, preventing a number of obvious constructions from working as expected, imposing limits on what programming techniques can be used safely, and displaying no warning (so the programmer has to know what not to do). Letting different compilers make different choices is horribly worse, as it makes the behavior unpredictable and compiler dependent.
C++ (especially the early versions, before it became buried in libraries and baroque constructions) came SO close to being a powerful and reliable tool for rapidly writing reliable code on large projects. But this "little bug" brought it all crashing down.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
They are OK it is just slow at this point in time and very costly, risky and coud bankrupt you...wondering when GC will kick in!
C++ would kill the Linux kernel...
Do people not debug through object code any more? I've done that so many times when trying to understand a bit of cryptic C++ code or C macrology. There's no mystery possible - just look at the generated object directly if there's any doubt at all what's going on!
I learned to program back in the days when compilers would produce listings with the assembly code for each source line immediately following the source line. It was a given that the programmer would understand it and it often gave insignts into what was going on - and going wrong - in a program.
It was also good training for reverse-engineering from object to source. (I fondly recall reading a piece of a buggy SCSI driver's object code that stored zero in a variable and then tested the value, and realizing that somebody had written "if (a==0)" as "if (a=0)" by mistake.)
But I gave up on this about 1990. RISC instruction sets, with things like the delay slot after a jump, and extreme compiler optimization, made enough of a hash of the object code that determining what it was actually doing became more of a research project than an exercise in reading. Dropping back to inserting instrumentation in the code ended up being far more productive.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Please don't say that in a hiring interview.
You are unable to grasp when a copy constructor or an assignment operator is called?
It is impossible to tell, from looking at an assignment, whether it is being done by a native assignment, a copy constructor, an overridden assignment operator, etc. To determine that you must go back to the declarations of the variables to determine their type, maybe hunt through the include files to identify the type behind a typedef (and possibly which typedef is in effect given preprocessor-flag-driven conditional compilation), then (if you're dealing with a class type), studying the class definition (including walking back through and groking its base classes).
Ditto for overridable operators - which is pretty much all of them.
In C you can pretty much look at the code describing what to do and figure out what it does, only going on a snipe hunt when you hit a subroutine or macro invocation.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Yes, these days he might not be able to easly determine what the generated code IS. But with C he can be pretty sure he correctly determined what it DOES - and if it does something else it's a compiler bug.
With C++ you get to override operators, functions, and pretty much everything else. You can redefine the semantics of what they actually DO in various situations. Keeping the semantics analogous when writing overridings is a convention, not something that's forced by the compiler.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
It won't be time for C++ in the kernel until the standard defines (and the compilers implement) whether you get the base or derived class version of a virtual function if it's called during the initialization, construction, or destruction of a derived class' member variables.
It also won't be time for C++ in the kernel if they DO define it, but they define it to be anything but the base class version. The derived class version should only be called beginning with the first user-written line of the constructor and ending just after the last user-written line of the destructor.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
C++ reduces the complexity of the source code it INCREASES the complexity of the software! (which in this case would be the kernel)
For a short while, the Linux kernel could be compiled as C++. Some developers, I believe Linus included, felt that the stricter type checking offered by C++ would help kernel development. There was no attempt to actually use C++ features though.
The effort did not last long.
Once ANSII had imported C++'s strong type checking into the C standard, and compilers had implemented it, there was no need to use the C++ compiler to get strong type checking.
Since that was the only feature Linus was using, it makes sense to discard the remaining cans of worms unopened. B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Have you tried profiling the jvm with VisualVM? I have used it together with the glassfish application server to optimize the memory usage of our application and it was quite helpfull.
Was that the same time all the new HORRID bugs were introduced?
Looking at the project, I stumbled over the fact they did rewrite an ethernet driver and have rewritten it in C++ with a 2% performance overhead.
Well that makes it easy to determine whether it's worth it.
The David House variant on Moore's Law says processor power doubles every 18 months, and the real world has tracked this very closely for half a century. A 2% improvement doubles after 36 steps, and 18 months is 78 weeks. So in a few hours over 16 days, Moore's law has given you back your loss, and after that it's gravy.
So if having your code base in C++ improves your development process enough that it lets you complete and release your next upgrade (or the one after that, etc.) only a couple weeks earlier, C++ wins.
If it lets you keep gaining on your competition, it wins BIG.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
And with 1000s of contributors you then have to educate all of them what C++ features can be used when and where, and every patch review has to double check if through some mysterious overload hidden somewhere that code actually does something that it doesn't at all look like.
C++ is not good when you _regularly_ have to deal with people that might be lightyears away from the competence required to use it correctly.
> The entire point of C++ and it's compatibility with C is that you can use as much or as little of the higher-level abstractions as you need.
Except you forgot that especially in an OpenSource project you also have to then police that only the appropriate parts are in fact used.
Also you forgot all the language feature C++ _misses_. Designate initializers so that your "static const" variable definitely will be possible to place in a read-only segment but you still can refer to the fields by name so reordering them doesn't break the code? Or so that you can easily create sparse arrays for optimization? Not there in C++. And there are a good few other features very useful for embedded/realtime code that C++ never bothered to adapt, because the have "more powerful" features (like constructors), except that these features never work reliably in the same way.
> You just create objects on the stack, let them handle their memory management internally and automatically clean up when they go out of scope
Yes, and 4 years in I still have to look out for both in my code but mostly in code from other team members for news and deletes.
Unless you have some tool that automatically and at least 99% reliably (including cases where it's too much of a pain to not use new and does not warn about it) detects and warns about it, C++ is of very limited help when you to work with real-world teams and not just on your own hobby project or elsewhere where you can chose who gets to work with you.
If you don't think Linus has enough C++ experience, how about the man who created of C++ as a hoax, Bjarne Stroustrup:
Interviewer: If we publish this, you’ll probably get lynched, you do realise that?
Stroustrup: I doubt it. As I said, C++ is way past its peak now, and no company in its right mind would start a C++ project without a pilot trial. That should convince them that it’s the road to disaster. If not, they deserve all they get.. You know, I tried to convince Dennis Ritchie to rewrite Unix in C++..
Interviewer: Oh my God. What did he say?
Stroustrup: Well, luckily, he has a good sense of humor. I think both he and Brian figured out what I was doing, in the early days, but never let on. He said he’d help me write a C++ version of DOS, if I was interested..
Interviewer: Were you?
Stroustrup: Actually, I did write DOS in C++, I’ll give you a demo when we’re through. I have it running on a Sparc 20 in the computer room. Goes like a rocket on 4 CPU’s, and only takes up 70 megs of disk..
Interviewer: What’s it like on a PC?
Stroustrup: Now you’re kidding. Haven’t you ever seen Windows ‘95? I think of that as my biggest success. Nearly blew the game before I was ready, though..
Interviewer: You know, that idea of a Unix++ has really got me thinking. Somewhere out there, there’s a guy going to try it..
Stroustrup: Not after they read this interview..
Obviously the BOSS-MULL developers never did read it. You can here.
> All code is written and abstractions can be accomplished in C just fine, thank you.
Not with equal effort.
OTOH if C had the ability to have a finally {} for a given block, there would be little reason to use C++ in this use case.
As in, std::max wasn't usable in C++ for years because it was define'd in WIN32 already, and rtather than have #define NOMINMAX everywhere a lot of coders rolled their OWN min/max functions?
Way to be arrogant. You for example forgot that copy constructors in certain causes can be removed when an object is returned by value.
But make a simple mistake and they suddenly won't be. Or your compiler has a bad day and it doesn't do that optimization.
Copy constructors are also used when you increase the size of a std::vector. That is unless you use C++11, when they aren't used.
I think you very eloquently demonstrated the problem, since you seemed to be completely ignorant of the issues without even knowing it.
And I definitely am rather clueless and inexperience when it comes to C++, so I probably don't know even half the issues with it myself.
So it is about the same reason why longbows were superceded by slower and shorter range crossbows: crossbows are much easier to use effectively while longbowmen had to start their training when they were still kids.
Good tool is easy to use. Easy tool allows its users to concentrate on the tasks and not on the tool. Good tool lets more people use it effectively. C++ is not a good tool.
Yes, they can. Your links are irrelevant.
If you fail to close a resource what do you think you're going to do in C differently than suppress?
The fact that *EVERY* line of kernel code has to deal with those kind of issues is a byproduct of the monolithic kernel design, not what the code itself is doing.
I started off as a Unix kernel programmer in the late-80's, did a lot of stuff on supercomputers and went to Apple to work on Copland (micro-kernel). I/O subsystems can make good use of OO abstractions. OS X's IO subsystem is written in C++.
It's really time to look at microkernels again. There are some performance issues, but many of those will get smoothed out as they're hit and engineered around.
The argument around gets as an example of how c leads to bad design is bogus. Even the man pages point out the problem.
So? GCC ended up actually building in some optimizations to make that poor example run fast because despite the man page, people write it in code so much it was worth hacking the optimizer. The point is not that C++ is faster than C, it's that the obvious choice in C++ is often much faster and cleaner than the obvious choice in C.
Have you looked at the mess that is the string class in the stl?
It's a mess in that it has a bunch of functions plus the kitchen sink included. But it's still not hard to understand because the encapsulation works well. Also, just because the C++ standard ossified one bad design choice from 20 years ago does not mean that C++ is worse than C. I could find heaps of terrible C code for you if you like.
And that goes for pretty much any container class.
Oh god I've had to work with people like you. I worked with as guy who believed like you and hacked together his own vector class. Well, he mad a bunch of mistakes. He forgot exponential growth, so algorithms were asymptotically worse (and slower in practice) using his class instead of vector. He also forgot to not use const references in things like push_back() because that will ocasionally break if you do vec.push_back(vec[0]). And so on.
The STL is extremely well specified. Anyone capable of reading cplusplus.com can see exactly how any vector implementation on any implementation outhr to work (modulo bugs, though I've never encountered a STL bug in the wild).
If you spent half the time perusing the spec than you spent duplicating the STL, you would not find the behaviour "unexpected", you'd save time and other people would find it easier to follow your code.
SJW n. One who posts facts.
> Don't like giant template metaprograms? Don't accept the pull request. That easy.
Have you ever been involved in a real project, and been responsible for reviews?
If your solution involves manual reviews, it is not "easy", it is a high-risk, high-effort manual process that puts additional load on the people that have least time to spare. I.e. it shifts the work exactly the way you're not supposed to shift it.
You just create objects on the stack, let them handle their memory management internally and automatically clean up when they go out of scope.
You mean like this in Java?
public void myfunc()
{
MyObject localObj = new MyObject();
}
When you exit the scope it's eligible for garbage collection. Unless you hang onto a reference it's not going to hang around. If you're leaking memory or resources in Java you're hanging on to them somewhere. If you were doing the same thing in C/C++ and you free the object while keeping the pointer around you're just creating a Heisenbug.
By my reading of the try-with-resources thing is you still have to type out that block. It's more lines of code you have to type that the compiler can do for you in C++.
Sure you can remember to do try-with-resoruces, just like you can remember to call fclose(). But every special case you have to remember and every line you have to type is another source for bugs to creep in.
Personally I like it in C++ that I can open an iostream safe in the knowledge that the compiler will make sure I don't mess up and forget to close it.
And for fuck sake, Java has build in support for multithreading, a mutex is not acquired by a constructor nor is it released by a destructor, for that we have a keyword: synchronized. Since Java 0.7 I believe.
Ah and so it is decreed then. No one could possibly want or use mutexes in Java then. I guess the current owners of Java are wrong about it too.
http://www.oracle.com/technetw...
So apparently you are mistaken. Since locks do exist in java in addition to monitors (apparently, it is not my knowledge that is outdated):
http://docs.oracle.com/javase/...
So, are you now going to recant your absurd claims?
SJW n. One who posts facts.
I worked once for a company producing an embedded kernel for real-time applications, entirely written in C++/assembly.
To maintain a good level of performance and reliability, you have to put constraints and rules on generated code layout. No per-compiler ABI here.
Otherwise, you have to marshall calls between applications, libraries, kernel, even if system architecture is micro-kernel oriented, and these marshalling layers quickly tend to harm performances in general and also real-time capacity.
Comparing the 2nd and the 3rd edition of C++ reference book is quite enlightning about the language. Bjorne Stroustrup, in the 2nd edition, considers the C++ language as mature and almost as a closed subject. As presented in the 3rd edition, language kerwords number has been multiplied by two.
Regarding all the programming paradigms allowed by languages providing classes, you can say that C++ will still have to evolve to be able to manage its own complexity and to provide all the tools and possibility that object oriented programming can furnish. The key constraint being to express all of it with syntax and concepts that can be compiled to hardware interpretable code.
Regarding how far C allowed programmers to go in term of systems, performance, creativity, and program exchange, C++ standardisers will have sooner or later to think about normalising its ABIs or allowing enough part of said ABIs definition through the language itself to minimize as little as possible the impact over compilers.
So basically Bjarne added features that would cause coders try emergent solutions. Offered maximum flexibility knowing full well it would lead to maximum bad behaviour. We are lucky to have guys like Linus wise enough to take C++ at its face value and drop it.
Emergency is bad, that's why it is called 'emergency'!
Apple was burned by this earlier. The IOKit interface for device drivers on OS X used the GCC 2.95 C++ ABI and so they've been forced to add support for this in clang and maintain it. Name mangling isn't the issue though, it's vtable layouts, which are sort-of standard now, in that everyone (except Microsoft) either uses the CodeSourcery Itanium C++ ABI or (in the case of ARM) something with small diffs against that ABI.
The big argument against C++ in the kernel is that it's hard to use the C++ type system without templates and it's hard to use templates without generating so much code that you'll blow your i-cache away. It's fine in a lot of userspace code, where you'll want to spend a lot of time in the template code and so this cost is amortised, but in the kernel (where you typically want to quickly do a small thing) having to pull a lot of code into i-cache and displace a load of userspace code is far from ideal.
I am TheRaven on Soylent News
No, I also don't understand the COM hate. It's just a standard for vtable layouts and a few other things. It's not even a large standard - compare it to CORBA some time. Apparently some developers don't like well-specified binary interfaces or separation of interface and implementation. Their code is probably best avoided.
In the FreeBSD kernel, we use an object system implemented in C ('KObj'), but the functionality it provides is pretty close to COM, it's just less well documented and doesn't have an IDL (it's only really meant to be used in C). I keep threatening to add a clang C++ ABI that compiles to KObj interfaces...
I am TheRaven on Soylent News
There already is a de-facto ABI standard that is maintained by most interested parties (i.e. everyone except Microsoft) and nominally edited by CodeSourcery / Mentor Embedded. As the grandparent said, the important point is to have an ABI standard, not a name mangling standard. Having compatible name mangling but different object and vtable layouts would cause far more pain than it would solve. Different compilers would generate incompatible object files, but they'd still link.
I am TheRaven on Soylent News
The fragile base class problem isn't really specific to C++. Any time you change the size of a kernel struct, you risk breaking the KBI. It's also easier to solve in a language like C++: you can encode the field offsets as relocations so that either the static linker will resolve them if you're in the same binary as the type was declared, or the run-time linker will resolve them at load time for other binaries. This can also give you link-time checking that the fields that you think exist really do.
I am TheRaven on Soylent News
To work around it, you can simply fall back to a C-like API at module boundaries
And thus losing the entire reason for using C++ in the first place. The whole point of this project seems to be that they want drivers as C++ classes. If you do that then you end up with a giant mess of wrapper functions to translate calls from simple C to C++ object calls.
Actually no. All you need is one C function to pass the driver class instance to whatever wants to use the driver. From there on you can use the instance to make the calls directly in a C++ manner.
The importance of this is underestimated. With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.
Unfortunately, you can't use any of that in the kernel [overloading create/destroy new/delete operators won't cut it]. Spinlocks, rwlocks, RCU, slab allocation, per cpu variables, explicit cache flush, memory fence operations, I/O device mappings, ISRs, tasklets, kmalloc vs vmalloc, deadlocks, livelocks, etc. are the issues a kernel programmer has to deal with. Nothing in C++ will help with these and some C++ constructs are actually a hindrance rather than a help.
For instance, copy constructors must be disabled. This was part of a proposal a few years back to make a C++ subset suitable for realtime/embedded. It isn't acceptable to have "x = y" invoke an unexpected amount of code simply because you inadvertantly invoked a copy constructor.
Kernels by their nature are messy. Anybody writing kernel code must be fully aware of the implications of doing something and must be aware of the state they're being called in. Abstraction just makes this job harder not easier.
For example, all kernel code must be compiled with -mno-red-zone because of the threat that any base code could receive an interrupt at any time [even between 2-3 machine instructions that comprise the red zone setup code].
Linux already does a pretty fair job of keeping things clean. If you don't believe that, actually go read the kernel source code. And, if something ends up being crufty, it gets cleaned up. Even if that means that some 100 or so modules need corresponding changes.
As someone who have tought kernel programming and C++ at the same time, I call bullshit on all of that.
Overloading allocation is exactly one of the useful features of C++, and copying is no different than on C. You can in fact even explicitly disable copying or explicitly enforce default copying in C++11. Things that is error-prone and boiler plate code in C is easy in C++. As for memory barriers and all that, C++ is again no different from C. Usually you use compiler extensions or assembler for kind of feature, but it is much easier in C++ where you can create templates and wrappers do use all of this correctly, convientenly and safely.
The abstractions of C++ makes handling most kernel issues easier, but it does require more skill as C++ is greater language, this is also why it was great to teach students C++ by letting them write a kernel, they had to learn what C++ features actually did and which to use and what not to use.
Unfortunately C programmers are a religous sect at this point. The believe C++ is witchcraft because they don't understand it, and refuse to learn.
Lack of a C++ binary compatibility standard is also responsible for one of the greatest misery in modern computing, the fact that other languages cannot reliably interface with C++. This has lead to horrible hacks and huge problems with GUI libraries because these are mostly C++-based (except for Cocoa and GTK). Ironically, lack of an interface specification is also the primary reason why C++ is still in use today.
I would use Ada, which is harder to write but easier to read.
i would use PHP or Ruby, because that would allow us to put the kernel right into the cloud, where it belongs.
The question was "when are copy constructors and assignment operators called". I listed the times when they are. The fact that the compiler might optimize these situations away is irrelevant. You assume that it won't and code accordingly.
In C++, if you're dealing with an object of a class type, you always assume that an assignment operator or cctor is being invoked when you see an assignment being performed or something being passed around by value. At least I always do. Reason being is that if the programmer decided to make it a class, it probably has non-trivial implementation details necessitating the need for op=() and a cctor. It probably needs a destructor too. Hence the Law of the Big Three. Some places even consider it a bug if a class doesn't have these three member functions (or at least documented that the compiler-generated versions will be used) and will get flagged during a code review.
I would grant that poorly written C++ is probably much worse to detangle than poorly written C. However, well written C++ is just as usable and maintainable as well written C.
And which do you think you are more likely to run into? And which do you think is more likely to be contributed to your project?
I'm a minority race. Save your vitriol for white people.
C is a product of its time, and so is C++.
They both have benefits and faults.
However they're also (like Go) from the same small group of people.
We don't need Go - we need fresher thinking from a new generation.
That is the correct decision, IMO. It's not the 80's anymore; standard input and standard output are not sufficient IO abstractions. Graphics and mouse input are the bare minimum for general usability these days, altough in a pinch terminal emulation might do.
On the other hand, binary compatibility for a language that relies heavily on compile-time code generation (template specialization) is frankly pointless, especially since libraries are going to continue being plain C due to near universal presence of C bindings.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
I'm not so sure of that, the NT kernel is C. Look at the low-level APIs used in win32, these are all C based, with handles and whatnot.
Microsoft is perfectly happy to put a C++ wrapper around a lot of things, but I think the Windows kernel team are basically C coders.(which is not a bad thing).
One interesting example is Windows Web Services - a kernel equivalent of the shitty .NET WCF. Its completely compatible, but is much, much, much faster. The APIs for that are C, not C++ as you'd probably expect.
But they cannot be used to release any resources, like sockets, streams, files, connections, etc.
How the hell do you get an error closing a socket or a file? Seriously, think about the question for a second...
Yep, program termination is perfectly fine, because that's a programming error that should certainly never get past basic testing. In fact, it should never even show up in testing, because avoiding it in C++ is so damned easy, allocate in constructor, close in destructor, and you'll never get an error on close, unless of course you've already corrupted memory hopelessly.
and yes the ABI is a serious thing. I asked Bjarne about it in the recent slashdot Q&A, and he basically said "meh, its not important and the vendors wouldn't like it, next question".
An ABI wouldn't be difficult to implement - all the vendors could add a compatibility switch to emit the bespoke mangling if they liked. But the rest of us (who compile the entire software suite every time anyway, or use C bindings because of C++ mangling incompatibilities between different versions of a vendor's compiler) would love it. I think one of the reasons C# and co do so well is because they have the ability to generate a binary and then it just works in other people's programs.
An ABI might mean more binary objects being released for Linux, so you wouldn't get the source, but that's more an idealogical issue than technical.
Any programmer that can't use C++ effectively, should really think about becoming a janitor.
I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion.
You must be new. You can get all kinds of statistics from the garbage collector through the API. That's how VisualVM (distributed with the Java SDK) manages to display things like permgen, heap, threads,etc. There are other tools out there as well that access the Java GC for monitoring and performance tuning if VisualVM isn't enough for you (though in almost every case I've found it more than sufficient).
With VisualVM it's trivially easy to watch the activities of the GC, do heap dumps for comparison, profile both memory and CPU, and watch and dump threads. If you want to track that information on your own or trigger certain behaviors then you can access the APIs directly.
If you want to know why C++ is great for operating systems design, look at the Amiga Exec.
Which actually was written in C, but mapped flawlessly onto C++.
Um, come again? The Amiga exec was written in BCPL, and ported to C[*], not C++.
[*]: Using Manx Aztec C, if I remember correctly, because that allowed embedding machine code in the C code.
When the Amiga kernel was written, C++ did not even exist as such - it was still called "C with classes", and Strostrup's definitive "The C++ Programming Language" had not yet been released.
Dunno about that. Have a look at fs/pipe.c some time; all those gotos didn't write themselves.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
That's why no C++ programmer ever writes code like this:
MyObject* localObj = new MyObject();
That line is considered a bug in C++.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
And not just that. Even experienced coders need to understand the purpose of the particular abstractions that were built into a particular set of C++ code to avoid butting up against them - or throwing up their hands in frustration and working around them in standard C in the middle of all the C++ code because it was to hard to figure out how to implement what you wanted within the class structures that were handed to you along with the order to "go and make it do this".
C++ is great for well-documented libraries designed for a 'use but don't touch' mode. For all other uses, the less C++'y, the better - even if you're using the language to take advantage of those great libraries.
Posted from my Android phone. Oh, I can change this? There, that's better...
"big ugly, hard to maintain or read macros that generate arbitrary machine code. No matter how good you are, you won't know what code is being generated without extensive analysis." Why can't you just look at the preprocessor output? This isn't that big of a deal. Or use an IDE like Understand, which will expand macros for you.
Yeah, but that's kind of like the "look at all the different, incompatible versions of Windows" argument that gets made to defend Linux against charges of fragmentation. C certainly can have some magic happening under the covers, but it's an order of magnitude less than what goes on in C++. That said, I'm sure it's possible to know C++ well enough to have a good sense of what an arbitrary line of code generates under the covers. What's arguably harder is to pick up an arbitrary piece of C++ designed by another coder with a different sense of how to organize his abstractions and understand how those abstractions are organized and work within them.
With C, you can pretty much look at a set of functions and understand why they were built the way they were. Maybe that's because of the limitations of the language, but IMHO, that's a good thing.
Posted from my Android phone. Oh, I can change this? There, that's better...
You know that you can do that with the PhantomReference, SoftReference, WeakReference classes?
http://docs.oracle.com/javase/...
clear() Clears this reference object.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
And how do you handle exceptions? For example, if you close a file it's a good idea to flush() changes. flush() can throw I/O exceptions.
Or if you close a socket. Or anything else that handles external resources.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
A file should be flush()ed so that changed are written out. That can cause I/O errors. If you disconnect your computer from the Internet, that can cause an I/O error on close(). There are sure more valid scenarious, when close() or flush() can cause I/O errors. There are also more subtle ways, like if you write a log message to a file in your dtor. That log message can cause I/O error.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
You don't realize that "interview" is a parody??? Nor do any of the people modding up your post as insightful???
Idiots. (Or jokers, which I guess would be OK, but sheesh, that's what +1 funny is for...)
Whoosh - he was talking about how you could allocate objects on the stack and have them be released automatically as you exit the scope. Java always allocates objects from the heap, but the reference can be on the stack and when you exit the scope the reference disappears and the object is now eligible for garbage collection.
Greyfox doesn't understand how garbage collection works in Java is what it comes down to.
You can do this with Java too.
Why crash when you can catch such errors and recover?
I thought you said sane C++ doesn't leak resources?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Smart pointers in C++ are rarely larger in size than normal pointers.
std::unique_ptr has the same sizeof of void *. std::shared_ptr has the same sizeof as void *, but adds another allocation. Then again, boost::intrusive_ptr has the same sizeof as void *, does reference counting, does not require virtual functions in the destination class and carries no extra allocations (but does require that the class being indexed be aware it has references).
Shachar
I bought the TR1 spec in hardcover when it came out. Read it three times in an attempt to like it, and unfortunately, in the final analysis, the bad outweighs the good, at least for me. YMMV.
Vectors can be implemented so many different ways in c, tailored to each use case. Ditto in c++, in java, in any language. To each their own.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Very bad example. ...)
Obviously the operator = is called if 'b' is a variable. The only question is if that operator is user defined.
The next option is, 'b' is a class name, then there is an object of type b created.
Now you have four chances:
b can be assigned to a, then a has an operator = accepting a b
b and a have the same type, same as above, but likely the build in assignment operator is used
b can be casted into a, usually with an 'operator a' (forgot how it is written, an operator belonging to class b)
or finally a has a constructor taking a b
So bottom line, it is very obvious what _can_ happen, the = makes it very clear, and the open question is: which of the above 'operations' are implemented. (The order in which those operations are tried is not the correct one
So granted: you have to look at the class definition of a or b or both.
Bit there is nothing hidden or unclear.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Correct, and I don't see any problem with having to look at the definition of the left side and right side types.
After all you likely work with those types on a regular basis and should imho know from your mind what operators are overloaded.
Why one claims that the limited expressiveness of C is an advantage, is beyond me.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You have to accept that Java has no 'flat objects' but only heap allocated ones. /. readers can describe the difference between a mutex and a monitor right out of their mind.
So the constructor/destructor stuff never will be available in Java.
The new try (closeable) construct is god enough imho, after all the usage of such objects usually _allways_ involves exceptions anyway.
Regarding your rant about mutexes, I don't get what you want to say. Java always had 'monitors' which is for most usages the exact same thing as a mutex.
I doubt many
For all practical purpose, in Java at least, both are the same.
So again: instead of a constructor / destructor idiom you use the build in keyword in Java, which happens to be synchronized. Your original claim that Java 'is bad for multithreading, because it has no constructor / destructor idiom ready for handling mutexes' is wrong, it does not need that, as it has monitors.
The links you gave are all referencing to higher level synchronizations that are implemented with such monitors.
So what exactly is your point? That you can not use those higher level abstractions without a constructor / destructor idiom?
Sorry, then learn to code ... can't be so hard to separate lock management in one method, which has max 8 lines, and call the business logic from there.
If your methods are so big that you can not see that the lock you acquire on top is not released at the bottom you have far more serious problems :)
However if I would write a language for the JVM I would follow the C# example and add the constructor / destructor idiom for stack allocated objects.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I did not say, use a timer.
I said reclaim memory during the call to new/malloc. That is how embedded VMs do it.
Well, perhaps Windows and the world of USB devices would be less shitty when they simply would mot poll?
Macs btw don't make hardware assumptions. Every USB device I ever put into a Mac worked just fine, but granted: I never used fancy stuff ... however the more fancy the stuff is, the more expensive it is and the more likely it is working out of the box on a Mac.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
That's true that it isn't specific to C++. C++ has a lot of the same binary compatibility issues that C structs do, because classes are basically glorified structs under the hood. But IMO, C makes it a little easier to work around, because nobody assumes that they can make a struct bigger. Instead, assuming you're designing things with binary compatibility in mind, you add an extension field into the struct, and "subclasses" (so to speak) store their data in an opaque pointer at that location. For backwards compatibility, you just ensure that you never move or change the existing fields' offset within the base struct when you add new members to the end in a subsequent version of the struct, and ensure that the "subclasses" always call the official allocator function instead of malloc.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Well, one way, you can monitor heap usage and trend the usage immediately following full GCs.
The other way to look at it is as a function of time.
None of that applies to modern server-centric garbage collection (GC1). "Stop the world while I collect garbage" makes a server worthless if you have 64 GB and GB takes minutes, which is why the default GC for the server SDK hasn't worked that way since mid Java 7.
That's not quite true; even without a "stop the world" collector, you can still look at the amount of time the parallel GC thread is busy. In fact there seems to be quite a bit of information available with tools such as jstat. Perhaps this could help you better understand actual heap use (this is also a problem I face at work -- processes that run out of heap after many hours, expectedly... argh).
Some info about jstat: http://www.cubrid.org/blog/dev...
Info about G1 (although you already seem very familiar with it): http://www.infoq.com/articles/...
You are correct on the last, but not the preceeding items. I had the opportunity to talk about it with Carl J. Sasserath himself. IIRC, he was actually inspired by Smalltak, but don't take that as immutable truth.
The Amiga's OS consisted of several layers. The Exec, AmigaDOS, and the GUI, which internally subdivided into the layer and window systems. Everything was very modular.
AmigaDOS was indeed written in the "British Cruddy Programming Langue" based on a thesis project named Tripos. However, it was jammed on top of Exec, which was written in C. The results were occasionally awkward, as BCPL used word-based addressing and C was byte-based. Plus the BCPL and C stacks grew in opposite directions.
The C compiler used was Green Hills C, cross-compiling off Sun or Apollo Unix machines (again, memory is hazy here). Manx was the first C compiler native for the Amiga, followed by Lattice C. Manx was probably a Macintosh port, as it worked with 16 bit integers. Lattice worked with 32-bit integers, which was a more natural fit for the machine. Eventually, the 2 compilers adopted support for each other's word sizes and all became happy (more or less). By that point, Commodore was doing native development and no longer needed to cross-compile.
The Amiga OS source code had no embedded assembler that I'm aware of. Embedded assembler is a hallmark of complex monilithic systems. Exec was very minimalistic and so far as I am aware, the assembler components (primarily scheduler and interrupt services) were all separate source modules. The C compilers did add pragma directives to allow passing parameters in registers instead or (or in addition to) on the stack, support for volatile variables (for memory-mapped I/O devices) and similar.
C++ first began to get public notice about August 1986, which is when Amiga computers began to hit the street in quantity. But despite not being written in C++, Amiga's Exec mapped very well to it.
Check out the Wikipedia entry for Carl Sassenrath. I believe it has a link to a BYTE magazine article that discusses this.
An interesting thing about the Amiga's OS was that you could run a workhorse machine with GUI in 6MB of RAM. The equivalent port of Linux to the Amiga required 16MB. However, the Amiga's OS didn't support virtual memory, as the earlier Motorola 68000-series processors didn't have an MMU.
Dude, what?
You have to accept that Java has no 'flat objects' but only heap allocated ones. So the constructor/destructor stuff never will be available in Java.
I write in Java often enough to know that the latter is true. However it doesn't follow from the former. Also, you know java actually has constructors, right?
Regarding your rant about mutexes, I don't get what you want to say.
You swore at me and told me java didn't have mutexes making use of synchronized objects instead. You were mistaken and I proved that by pointing to the documentation for mutexes.
The rest of the reply is a garbled and rambling rant about things you believe I said but aren't actually in the post.
SJW n. One who posts facts.
C certainly can have some magic happening under the covers, but it's an order of magnitude less than what goes on in C++.
Well, that's exactly the assumption I'm questioning. Certainly it was true once, but I'm not sure the gap is anywhere near that wide any more. It's not just about the differences written into the language specs, like overloading and construction/destruction in C++. It's also about all the things that aren't specified at all but matter in practice.
Perhaps the balance will shift back a bit now that both C and C++ have incorporated more detailed semantics in some of the tricky areas into their recent specifications, particularly in terms of the memory access model and concurrency, but even that is just the headline example at the top of a long list.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You swore at me and told me java didn't have mutexes making use of synchronized objects instead. :)
Neither did I swore, nor did I say such a thing.
You said Java can not have mutexes, because it has no constructor/destructor idiom.
I said: it has, it is called synchronized objects, and does not need a constructor/destructor idiom.
Next try?
The rest of the reply is a garbled and rambling rant about things you believe I said but aren't actually in the post. The same I could say about you, with more truth in it
E.g. I write in Java often enough to know that the latter is true. However it doesn't follow from the former. Also, you know java actually has constructors, right? ... so what was the point exactly you wanted to make?
So, why do you write this nonsense, when we talk about your complaint that you can not use your beloved constructor / destructor idiom. Hu? What has that to do with knowing if or that Java supports constructors? Everyone knows that
You lost your argument and now you try to treat me like a child who forgot what it heard or said five mins ago. Unfortunately you only need to click back often enough to see what we both wrote.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I've been wanting this information for ages, thanks! Also, will be quite interesting to use this information in some upcoming C++ classes I'll be teaching.
The C++ committee would rather add a 2D graphics API that no one cares about to the language libs then focus on binary compatibility.
You not caring about a standardized 2D graphics API doesn't mean no one cares about it. A standard 2D API will be welcome as part of a larger standard library.
Now, if you really care about a standard ABI for C++, please, feel free to contribute. Here is the proposition from Herb Sutter: http://isocpp.org/files/papers/n4028.pdf
Amusing Note: Herb Sutter supports both the 2D API and C++ ABI propositions. You'll have the occasion to speak about both subjects to him, I guess.
C++ destructors can be used to deallocate any memory, or do other stuff that cannot go wrong. But they cannot be used to release any resources, like sockets, streams, files, connections, etc.
Of course they can.
Consider a resource whose release failure you could want to react upon, or not.
Sometimes, you want to react to it, sometimes you don't care. Have a "release()" method which will be called explicitly by you, with an error code or an exception, as you see fit. Then have the destructor call release() if the resources wasn't manually released, swallowing the error/exception. This means your object will always behave correctly as you want it: When you care, you'll handle it manually. When you don't, you let the destructor do it for you.
Indeed, in a variant, you could even replace the call to release with an assert (or a std::terminate) in the destructor, to catch the problem (if the resources was not released manually), for testing purposes, or design choice, or whatever.
Another variant, and your destructor does nothing. Another variant, and there is no release, and the destructor does everything.
The fact you missed is that destructor enables you to do whatever you want, depending on the desired resource release process.
This is CHOICE, and CHOICE is POWER.
Unlike in C.
clean up on isle5 mr. ac. why don't u sign your post
Actually, I do have to retract my statement about DO-178 standards: using these standards as-is wouldn't work for general-purpose computing kernels, and one giant reason is that DO-178 doesn't allow you to deallocate memory. Once it's allocated, that's it, it stays allocated forever. So "free" (C) and "delete" (C++) are forbidden. This would make your PC run out of memory pretty quickly. It's done in embedded systems because it provides deterministic behavior, and such embedded systems only do one task (or a small group of tasks), continuously, and unlike, say, a smartphone, aren't repurposed to do other things that use a lot of memory (such as running the Firefox mobile browser, then switching over to the Facebook app, then running Tinder, then playing Angry Birds, etc. There's not enough memory in a phone for all of that staying allocated at once.).
Anyway, perhaps a subset of the standards could be used, such as forbidding C++ exceptions. A lot of places I've seen do stuff like this: they use C++, but with a lot of specific rules on which features are and aren't allowed, and exceptions are a big one on the forbidden list. Basically, the main idea is places doing this kind of development like some of the C++ features like object-orientation and inheritance because it lets them avoid doing some of the nasty stuff you see in the Linux kernel, such as all the callbacks and tables used for mapping function pointers; with C++, you can just do that stuff using the standard OO features. Also, templated code: there's a huge pile of #define macros in the kernel which are really just implementing template code, which could easily be done with C++ templates instead. Shifting to C++ would allow eliminating many lines of code this way, and probably making some things safer (not having to worry that you're checking every function pointer for not-null before calling it, for instance), and theoretically this shouldn't affect performance if the compiler works correctly as the generated object code should be the same. It would be an interesting project to rewrite parts of the kernel in C++ and then compare, line-by-line, the object code and verify it's mostly the same and that performance isn't affected, and if it is, fix the compiler or at least identify specifically why it isn't the same.
Neither did I swore, nor did I say such a thing.
Last I remember, fuck was still a swearword. You said:
And for fuck sake, Java has build in support for multithreading,
Do you deny saying that?
You said Java can not have mutexes, because it has no constructor/destructor idiom.
I never said any such thing. Learn to read!
SJW n. One who posts facts.
This sounds like the QNX operating system all over again, but i don't really know. Small kernal, C++. The last time i heard the QNX kernel was 45k, maybe now it's a few megabytes. Could be very interesting. One of the things Linux has going for it is momentum in the marketplace. BOOS-MOOL if it's a successful implementation could challenge the Linux people to a new way of thinking.
Why can't you just look at the preprocessor output?
Go ahead and try it. Get the source code here.
When all you have is a hammer, every problem starts to look like a thumb.
true. But this is a case where (usually) the application has no way to try to fix whatever the underlying problem is, so you're still going to have to choose between ignoring it and terminating.
Gtk+/glib comes to mind at once, with their GObject infrastructure.
Curious in this context is a quote I read somewhere by someone giving reasons why Gtk+ could absolutely not run faster (than Qt, iirc): "Because there is a whole lot of strcmp() which cannot be dispensed with." Now I see why in more specific details: Because this is how classes are identified in Gtk+, whereas in C++, they become integers.
"substandard programmers" is not a cop-out argument. it is a very legitimate concern in the context of trying to use C++ and maintain a giant code base with people contributing from all over the place. C++ is a language with lots of wonderful things. if those things are used by somebody who does not fully understand them, though, it can lead to terrible results, and there are quite a lot of things to know.
If you spent half the time perusing the spec than you spent duplicating the STL, you would not find the behaviour "unexpected", you'd save time and other people would find it easier to follow your code.
This.
I had been away from C++ for a little over a decade (got suckered into web design among other things). When I came back to it two years ago, I was pleasantly surprised at the improvements in the language. Specifically, the STL improvements, and the Boost libraries made light work of projects that used to take forever to code and debug. Even the string class I found to be indispensable, even if its interactions with non-c++ code is less than optimal, it still beats C-style string manipulation by leaps and bounds.
Having used Java, PHP and Perl in the mean time, I found C++11 to have incorporated many of the best features of these other languages without loosing much of the performance that was the reason I had gone back to C/C++ for this project.
I wish I had a good sig, but all the good ones are copyrighted
Thanks - first piece of helpful advice in the thread! I'll definitely try out "G1 stopping the world" as a warning sign.
I'd also say this - if you're capable of writing C++ without any resource leaks you're capable of writing Java without any resource leaks. In which case memory usage will be predictable and simple load testing will show you how big a heap you need to allocate.
Our memory usage scales with load. Our load scales with usage. Predictions about growth in popularity of our product are all very well, but no excuse for not monitoring for impending doom (especially since we have some legacy code that doesn't scale horizontally and so we have to keep throwing more memory at the problem for those services until we can fix that).
A better solution of course is to not use a language that requires stupidly huge amounts of memory to do anything, but I'm sort of stuck with Java. I'll be happy enough when we've killed all the Ruby with fire.
Socialism: a lie told by totalitarians and believed by fools.
Unortunately, you can't use any of that in the kernel [overloading create/destroy new/delete operators won't cut it]. Spinlocks, rwlocks, RCU, slab allocation, per cpu variables, explicit cache flush, memory fence operations, I/O device mappings, ISRs, tasklets, kmalloc vs vmalloc, deadlocks, livelocks, etc. are the issues a kernel programmer has to deal with. Nothing in C++ will help with these and some C++ constructs are actually a hindrance rather than a help.
My experience differs. I've used C++ to greatly simplify many of those issues. "Placement new" is perfectly suited for slab allocation. What's more, you can switch a specific struct between slab allocation and normal allocation (or vice versa, more likely) without a significant re-write. Locking constructs are just objects, and number one advantage of C++ over C -- automatic object cleanup on scope exit -- is the greatest boon ever to lock management. Sure, no real difference for the various alloc types, (though all the C++ standard library container classes support custom allocators, it's rarely the right choice).
Yeah, sure there's plenty of stuff like thinking through deadlocks and priority inversions that no low-level language is going to help with, but there's also plenty of stuff where C++ is simply less error-prone than C, and involves less boilerplate, making algorithmic mistakes perhaps easier to see without the clutter.
Socialism: a lie told by totalitarians and believed by fools.
Nothing you said was language-specific (except that C offers the smallest toolkit of any language). Only use special-purpose tools for the purpose they were specially built for - don't go looking for excuses to use them elsewhere. If the only non-C part of C++ you ever use is the automatic clean-up of objects when you exit scope, you have a huge win just from that. Half the lines of code at least in a well-written C program vanish, and the actual logic of functions emerges from the clutter.
I swear, when some people think C++ all they know is "huge poorly documented class hierarchy I'll be forced to use", which is entirely not the point of the language (a decade of MS brain damage nonwithstanding).
Socialism: a lie told by totalitarians and believed by fools.
The biggest mistake you can make in any language is to catch an OOM error and proceed (except in the very special case of deliberately exhausting memory in a single-threaded process to get the biggest possible buffer or whatever). It's more general in Java: don't catch throwable unless you then exit. No, not even then. Restarting is fine, but proceeding often leads to undefined behavior.
I thought you said sane C++ doesn't leak resources?
If you've never worked on code that can exhaust memory of even a big server without leaking resources, perhaps that explains why you think it's safe to catch throwable.
Socialism: a lie told by totalitarians and believed by fools.
The code example you gave is pretty clear.
What does my example code do, would you say? It's tripped up many good programmers over the years.
Copy constructors or operator= don't add any "obscurity" to C++.
Wait, what? Are you replying to the right post?
The problems of macros and compiler arguments has nothing to do with C versus C++ programming/reading/debugging
Source debuggers and macros mix poorly, was my point, because what you really want is to step-by-step debug through the pre-processor, not the generated code, to see how the heck that got generated, or in the really bad cases, to have a clue what got generated.
Socialism: a lie told by totalitarians and believed by fools.
Touche! A fair point.
Socialism: a lie told by totalitarians and believed by fools.
Thanks - useful tool. I guess we can do some tuning to see if there's anything useful to alarm on (we allocate a very large list very few minutes, and if the list grows too large everything fails - but possibly everything we care about will be "young", which makes this all non-trivial.
Socialism: a lie told by totalitarians and believed by fools.
If you had destructors like in C++, your program would terminate when the close() fails because it couldn't flush the buffer or there was a problem with the socket, or whatever. Is that really what you want? It's not what I want.
dom
Well, no, not every programmer lives in the C++ world...
Err... you too are posting as AC. Is that the joke?
No, it doesn't. An OOM error in Java means the stack is unwound to the point where the error is caught, just like with any other throwable. While this can cause problems if the error occurred in the middle of a complex data structure manipulation, that can be worked around (for example by using immutable data structures). In my experience such programs work perfectly reliably, they simply require some more forethought.
Ooh, burn! But do explain to me how restarting helps in that case? Surely your code will use just as much memory on rerun than on the first? Unless, of course, some of that memory was actually being taken up by accumulated cruft that had not been freed despite no longer being needed - in other words, a resource leak.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Any programmer worth their salt (and if you're not, you have no business writing system-level code), can (and does) structure their code in an object-oriented fashion in C. Inside a function, you should generally be writing code that resembles functional code (perhaps minus the recursion). You make a struct to encapsulate data and you write functions ("methods") to handle them. Internal to a function, your code should strive to be stateless (and various other things that resemble functional programming).
Long story short: stop blaming the tools. PEBKAC.
Oh, yeah, immutable data structures, those work great for code that runs on a whiteboard. :p I just spent a year cleaning up and refactoring code where someone thought immutable data structures were clever - it's hard to make code run unacceptably slow without being I/O or lock bound, but spend enough time copying data around in code that was CPU-intensive anyhow, and you can manage it!
Anyhow, I've never seen a large code base, written and maintained by the usual diverse range of developer competencies, where it was safe to proceed after unwinding too far "such programs work perfectly reliably, they simply require some more forethought" indeed. In my current case, restarting actually will help, because of the way in-memory caching was done (which design required more forethought than it was given).
Man, it seems like too much of my recent career has been spent re-doing someone's "oh so clever" idea, instead in the most straightforward and obvious way, and gaining a 100x performance increase, or a 10x memory improvement, or getting horizontal scalability by abandoning some technology that some developer was just in love with, and would not let go of, despite it's inability to scale out.
Socialism: a lie told by totalitarians and believed by fools.
So you're blaming C for someone writing bullshit code in ANOTHER LANGUAGE?
The macro preprocessor is its own bit which runs before the lexer and parser for C. You don't need to touch it for the most part, beyond things like include guards (which aren't a C thing anyway, and only exist for the purpose of making it easier to turn the project into one giant file). C itself doesn't know anything about includes, header files, or macros. Everything is expanded and replaced BEFORE the proper C stage begins--hence preprocessor. If you wanted, you could replace the preprocessor with some other language. Have at.
Don't blame C for the failings of another language or a person abusing the macro preprocessor when they should've written their code in C instead. You're only demonstrating how little you actually know about C.
"Substandard programmers" is pure rhetoric and Linus knows it. He is not a dummy when it comes to debating and is very clear on what is and is not a logical falacy. When he makes an unfalsifiable claim like "substandard programmers" that is simply his way of saying shut up, my ears are closed.
When all you have is a hammer, every problem starts to look like a thumb.
That's called being understaffed. The person who wrote the code is the person least qualified to review it. I know there's plenty of occasions I spent an hour looking for a missing comma or something equally stupid (usually due to a misleading compiler error) and the minute I had a co-worker look it over, they spotted it. Your brain sees what it expects to see.
Every sufficiently large C project re-invents key portions of OOP, poorly. I've been involved with a couple such efforts myself. There's just no excuse for the NIH-ism. An OOP language compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
There fixed it for you... no need to bring C++ into it.
I agree with what you say, but it wasn't "whoosh". My point is that the "if you were doing the same thing in C/C++" comment is incorrect on two levels.
1. There is no such thing as "C/C++".
2. No C++ programmer worth their paycheck would ever do this. (Yes, yes, I can think of situations where it's kosher, too. You know what I mean.)
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Every sufficiently large C project re-invents key portions of C++, poorly.
So does every new C++ standard.
Rubbish on one claim, yet you accede to all the other, more substantive and important claims?
When I said "If you were doing the same thing in C/C++" I meant hanging onto a pointer after freeing the memory. Which you can do in both languages and which will cause you no end of problems later on.
NASDAQ large stock exchange system on Wall Street called INET (and derivative system INET Genium), fastest in the world with sub 100 microseconds latency and enormous throughput, both of the exchanges are written in Java. The trick to achieve extreme Java performance is to never trigger the GC. NASDAQ do it by preallocating lot of objects and constantly reuse them. If you do this, you get predictable RAM behaviour.
Real time Java sucks if you need extreme Java performance.
Initial refuse of source control and in-kernel debugger? No, you must be kidding. Have you any links??
> ...a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated.
Hear, hear. I was Googling on C++ trying to get answers to a few questions, and came across this gem:
I checked out mentally at that point. If you can't look at the code and have a clear picture of what it's going to do, you're not a programmer, you're an alchemist!
Rubbish on one claim, yet you accede to all the other, more substantive and important claims?
Fallacy.
When all you have is a hammer, every problem starts to look like a thumb.
Our memory usage scales with load. Our load scales with usage. Predictions about growth in popularity of our product are all very well, but no excuse for not monitoring for impending doom
Of course. But testing will tell you something like "a single instance with a 32GB heap will support 9000 tx/sec with acceptable 99.9% latency". So you can monitor traffic levels and scale out as appropriate well before something monitoring GCs starts seeing problems. Where I work we deal with request rates in the 100k/s range and so if things go wrong they do so very fast - the trick is to know the limits and stay well away from them!
(especially since we have some legacy code that doesn't scale horizontally and so we have to keep throwing more memory at the problem for those services until we can fix that). :) Be wary of getting too big. I'm a JVM fan but if you start going above 100GB you need to be careful - GC pauses can start getting extremely significant and tuning new/eden becomes very important. Over 200GB and you're bleeding edge. If you have the budget look at Azul - their stuff is amazing.
Oh fun
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
C++ simplifies by implicitly performing actions. These implicit actions are what undermines C++ use in system/multi-threaded code.
- A data declaration *may* invoke code (constructors)
- Method calls *may* invoke other (virtual) code.
- Use of STL *may* do whatever it wants.
In short, C++ tries to do what it thinks you want, rather than what you tell it to do. Whereas system coders need to know exactly what a piece of code does, just by looking at it, with C++ you pretty much need to step through the code in a debugger to be sure what is going on. Anyone who has spent any time debugging g++ knows how much fun that can be as you are continuously stepping into constructors for std::string, STL, etc. Add threads for a new level of debugging debauchery. And of course the pinnacle of masochism is debugging kernel code.
The following page lists c++/gdb issues: http://pdqi.com/cgi-bin/cgiwra...
For example with the file, the application could ask for an alternative file location.
Or if the socket can't disconnect, the app can ask the user to connect to the internet again.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
I think I would have to disagree with almost everything you've written. I have written a "hobbyist OS" purely with C++ (a little glue ASM mixed in), and basically all of the constructs you mention created absolutely no issues. Heck some of the things you mention (such as per CPU variables, memory fense operations, ISRs, livelocks, deadlocks, spinlocks, rwlocks) have little to nothing to do with the choice of high level language at all. You write some macros with some inline ASM (or just write some ASM for the ISRs) and you're good to go. Some of these constructs (for example, rwlocks) are EASIER to get correct in C++ because you can use scoped locks to ensure correctness without resorting to goto's (something you'll find sprinkled throughout the Linux kernel).
Addressing some of your follow up paragraphs:
For instance, copy constructors must be disabled. This was part of a proposal a few years back to make a C++ subset suitable for realtime/embedded. It isn't acceptable to have "x = y" invoke an unexpected amount of code simply because you inadvertantly invoked a copy constructor.
This is a silly argument. This really just boils down to the programmer knowing what the code he is calling does. If you are not using a basic type, feel free to assume that calling the copy constructor may be expensive... it's that simple. On the other hand, C++11 move semantics make it so you can use value semantics with the cheapness of copying pointers... a win/win. In my personal kernel, I have implemented most of libstdc++ in kenel space. I know that copying a std::string may be expensive, so I don't do it in time critical places. I also know the nuances of how I implemented my std::string, so I am very familiar with how I can expect it to perform.
copy-constructors are just another function call, anyone allowed to modify the kernel should know to look at the cost of the function they intend to call. If for a given type the performance metrics are too irratic or poor, then the class creator can explicitly make the type non-copyable.
I understand that my hobbies don't compare to the Linux kernel in a substantial way, but I can say that in my experience, this really has not been an issue at all.
Kernels by their nature are messy. Anybody writing kernel code must be fully aware of the implications of doing something and must be aware of the state they're being called in. Abstraction just makes this job harder not easier.
I agree with everything here except your last sentence. Yes, they should be aware of the implications of the code they write. But abstractions can make code EASIER to understand if use appropriately. For example, I know that I can use just about any algorithm in and get very specific performance in the code because the c++ standard mandates the performance characteristics. I can call std::merge, know what it does and can know at most how many comparisons it will do, because it is guaranteed.
For example, all kernel code must be compiled with -mno-red-zone because of the threat that any base code could receive an interrupt at any time [even between 2-3 machine instructions that comprise the red zone setup code].
Bad example, as it has nothing to do with C++. compiling C code also needs this flag. This is a "compilers on x86-64" issue, not a C++ issue.
Linux already does a pretty fair job of keeping things clean. If you don't believe that, actually go read the kernel source code. And, if something ends up being crufty, it gets cleaned up. Even if that means that some 100 or so modules need corresponding changes.
I agree, Linux does a very good job of making things clean. There are some areas which could be cleaner though. For example, the Linux way of handling linked lists is to have a member in middle of the data structure which is the "link" node, which points to the "link" node of another element. To get the base element, you need to do some ar
placement new doesn't work without nullifying a few things. Automatic cleanup on scope exit doesn't work for locks in the kernel. See below ... Much more ...
placement new/delete are noexcept functions. But, they call std::terminate--not acceptable. The only thing that works is an alloc function that returns NULL (or (void *) -errno). Returning null is not fatal in the kernel. The caller must be able to deal with it (usually returning -ENOMEM). So, the [global] new/delete must be changed. Also, placement delete has problems [I've left off the backslashes for clarity]:
#define GETPTR(_ptr,_typ,_siz) // ...
switch (_typ) {
case 0:
_ptr = alloca(_siz);
break;
case 1:
_ptr = kmalloc(GFP_KERNEL,_siz);
break;
case 2:
_ptr = kmalloc(GFP_ATOMIC,_siz);
break;
case 3:
_ptr = slab_one(_siz);
break;
case 4:
_ptr = slab_two(_siz);
break;
}
void
myfnc(int typ)
{
void *ptr;
GETPTR(ptr,typ,23);
class abc *x = new(ptr) abc(19,37);
}
At this point, a delete operator [even a placement version] has no idea which pool to release to because there's no way to pass typ to it. You might be able to create a contructor abc(typ,19,37) but that adds an extra member element to hold typ so the delete operator can get at it, but that's additional overhead/complexity that C doesn't have. It might be possible to make it work by casting typ to void* and using that as the pointer:
class abc *x = new((void *) typ) abc(19,37);
and have the class specific new operator use GETPTR internally. I tested this and it works. However, I haven't yet been able to get the corresponding placement delete to work as a class specific overload [yet]. In trying to find the way, I came upon:
http://www.scs.stanford.edu/~d...
It's fairly detailed and lays out a [pretty strong] case against using the new operator [more eloquently than I could do here].
A lot of kernel code puts definitions in the usual place [top of function body] for C. In C++, this invokes the constructor, which is not what you want. The reason is that [say] 10 vars are defined. The function does a quick check on args and does a non-standard return -EINVAL. All that wasted create/destroy. This may be harmful if the constructors have side effects such as lock acquisition. Note that doing a [wasteful] lock followed by an immediate unlock [to satisfy having a destructor do lock cleanup] is a non-starter in the kernel [you'll never get such code checked in/signed off on]
So, you'd have to go through every kernel function by hand [there are 16.9 million lines of source code] and move the definitions down: ... ...
{
struct foo x;
if (bad_news)
return -EINVAL;
}
{
if (bad_news)
return -EINVAL;
struct foo x;
}
You can't put a lock release in a destructor because you'd need an extra member var that would have to be set/cleared when you acquire/release a lock. That's because the destructor has to have some way of knowing whether to suppress the lock release. So, you're adding an extra variable [that isn't needed in C] just to prevent an attempt to release a lock that was never acquired in the first place. More overhead and slower [and more complex] than its C counterpart.
I
Like a good neighbor, fsck is there
BTW, you can use <code> or <tt> on Slashdot (I find the latter works better for indenting).
Thoughtful post. Couple of notes. You seem to worry about a mix of non-trivial constructors and existing code, but of course for all existing code the constructors are trivial. You can't quite compile C code as C++ and get exactly the same object, but it's pretty close (still, not 100% so of course you couldn't blindly do it for a large code base).
As far as placement new, well, I guess it depends on what you're doing with slab allocation. We were hyper-paranoid about dangling pointers and slot re-use, rather than trying to count clock cycles, so everything that was allocated in slabs had meta-data before it anyway, so delete knew what class it was working on. (Every function argument that was a pointer to an important type was checked that it still pointed to an instance of that type, that the instance hadn't been freed, and that the generation number of that instance was as expected. We caught so many bugs that way.)
As far as locks - of course there's no one pattern that fits every use case, but the "try to get the lock, if we get it, use the locked object, then whatever you do be damn sure to release any lock on the way out" is a really common pattern, and one that junior programmers somehow manage to screw up from time to time. Turning this:
get_lock_a(); // do stuff // do more stuff // do even more stuff
x = find_object_in_a();
if (! x)
goto release_a;
get_lock_b();
y = find_object_in_b();
if (! y)
goto release_b;
release_lock_b();
release_lock_a();
return 0;
release_b:
release_lock_b();
release_a:
release_lock_a();
return -EINVAL;
into this:
Lock lock_a(a); // gasp, horror, return in the middle!
// do some stuff;
x = find_object_in_a();
if (!x)
return ERROR;
Lock lock_b(b);
y = find_object_in_b();
if (!y)
return ERROR;
return 0;
Is more clear for the missing boilerplate, and requires far less demanding code reviews. Too much culture shock for traditional C kernel guys though, I guess.
It's probably also worth pointing out that in many (all?) contexts these days, security trumps a doubling of performance. We're none of us perfect - but I never released a resource leak in the 12 or so years I did low-level stuff. And it wasn't because I was the unerring master of matching alloc at the top with free at the bottom! You name a typo that compiles, I made it! But there are coding styles less demanding (and less tedious), by eschewing the boiler plate that must be perfect every time.
Socialism: a lie told by totalitarians and believed by fools.
I can see the point of writing an OS kernel in C++ if you wanted to experiment and do research into OS ideas. But to rewrite Linux in C++... all you'd end up with is yet another UNIX kernel. Why do we need another UNIX kernel written in another language? UNIX is not that interesting anymore. It's been done already. Write something new and interesting in C++.
Oracle VisualVM should be good enough, even works on Linux.