How HHVM Uses Modern C++ for Fun and Profit (2014) [video](youtube.com)
youtube.com
How HHVM Uses Modern C++ for Fun and Profit (2014) [video]
https://www.youtube.com/watch?v=XqK8Yuoq4ig
4 comments
He did not ignore C, he said C++ is much easier to maintain and lets you use friendly features when it's not performance expensive. They use template as much as possible over macros, C++ debuggers, lambdas, ref counting.
I haven't watched the last 10 minutes yet, but there's no mention of C in the talk before that. The only comparison is to Assembly.
And I can't really rewatch the first half hour, but I distinctly remember he mentioned C at least two times at the begging, slightly before and during "Why C++" part. The examples of template usage also imply things not possible in C.
Interesting, do you have link where that comment was made?
Meh. In most software test suites don't accurately portray or reflect real world workloads or results. I interpret this as 'our test suites are embarrassing'
I don't care about "real world workloads" when measure a programming language. There network latency or disk/database i/o would dominate in most cases.
I'm interested in the raw language speed/memory use in its native form, which is a good indicator of what you can do with it (e.g. "can you do number crunching? is it good for 3d rendering? can it tackle writing a fast compiler in it?" etc).
I'm interested in the raw language speed/memory use in its native form, which is a good indicator of what you can do with it (e.g. "can you do number crunching? is it good for 3d rendering? can it tackle writing a fast compiler in it?" etc).
I remember someone from Facebook saying that ( can't find the link ATM ) when HPHP was being built there was a competing project to trans-compile PHP to Java. In the end they compared the performance and found that the C++ was faster and went with it. Is it true ?
If it is, I wonder how they feel now that they have given up speed improvements and built a VM in search of other advantages. At least if they had chosen the JVM they could have taken advantage of interoperability that JVM provides with other languages to convert at least part of their code base to JVM languages, thereby possibly improving maintainability.
If it is, I wonder how they feel now that they have given up speed improvements and built a VM in search of other advantages. At least if they had chosen the JVM they could have taken advantage of interoperability that JVM provides with other languages to convert at least part of their code base to JVM languages, thereby possibly improving maintainability.
Are you possibly referring to Quercus? https://en.wikipedia.org/wiki/Resin_%28software%29#Quercus
I was expecting a talk about how cool C++11 features are. It was actually a talk about how C++ lets you be super close-to-the-metal and do ridiculous performance hacks. Interesting.
Nobody uses C++ for fun. Unless they're a masochist.
I do, and I'm not a masochist. I use it to write small games on my own time.
I used to loathe C++, but the C++11/14 dialect makes things much more pleasant. There's still a lot of details you need to worry about, but crucially these are details that other languages rarely give you a choice about. The only real alternative was C, but I'm tired of reinventing wheels and C++ has the STL. C also doesn't have the same support for value types which C++ does, and value types are really nice to use.
I used to loathe C++, but the C++11/14 dialect makes things much more pleasant. There's still a lot of details you need to worry about, but crucially these are details that other languages rarely give you a choice about. The only real alternative was C, but I'm tired of reinventing wheels and C++ has the STL. C also doesn't have the same support for value types which C++ does, and value types are really nice to use.
Value types, as opposed to polymorphic types, ie pointers (including references)?
struct IntForFoo { int value; };
when you use it you write a function that takes an IntForFoo as one of its arguments and you get type safety over other ints. Gently snarl at anyone who does a .value outside such a function. Include a constructor function, an assignment function... Remember that that typedefs just lie to you about the type, they don't change it for type checking...
If you need to generate code, do it, macros and templates are just really crappy ways of generating code; you can do a lot better when you need to. But how often do you really need to and how often are you worshipping at the false idol of "must be general so can be used for 100 years" when that's really not the purpose of the code?
Polymorphism and templates are overrated by C++ designers you don't actually need them and they encourage some awful designs.
struct IntForFoo { int value; };
when you use it you write a function that takes an IntForFoo as one of its arguments and you get type safety over other ints. Gently snarl at anyone who does a .value outside such a function. Include a constructor function, an assignment function... Remember that that typedefs just lie to you about the type, they don't change it for type checking...
If you need to generate code, do it, macros and templates are just really crappy ways of generating code; you can do a lot better when you need to. But how often do you really need to and how often are you worshipping at the false idol of "must be general so can be used for 100 years" when that's really not the purpose of the code?
Polymorphism and templates are overrated by C++ designers you don't actually need them and they encourage some awful designs.
One of the problems with structs in C, is that you must explicitly call the destructor function if you have non-memory resources. In C++, a scope's closing } always takes care of that for you.
As for the generated code bit, I assume you're referring to the STL. Writing my own data structures is explicitly what I don't want to do anymore. STL has it? Great, I use it and move on.
As for the generated code bit, I assume you're referring to the STL. Writing my own data structures is explicitly what I don't want to do anymore. STL has it? Great, I use it and move on.
Sure use it if you understand it, ie vector where you reserve the memory up front to avoid future allocations and pointer/iterator invalidations or you don't care in which case use a friendlier or more powerful language maybe?
Writing datastructures is much of what programming is, I know that's not what you meant and you use the basics of STL to build the real datastructure you want, but you care about performance and with STL it's not targeted at your case so when you get beyond prototype you have to rip it out anyway.
Automatic destructor calls on leaving scope is the nicest part of c++ - shame it interacts with exceptions so nastily that nobody understands how it works. "Exception safe code" yeah, right, not in c++.
Generated code - you can use macros, you can use templates. Or you can use anything that generates text and does what you want, more nicely than that.
Writing datastructures is much of what programming is, I know that's not what you meant and you use the basics of STL to build the real datastructure you want, but you care about performance and with STL it's not targeted at your case so when you get beyond prototype you have to rip it out anyway.
Automatic destructor calls on leaving scope is the nicest part of c++ - shame it interacts with exceptions so nastily that nobody understands how it works. "Exception safe code" yeah, right, not in c++.
Generated code - you can use macros, you can use templates. Or you can use anything that generates text and does what you want, more nicely than that.
> Sure use it if you understand it, ie vector where you reserve the memory up front to avoid future allocations and pointer/iterator invalidations or you don't care in which case use a friendlier or more powerful language maybe?
std::vector implements one of the simplest data structures in computer science. If somebody doesn't understand the difference between, say, an array (however you want to call it) and a linked list, I don't want them on my team.
> Writing datastructures is much of what programming is, I know that's not what you meant and you use the basics of STL to build the real datastructure you want, but you care about performance and with STL it's not targeted at your case so when you get beyond prototype you have to rip it out anyway.
What are you talking about? More than a decade ago, there was a lot of interest in what kind of penalty there was in using C++ compared to C. There were several benchmarks run and papers written, including one from Alexander Stepanov (main contributor to the STL) that became an appendix to the standard ( http://std.dkuug.dk/JTC1/SC22/WG21/docs/PDTR18015.pdf ). The conclusion from the various experiments was that C++ performance was on par with C, and C++ often provided opportunities to optimize more than C did (e.g., passing a pointer to a function in C to the more common C++ practice of passing a functor with an inlineable operator()). The STL relies on those features that allow for a very efficient implementation. In fact, the main complaint I've seen is that the STL struck the wrong balance of preferring efficiency over generality ( http://www.open-std.org/JTC1/SC22/wg21/docs/papers/2007/n227... , http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n185... ).
> Automatic destructor calls on leaving scope is the nicest part of c++ - shame it interacts with exceptions so nastily that nobody understands how it works. "Exception safe code" yeah, right, not in c++.
A decade ago, there was a period of maybe six months where people thought it might be impossible to write exception safe code in C++. It was solved, and the solution was to use destructors. You may have heard of RAII ( http://stroustrup.com/except.pdf ). Alexandrescu even made it incredibly simple to do ( http://www.drdobbs.com/cpp/generic-change-the-way-you-write-... ).
> Generated code - you can use macros, you can use templates. Or you can use anything that generates text and does what you want, more nicely than that.
So I have a choice between using templates, which provide syntax checking and type checking, or generating text in an ad-hoc way? And you actually recommend monkeying with text generation?
For what it's worth, I do like C. But when I work in C, I need to rely on something like Apache's APR or GNU's glib to provide me with useful data structures. While those have been ported to all architectures I care about, there's something to be said for having data structures in the core library.
I like C11. I like using _Generic in macros. I like variable argument macros. But if I'm working on a project where I need variable argument macros, I'm much more likely to pick C++ than to try to convince myself that I'm generating correct source code through macros.
std::vector implements one of the simplest data structures in computer science. If somebody doesn't understand the difference between, say, an array (however you want to call it) and a linked list, I don't want them on my team.
> Writing datastructures is much of what programming is, I know that's not what you meant and you use the basics of STL to build the real datastructure you want, but you care about performance and with STL it's not targeted at your case so when you get beyond prototype you have to rip it out anyway.
What are you talking about? More than a decade ago, there was a lot of interest in what kind of penalty there was in using C++ compared to C. There were several benchmarks run and papers written, including one from Alexander Stepanov (main contributor to the STL) that became an appendix to the standard ( http://std.dkuug.dk/JTC1/SC22/WG21/docs/PDTR18015.pdf ). The conclusion from the various experiments was that C++ performance was on par with C, and C++ often provided opportunities to optimize more than C did (e.g., passing a pointer to a function in C to the more common C++ practice of passing a functor with an inlineable operator()). The STL relies on those features that allow for a very efficient implementation. In fact, the main complaint I've seen is that the STL struck the wrong balance of preferring efficiency over generality ( http://www.open-std.org/JTC1/SC22/wg21/docs/papers/2007/n227... , http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n185... ).
> Automatic destructor calls on leaving scope is the nicest part of c++ - shame it interacts with exceptions so nastily that nobody understands how it works. "Exception safe code" yeah, right, not in c++.
A decade ago, there was a period of maybe six months where people thought it might be impossible to write exception safe code in C++. It was solved, and the solution was to use destructors. You may have heard of RAII ( http://stroustrup.com/except.pdf ). Alexandrescu even made it incredibly simple to do ( http://www.drdobbs.com/cpp/generic-change-the-way-you-write-... ).
> Generated code - you can use macros, you can use templates. Or you can use anything that generates text and does what you want, more nicely than that.
So I have a choice between using templates, which provide syntax checking and type checking, or generating text in an ad-hoc way? And you actually recommend monkeying with text generation?
For what it's worth, I do like C. But when I work in C, I need to rely on something like Apache's APR or GNU's glib to provide me with useful data structures. While those have been ported to all architectures I care about, there's something to be said for having data structures in the core library.
I like C11. I like using _Generic in macros. I like variable argument macros. But if I'm working on a project where I need variable argument macros, I'm much more likely to pick C++ than to try to convince myself that I'm generating correct source code through macros.
> Automatic destructor calls on leaving scope is the nicest part of c++ - shame it interacts with exceptions so nastily that nobody understands how it works. "Exception safe code" yeah, right, not in c++.
OK, I think I figured out what this was referring to. Generally a constructor initializes an object, and the destructor undoes all of that work. If a constructor throws an exception before it completes, the destructor is never called. This is a common interview question, because it surprises people. But there's no way for the compiler to figure out which parts of the destructor must be run (to clean up things that completed successfully) and which parts must not be run (because they refer to things that were never initialized).
The solution to the problem, amusingly, is to create more destructors. It's trivial to run the destructor for any objects that were created as part of an object's construction, so the compiler does promise to do that. To make this concrete, if a Foo object has members of types Bar and a Baz, and the Foo constructor also creates a temporary Quux and opens a network connection, throwing an exception from Foo's constructor will cause any successfully-created Bars, Bazes and Quuxes to be destroyed, but the network connection won't be closed because the compiler doesn't know that close_connection() must be called for every successful open_connection(). But if you wrap those open_connection()/close_connection() calls in an RAII object, you can guarantee that they'll be cleaned up correctly.
OK, I think I figured out what this was referring to. Generally a constructor initializes an object, and the destructor undoes all of that work. If a constructor throws an exception before it completes, the destructor is never called. This is a common interview question, because it surprises people. But there's no way for the compiler to figure out which parts of the destructor must be run (to clean up things that completed successfully) and which parts must not be run (because they refer to things that were never initialized).
The solution to the problem, amusingly, is to create more destructors. It's trivial to run the destructor for any objects that were created as part of an object's construction, so the compiler does promise to do that. To make this concrete, if a Foo object has members of types Bar and a Baz, and the Foo constructor also creates a temporary Quux and opens a network connection, throwing an exception from Foo's constructor will cause any successfully-created Bars, Bazes and Quuxes to be destroyed, but the network connection won't be closed because the compiler doesn't know that close_connection() must be called for every successful open_connection(). But if you wrap those open_connection()/close_connection() calls in an RAII object, you can guarantee that they'll be cleaned up correctly.
Yeah you probably DO understand std::vector which is what I said.
You probably don't understand std::list and std::deque forget std::rope std::map std::unorderd_map, std::set etc. etc.
I know I don't. I know what they do, I know how they're probably implemented. I know their big O characteristics etc. But they're optimised for high level generality not for the thing I'm doing on the hardware I'm targeting. I don't know how they perform on particular hardware, how cache sizes affect them etc etc etc. You have to find that out for yourself, hopefully by benchmarking before you use them, rather than finding out they suck very, very hard in production.
Bjarne Stroustrup himself as chief c++ booster says: "Everybody gets this wrong" when comparing something as simple as std::vector to std::list in performance.
"Everybody gets this wrong" --Bjarne Stroustrup
Maybe you're smarter than the rest of us, it's entirely possible but the rest of us use this language and that's what I'm talking about here. Eh see for yourself.
https://www.youtube.com/watch?v=YQs6IC-vgmo
Note that the benchmark he shows is not available, and it's not available in the STL. It might perform completely different on your embedded project. Eh so you have to write this benchmark (and all the others you might need) yourself. Write it every time you need to use an STL container that isn't vector and you care before you have the evidence you need to reject it. Seriously. WTF is up with that?
You have to care? Write your datatructure and algo yourself, you can reason about how the memory is used, how the caching performs. How the compiler vectorises, inlines it. You have an idea of the assembly language that will be generated (or at least you should). If you look at an STL implementation you feel your eyes bleed. It's ridiculous, what instructions will the compiler produce, hell what c++ code will it even compile?
But if you dont' care it's fine - and there are great reasons not to care. Being in a situation where you don't have to care is awesome, use them. Eg setup code that can be slow before you get the the stuff that has to be fast.
I have never seen an exception safe C++ codebase, I don't believe such a beast exists. Even if it does it's a properly hard problem that you can't keep in check with multiple committers. Just see how much time Herb Sutter and Alexandrescou (who has now dumped c++ as needing to become a legacy language) put into trying to explain how to do it. And failing to do so. The idea "exception safe" in c++ easy is only entertained by those who don't understand the problem. Scope guard is not a magic bullet. How does the silly contrived example of opening a file work with multiple threads? Look at his example, push_back of a pointer onto a vector. I've never seen anything other than
vec.push_back(ptr); //get on with life
in the wild. But hey, maybe I'm missed some and it's only 99% of c++ code that is by the Alexandrecou definition "exception unsafe" Maybe 99% of c++ programmers aren't smart enough to program in the language?
If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way. Haskell might, python, ruby, scheme might.
The whole point of C and C++ is being able to get that really low level performance.
Yes totally, I DO recommend "monkeying with text generation" because you won't do it unless you actually need to. Templates have the opposite characteristic, sadly.
(And just quietly, to hell with the bozo who voted me down to 0 for participating in this discussion, you're not very bright, responding as maxlybbert did is the correct thing to do if you disagree, disagreement is what this whole thing is all about otherwise why bother?)
You probably don't understand std::list and std::deque forget std::rope std::map std::unorderd_map, std::set etc. etc.
I know I don't. I know what they do, I know how they're probably implemented. I know their big O characteristics etc. But they're optimised for high level generality not for the thing I'm doing on the hardware I'm targeting. I don't know how they perform on particular hardware, how cache sizes affect them etc etc etc. You have to find that out for yourself, hopefully by benchmarking before you use them, rather than finding out they suck very, very hard in production.
Bjarne Stroustrup himself as chief c++ booster says: "Everybody gets this wrong" when comparing something as simple as std::vector to std::list in performance.
"Everybody gets this wrong" --Bjarne Stroustrup
Maybe you're smarter than the rest of us, it's entirely possible but the rest of us use this language and that's what I'm talking about here. Eh see for yourself.
https://www.youtube.com/watch?v=YQs6IC-vgmo
Note that the benchmark he shows is not available, and it's not available in the STL. It might perform completely different on your embedded project. Eh so you have to write this benchmark (and all the others you might need) yourself. Write it every time you need to use an STL container that isn't vector and you care before you have the evidence you need to reject it. Seriously. WTF is up with that?
You have to care? Write your datatructure and algo yourself, you can reason about how the memory is used, how the caching performs. How the compiler vectorises, inlines it. You have an idea of the assembly language that will be generated (or at least you should). If you look at an STL implementation you feel your eyes bleed. It's ridiculous, what instructions will the compiler produce, hell what c++ code will it even compile?
But if you dont' care it's fine - and there are great reasons not to care. Being in a situation where you don't have to care is awesome, use them. Eg setup code that can be slow before you get the the stuff that has to be fast.
I have never seen an exception safe C++ codebase, I don't believe such a beast exists. Even if it does it's a properly hard problem that you can't keep in check with multiple committers. Just see how much time Herb Sutter and Alexandrescou (who has now dumped c++ as needing to become a legacy language) put into trying to explain how to do it. And failing to do so. The idea "exception safe" in c++ easy is only entertained by those who don't understand the problem. Scope guard is not a magic bullet. How does the silly contrived example of opening a file work with multiple threads? Look at his example, push_back of a pointer onto a vector. I've never seen anything other than
vec.push_back(ptr); //get on with life
in the wild. But hey, maybe I'm missed some and it's only 99% of c++ code that is by the Alexandrecou definition "exception unsafe" Maybe 99% of c++ programmers aren't smart enough to program in the language?
If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way. Haskell might, python, ruby, scheme might.
The whole point of C and C++ is being able to get that really low level performance.
Yes totally, I DO recommend "monkeying with text generation" because you won't do it unless you actually need to. Templates have the opposite characteristic, sadly.
(And just quietly, to hell with the bozo who voted me down to 0 for participating in this discussion, you're not very bright, responding as maxlybbert did is the correct thing to do if you disagree, disagreement is what this whole thing is all about otherwise why bother?)
> You probably don't understand std::list and std::deque forget std::rope std::map std::unorderd_map, std::set etc. etc.
These were our general interview questions at the last place I worked (until we moved almost completely to Javascript development). Understanding big O performance characteristics is a very important skill, I don't consider it optional; at least in the world of C++ development. We asked about them because they use different, well-known, algorithms to get various results and we wanted to know if people had the skill to figure out appropriate trade offs when solving a problem.
Minor quibble: unless something has changed, rope ( https://www.sgi.com/tech/stl/Rope.html ) isn't in the Standard ( http://en.cppreference.com/w/cpp/container ).
> I know what they do, I know how they're probably implemented. I know their big O characteristics etc.
Then iterator invalidity should be easy to figure out for each of the containers. You don't even need a table.
> But they're optimised for high level generality not for the thing I'm doing on the hardware I'm targeting.
They're designed to be as efficient as they can be while also being general, yes.
> I don't know how they perform on particular hardware, how cache sizes affect them etc etc etc.
That's hardly a surprise, and that knowledge will go stale pretty quickly. Which is why Stroustrup says everybody gets it wrong. Many programmers have no idea how badly cache hostility will hurt them.
> You have to find that out for yourself, hopefully by benchmarking before you use them, rather than finding out they suck very, very hard in production.
I don't see how it could be different. Again, hardware architecture changes over time.
> Note that the benchmark he shows is not available, and it's not available in the STL.
I think you're looking for something like http://www.stepanovpapers.com/container_benchmark.cpp . I can imagine a compiler vendor or library vendor shipping something like this, but I wouldn't expect it to be in the STL.
https://github.com/rjernst/stepanov-components-course/tree/m... is also useful.
> Seriously. WTF is up with that?
I believe the first programming textbook I read mentioned the use of a profiler. If you're trying to improve performance, it's probably better to start with a profiler than with benchmarks. Then again, Douglas Crockford mentions how silly it is for programmers to make every choice based on performance instead of things like maintainability. Only worry about performance if you know it actually matters (and a profiler can help you decide if it matters).
> I have never seen an exception safe C++ codebase, I don't believe such a beast exists.
We may be talking about different things. I've worked on moderate sized code bases that wouldn't leak memory or leave files open, etc. if exceptions were thrown (and used ScopeGuard to do that), but our error handling code was as simple as possible. We had a large loop processing requests, and we'd throw out the request if there was any exception. We followed what Anders Hejlsberg describes as the expected C# pattern ( http://www.artima.com/intv/handcuffs.html ): "Surely in any kind of event-driven application like any kind of modern UI, you typically put an exception handler around your main message pump, and you just handle exceptions as they fall out that way. But you make sure you protect yourself all the way out by deallocating any resources you've grabbed, and so forth. You clean up after yourself, so you're always in a consistent state. You don't want a program where in 100 different places you handle exceptions and pop up error dialogs. What if you want to change the way you put up that dialog box? That's just terrible. The exception handling should be centralized, and you should just protect yourself as the exceptions propagate out to the handler."
But using C++ meant we didn't have to try to get the try ... finally's right ( http://mail.openjdk.java.net/pipermail/coin-dev/2009-Februar... , for the record, they accepted the proposal).
> How does the silly contrived example of opening a file work with multiple threads?
There isn't enough detail to answer this question. Are the threads going to share a single std::fstream? Or do they each get their own? Do we have access to some kind of file locking mechanism?
Clearly there are solutions to the problem. I have databases running on my system that were written in C and C++ and they manage to manipulate files from multiple threads.
> Look at his example, push_back of a pointer onto a vector.
Is the vector responsible for cleaning up the pointer? Will the pointer outlive the vector? Can you use shared_ptr? There are three, simple, answers to the question (std::vector<T*> if the pointer will outlive the vector and something else promises to clean up; std::vector<std::unique_ptr<T>> if the vector takes over responsibility to clean up; and std::vector<shared_ptr<T>> if the responsibility has to be shared). You don't need ScopeGuard for any of those cases. vec.push_back(ptr) will do the right thing for raw pointers (if cleanup is guaranteed elsewhere) and shared_ptrs (i.e., if "ptr" is a shared_ptr<T>), while vec.push_back(std::move(ptr)) will do the right thing for a std::vector<std::unique_ptr>> (if "ptr" is a unique_ptr<T>). In fact, vec.push_back(std::unique_ptr<T>(new T(...))) will also do the right thing for a std::vector<std::unique_ptr<T>>.
> maybe I'm missed some and it's only 99% of c++ code that is by the Alexandrecou definition "exception unsafe"
Not all code has to be exception safe (e.g., if the policy is to abort an any exception, or if memory leaks are deemed acceptable). And Google, somewhat famously bans them ( http://google-styleguide.googlecode.com/svn/trunk/cppguide.h... ). But the numbers are better than you believe. Mozilla seems to do a decent job with exception safety. The biggest source of exception unsafe code appears to be programmers who believe everything must be allocated with new in all cases.
> If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way.
That is a surprising statement, especially since you don't necessarily have any idea what my needs are. There are times that I choose to write code in C# or Perl (never Java, but that's my personal preference), so I don't use C or C++ if it doesn't make sense. But there are times that I choose C++ for reasons other than performance. It can actually be a good fit for what I'm doing (e.g., I don't like using neutered generics when I really need templates, and I don't like putting things into classes if there's no need to ( https://news.ycombinator.com/item?id=3717715 )). Or (more often) I know a C++ library that's a great fit and that doesn't exist in C# or Perl.
These were our general interview questions at the last place I worked (until we moved almost completely to Javascript development). Understanding big O performance characteristics is a very important skill, I don't consider it optional; at least in the world of C++ development. We asked about them because they use different, well-known, algorithms to get various results and we wanted to know if people had the skill to figure out appropriate trade offs when solving a problem.
Minor quibble: unless something has changed, rope ( https://www.sgi.com/tech/stl/Rope.html ) isn't in the Standard ( http://en.cppreference.com/w/cpp/container ).
> I know what they do, I know how they're probably implemented. I know their big O characteristics etc.
Then iterator invalidity should be easy to figure out for each of the containers. You don't even need a table.
> But they're optimised for high level generality not for the thing I'm doing on the hardware I'm targeting.
They're designed to be as efficient as they can be while also being general, yes.
> I don't know how they perform on particular hardware, how cache sizes affect them etc etc etc.
That's hardly a surprise, and that knowledge will go stale pretty quickly. Which is why Stroustrup says everybody gets it wrong. Many programmers have no idea how badly cache hostility will hurt them.
> You have to find that out for yourself, hopefully by benchmarking before you use them, rather than finding out they suck very, very hard in production.
I don't see how it could be different. Again, hardware architecture changes over time.
> Note that the benchmark he shows is not available, and it's not available in the STL.
I think you're looking for something like http://www.stepanovpapers.com/container_benchmark.cpp . I can imagine a compiler vendor or library vendor shipping something like this, but I wouldn't expect it to be in the STL.
https://github.com/rjernst/stepanov-components-course/tree/m... is also useful.
> Seriously. WTF is up with that?
I believe the first programming textbook I read mentioned the use of a profiler. If you're trying to improve performance, it's probably better to start with a profiler than with benchmarks. Then again, Douglas Crockford mentions how silly it is for programmers to make every choice based on performance instead of things like maintainability. Only worry about performance if you know it actually matters (and a profiler can help you decide if it matters).
> I have never seen an exception safe C++ codebase, I don't believe such a beast exists.
We may be talking about different things. I've worked on moderate sized code bases that wouldn't leak memory or leave files open, etc. if exceptions were thrown (and used ScopeGuard to do that), but our error handling code was as simple as possible. We had a large loop processing requests, and we'd throw out the request if there was any exception. We followed what Anders Hejlsberg describes as the expected C# pattern ( http://www.artima.com/intv/handcuffs.html ): "Surely in any kind of event-driven application like any kind of modern UI, you typically put an exception handler around your main message pump, and you just handle exceptions as they fall out that way. But you make sure you protect yourself all the way out by deallocating any resources you've grabbed, and so forth. You clean up after yourself, so you're always in a consistent state. You don't want a program where in 100 different places you handle exceptions and pop up error dialogs. What if you want to change the way you put up that dialog box? That's just terrible. The exception handling should be centralized, and you should just protect yourself as the exceptions propagate out to the handler."
But using C++ meant we didn't have to try to get the try ... finally's right ( http://mail.openjdk.java.net/pipermail/coin-dev/2009-Februar... , for the record, they accepted the proposal).
> How does the silly contrived example of opening a file work with multiple threads?
There isn't enough detail to answer this question. Are the threads going to share a single std::fstream? Or do they each get their own? Do we have access to some kind of file locking mechanism?
Clearly there are solutions to the problem. I have databases running on my system that were written in C and C++ and they manage to manipulate files from multiple threads.
> Look at his example, push_back of a pointer onto a vector.
Is the vector responsible for cleaning up the pointer? Will the pointer outlive the vector? Can you use shared_ptr? There are three, simple, answers to the question (std::vector<T*> if the pointer will outlive the vector and something else promises to clean up; std::vector<std::unique_ptr<T>> if the vector takes over responsibility to clean up; and std::vector<shared_ptr<T>> if the responsibility has to be shared). You don't need ScopeGuard for any of those cases. vec.push_back(ptr) will do the right thing for raw pointers (if cleanup is guaranteed elsewhere) and shared_ptrs (i.e., if "ptr" is a shared_ptr<T>), while vec.push_back(std::move(ptr)) will do the right thing for a std::vector<std::unique_ptr>> (if "ptr" is a unique_ptr<T>). In fact, vec.push_back(std::unique_ptr<T>(new T(...))) will also do the right thing for a std::vector<std::unique_ptr<T>>.
> maybe I'm missed some and it's only 99% of c++ code that is by the Alexandrecou definition "exception unsafe"
Not all code has to be exception safe (e.g., if the policy is to abort an any exception, or if memory leaks are deemed acceptable). And Google, somewhat famously bans them ( http://google-styleguide.googlecode.com/svn/trunk/cppguide.h... ). But the numbers are better than you believe. Mozilla seems to do a decent job with exception safety. The biggest source of exception unsafe code appears to be programmers who believe everything must be allocated with new in all cases.
> If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way.
That is a surprising statement, especially since you don't necessarily have any idea what my needs are. There are times that I choose to write code in C# or Perl (never Java, but that's my personal preference), so I don't use C or C++ if it doesn't make sense. But there are times that I choose C++ for reasons other than performance. It can actually be a good fit for what I'm doing (e.g., I don't like using neutered generics when I really need templates, and I don't like putting things into classes if there's no need to ( https://news.ycombinator.com/item?id=3717715 )). Or (more often) I know a C++ library that's a great fit and that doesn't exist in C# or Perl.
>> If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way.
>That is a surprising statement, especially since you don't necessarily have any idea what my needs are.
Look we've probably exhausted this discussion and are talking past eachother, but I do want to point out that this is a simple misunderstanding.
I meant "you" in the sense of the archaic english "one" "If one uses C or C++ and one does not care about performance one has performed a premature optimisation." It sounds terribly old-fashioned expressed like this but I guess the meaning is clearer given the way "you" is overloaded to mean you singular (you yourself), you plural (you and your admirers) and you in the sense of 2. here: http://dictionary.reference.com/browse/you "one; anyone; people in general"
I obviously have no knowledge or opinion about choices made specifically by yourself, and we are in total agreement that holding an opinion on such would be ridiculous in the extreme.
You might find this interesting, it highlights the problem I'm talking about with exceptions by a guy who has done it in c++ with amazing success, likes the language and appreciates its defects as well as its strengths: http://250bpm.com/blog:4
Where you are writing those pieces of code in your program that caused you to rationally choose C or C++ as your language (ie has to perform & caching is important), the STL is a bad option because it wasn't designed for your use, it was designed for everybody's use and you pay for everybody else's use and their architecture choices and so on none of which you are using! So uou pay when you don't use! This is kind of supposed to be what doesn't happen in low level languages. Good C++ code in such a case bears more than a passing resemblance to C and the fact that this is possible is one of the greatest strengths of C++.
If you're writing pieces of code that were largely irrelevant in your choice of C++ as a language and if that was the only code you were writing in this project you could have happily chosen a higer level language, the STL is just dandy, use it, write your code fast and forget about its performance as totally uninteresting to your problem.
More interesting is where you're not sure, "a deque could be good enough here and will save me time to write." How do you know if it's good enough. Big O don't help you. You should be able to run a canned benchmark you understand on the hardware you're targeting so you have an idea of "good enough" or "won't cut it, need to implement a ring buffer" or whatever. Instead you have to write that yourself or just ouija board. So we duplicate masses of effort from conscientious c++ hackers and simultaneously encourage ouija board decisions. C++ could and should do better. Stepanov's container benchmarks? Is a sorted vector with unique run on it better than a set, ok. Very limited in its general usefulness, for what are supposed to be general solutions. But yeah, about 200 more tests like it for different access patterns, insertion patterns, payload sizes and so on is what is required.
Here is Mike Acton (knowingly) wildly overstating the case for audience effect at cppcon last year. On the standards of these lectures this one is an absolute tour de force. Definitely worth your and any C++ hacker's time. Look up Alexandrescou's lecture on optimisation at the same conference as a benchmark to see just how good it is. https://www.youtube.com/watch?v=rX0ItVEVjHc
>That is a surprising statement, especially since you don't necessarily have any idea what my needs are.
Look we've probably exhausted this discussion and are talking past eachother, but I do want to point out that this is a simple misunderstanding.
I meant "you" in the sense of the archaic english "one" "If one uses C or C++ and one does not care about performance one has performed a premature optimisation." It sounds terribly old-fashioned expressed like this but I guess the meaning is clearer given the way "you" is overloaded to mean you singular (you yourself), you plural (you and your admirers) and you in the sense of 2. here: http://dictionary.reference.com/browse/you "one; anyone; people in general"
I obviously have no knowledge or opinion about choices made specifically by yourself, and we are in total agreement that holding an opinion on such would be ridiculous in the extreme.
You might find this interesting, it highlights the problem I'm talking about with exceptions by a guy who has done it in c++ with amazing success, likes the language and appreciates its defects as well as its strengths: http://250bpm.com/blog:4
Where you are writing those pieces of code in your program that caused you to rationally choose C or C++ as your language (ie has to perform & caching is important), the STL is a bad option because it wasn't designed for your use, it was designed for everybody's use and you pay for everybody else's use and their architecture choices and so on none of which you are using! So uou pay when you don't use! This is kind of supposed to be what doesn't happen in low level languages. Good C++ code in such a case bears more than a passing resemblance to C and the fact that this is possible is one of the greatest strengths of C++.
If you're writing pieces of code that were largely irrelevant in your choice of C++ as a language and if that was the only code you were writing in this project you could have happily chosen a higer level language, the STL is just dandy, use it, write your code fast and forget about its performance as totally uninteresting to your problem.
More interesting is where you're not sure, "a deque could be good enough here and will save me time to write." How do you know if it's good enough. Big O don't help you. You should be able to run a canned benchmark you understand on the hardware you're targeting so you have an idea of "good enough" or "won't cut it, need to implement a ring buffer" or whatever. Instead you have to write that yourself or just ouija board. So we duplicate masses of effort from conscientious c++ hackers and simultaneously encourage ouija board decisions. C++ could and should do better. Stepanov's container benchmarks? Is a sorted vector with unique run on it better than a set, ok. Very limited in its general usefulness, for what are supposed to be general solutions. But yeah, about 200 more tests like it for different access patterns, insertion patterns, payload sizes and so on is what is required.
Here is Mike Acton (knowingly) wildly overstating the case for audience effect at cppcon last year. On the standards of these lectures this one is an absolute tour de force. Definitely worth your and any C++ hacker's time. Look up Alexandrescou's lecture on optimisation at the same conference as a benchmark to see just how good it is. https://www.youtube.com/watch?v=rX0ItVEVjHc
>>> If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way.
>> That is a surprising statement, especially since you don't necessarily have any idea what my needs are.
> Look we've probably exhausted this discussion and are talking past each other,
I agree, it's petered out.
> but I do want to point out that this is a simple misunderstanding.
> I meant "you" in the sense of the archaic english "one" "If one uses C or C++ and one does not care about performance one has performed a premature optimisation."
I prefer "you" over "one." And, for the record, I didn't take it as an insult. But I find it odd to believe that the only reason anybody would use C++ is for performance. That there couldn't possibly be another use case (or if there were, it would be incredibly rare). I guess the only reason somebody would pick Python would be a strange obsession with whitespace? And Java's only for people who like checked exceptions?
>> That is a surprising statement, especially since you don't necessarily have any idea what my needs are.
> Look we've probably exhausted this discussion and are talking past each other,
I agree, it's petered out.
> but I do want to point out that this is a simple misunderstanding.
> I meant "you" in the sense of the archaic english "one" "If one uses C or C++ and one does not care about performance one has performed a premature optimisation."
I prefer "you" over "one." And, for the record, I didn't take it as an insult. But I find it odd to believe that the only reason anybody would use C++ is for performance. That there couldn't possibly be another use case (or if there were, it would be incredibly rare). I guess the only reason somebody would pick Python would be a strange obsession with whitespace? And Java's only for people who like checked exceptions?
I had looked at using ZeroMQ for a project. Based on the deep misunderstanding from that blog post, I'm glad we didn't.
First, undefined behavior has an actual meaning in C++, and it's not "nondeterminism" ( http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-... ).
Second, if you're going to publish a library, it's certainly important to have an error handling policy. But I find it very strange to assume that your clients will screw up error handling and blame you for it. The blog post doesn't say this explicitly, but I think it's the source of the "no exceptions, ever" policy ("no exceptions, because the clients will screw it up").
Third, you shouldn't throw exceptions for every error. You throw exceptions when something went wrong and you don't think your immediate caller can do anything intelligent about it. If the immediate caller can do something, you return an error code.
Fourth, did you know that printf() can fail? What should you do if it does? You can't print a warning to the user. Did you know that closing a file can fail? What should you do? Close it again? If a destructor is unable to clean something up, it's basically impossible to do anything about it. You might log the error, but I don't see what you'd do about it.
First, undefined behavior has an actual meaning in C++, and it's not "nondeterminism" ( http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-... ).
Second, if you're going to publish a library, it's certainly important to have an error handling policy. But I find it very strange to assume that your clients will screw up error handling and blame you for it. The blog post doesn't say this explicitly, but I think it's the source of the "no exceptions, ever" policy ("no exceptions, because the clients will screw it up").
Third, you shouldn't throw exceptions for every error. You throw exceptions when something went wrong and you don't think your immediate caller can do anything intelligent about it. If the immediate caller can do something, you return an error code.
Fourth, did you know that printf() can fail? What should you do if it does? You can't print a warning to the user. Did you know that closing a file can fail? What should you do? Close it again? If a destructor is unable to clean something up, it's basically impossible to do anything about it. You might log the error, but I don't see what you'd do about it.
> std::vector implements one of the simplest data structures in computer science.
It may "implement" one of the simplest DS, but this particular implementation is anything but trivial to use. You can get a pointer to an element in it, and keep using the vector, and the pointer will point to the correct element... until you push_back() one too many element, it resizes, and then suddenly your pointer is invalid.
But if you reserve() the right amount of space, you can keep it valid! If you are very careful. But then you don't want to call reserve() too often because it may actually turn your O(N) algorithm into O(N^2)! (Basically, calling reserve() N times on O(N) length vector takes O(N^2) time, while doing push_back() N times is guaranteed to be O(N).)
Sure, std::vector is useful, and I use it all the time, but it is anything but simple. It's C++ after all. :)
It may "implement" one of the simplest DS, but this particular implementation is anything but trivial to use. You can get a pointer to an element in it, and keep using the vector, and the pointer will point to the correct element... until you push_back() one too many element, it resizes, and then suddenly your pointer is invalid.
But if you reserve() the right amount of space, you can keep it valid! If you are very careful. But then you don't want to call reserve() too often because it may actually turn your O(N) algorithm into O(N^2)! (Basically, calling reserve() N times on O(N) length vector takes O(N^2) time, while doing push_back() N times is guaranteed to be O(N).)
Sure, std::vector is useful, and I use it all the time, but it is anything but simple. It's C++ after all. :)
You have the similar problems if you build your own resizeable arrays in C, unless you resort to an extra level of indirection (e.g. an array of pointers, or pointers to array chunks).
std::vector has a series of gotchas, but any generic resizeable array which has similar performance will have similar gotchas; std::vector wasn't made that way just for giggles.
std::vector has a series of gotchas, but any generic resizeable array which has similar performance will have similar gotchas; std::vector wasn't made that way just for giggles.
dmpk2k is right: the requirements on iterator validity are the obvious consequences of using a reallocatable array. Replace a std::vector with malloc-ed memory and call realloc every so often, and you'll find your pointers to elements in the array don't stay valid. It's not a gratuitous problem; you'd run into it no matter how you implement your grow able array.
Interestingly, keeping track of indexes into the array avoids the issue completely.
Interestingly, keeping track of indexes into the array avoids the issue completely.
boost::stable_vector[0] isn't a bad middle ground between a linked list and a vector if you just want iterator stability and better exception safety (for types that throw when moved or copied)
[0] http://www.boost.org/doc/libs/1_57_0/doc/html/boost/containe...
[0] http://www.boost.org/doc/libs/1_57_0/doc/html/boost/containe...
Alright, to be fair I haven't coded in C++ for ~10 years so maybe I might just be a little smidgeon behind the times =)
I use C++ for fun. Mostly because it's actually quite nice if you know what parts of the language to use.
C++ could really use a "C++: The Good Parts" book.
C++ could really use a "C++: The Good Parts" book.
It's got one! "The C Programming Language" by Kernighan and Richie ;-)
What it could really use some deprecation of the more idiotic, dangerous, useless features (eg explicit constructors should be the default, unbraced single line blocks only introduce bugs and have no positive value at all). They should also mandate that standards conforming STL implementations ship with a standard set of benchmarks you can run on the hardware you're targeting. All the C++ "anointed smart people" complain people use the wrong STL datastructures but don't show any cleverness at all in solving that problem.
No 2 C++ hackers agree on what constitutes "The Good Parts" witness every single C++ style guide ever endorsing a different subset of the language. C++11/14 has not changed this. Modulo different targets make that subset different from the point of view of the very same hacker.
What it could really use some deprecation of the more idiotic, dangerous, useless features (eg explicit constructors should be the default, unbraced single line blocks only introduce bugs and have no positive value at all). They should also mandate that standards conforming STL implementations ship with a standard set of benchmarks you can run on the hardware you're targeting. All the C++ "anointed smart people" complain people use the wrong STL datastructures but don't show any cleverness at all in solving that problem.
No 2 C++ hackers agree on what constitutes "The Good Parts" witness every single C++ style guide ever endorsing a different subset of the language. C++11/14 has not changed this. Modulo different targets make that subset different from the point of view of the very same hacker.
If anything, C is "C++ the Bad Parts. How to compromise language design to achieve adoption".
In fairness I think C++ has had a lot more compromise in its "design" than C did. C has a bunch of issues but it's understandable. C++, nobody understands it all, and it changes so much from compiler to compiler, accross hardware platforms and so on.
Pure virtual base protected friend member functions aren't in C.
Pure virtual base protected friend member functions aren't in C.
C also changes a lot between compilers,specially thanks to undefined behavior and vendor extensions. A feature C++ inherited from C.
Even between versions of the same compiler. Quite bad in the embedded space.
Lack of bounds checking for native arrays, null terminated strings, arrays that decay into pointers, include files instead of proper modules, implicit conversions are among the inherited features.
>Pure virtual base protected friend member functions aren't in C.
No they are not, but as someone that knows C++ since 1993, I fail to see the problem.
Pure virtual base => requires redefinition in derived classes
Protected => only accessible in derived classes
Friend => can be used by protected member functions of friend classes
Not needed in every day C++ code, but enterprise architects love this type of flexibility, which doesn't have anything to do with safety.
Even between versions of the same compiler. Quite bad in the embedded space.
Lack of bounds checking for native arrays, null terminated strings, arrays that decay into pointers, include files instead of proper modules, implicit conversions are among the inherited features.
>Pure virtual base protected friend member functions aren't in C.
No they are not, but as someone that knows C++ since 1993, I fail to see the problem.
Pure virtual base => requires redefinition in derived classes
Protected => only accessible in derived classes
Friend => can be used by protected member functions of friend classes
Not needed in every day C++ code, but enterprise architects love this type of flexibility, which doesn't have anything to do with safety.
Just get the "Tour of C++" from Bjarne. It exactly that.
http://www.amazon.com/Tour-In-Depth-Series-Bjarne-Stroustrup...
http://www.amazon.com/Tour-In-Depth-Series-Bjarne-Stroustrup...
I do.
When faced with the sad fact that Turbo Pascal was PC only I had to choose another language.
The year was 1993 and C already looked dated when compared with what Turbo Pascal was capable of. Also when compared against Modula-2, which was on the way out as well.
So I went C++, which even with C++ ARM compatibility issues, was way safer than C.
Nowadays there are plenty of compiled languages to choose from, but between C++ and C I only pick C if obliged to do so.
When faced with the sad fact that Turbo Pascal was PC only I had to choose another language.
The year was 1993 and C already looked dated when compared with what Turbo Pascal was capable of. Also when compared against Modula-2, which was on the way out as well.
So I went C++, which even with C++ ARM compatibility issues, was way safer than C.
Nowadays there are plenty of compiled languages to choose from, but between C++ and C I only pick C if obliged to do so.
Odd... I feel the same way about Python.
Not fond of significant white space?
Honestly, no.
I get the premise, but at least with braces there's no ambiguity at all about where a statement begins and ends. It's certainly not going to be the case that one tab too many or a space instead of a tab wrecks everything. Explicit is supposed to be better than implicit, right? I can't think of anything more implicit than using whitespace as syntax.
My personal bias is that whitespace is meant to make code human readable. It shouldn't matter to the interpreter, or at least, it shouldn't be critical to the degree that it seems to be for Python.
Of course I say this knowing perfectly well that Pythonists look at C code with its braces and think it's redundant and noisy.
I get the premise, but at least with braces there's no ambiguity at all about where a statement begins and ends. It's certainly not going to be the case that one tab too many or a space instead of a tab wrecks everything. Explicit is supposed to be better than implicit, right? I can't think of anything more implicit than using whitespace as syntax.
My personal bias is that whitespace is meant to make code human readable. It shouldn't matter to the interpreter, or at least, it shouldn't be critical to the degree that it seems to be for Python.
Of course I say this knowing perfectly well that Pythonists look at C code with its braces and think it's redundant and noisy.
Just so you can laugh at me. Hahaha. That's the one thing I really do like about python. It means any difference in the shape of python code tells you something other than a personal preference of a coder I shouldn't have to know or care about. The consistency of the signal you get from the shape of the code makes this signal useful across codebases. That signal has a lot more noise in it in C & Perl for example. Anyone who talks about automatic indent compensating for it has never worked with jerks using different styles or hasn't had to hack a 3rd party library source to find a bug. No really. Make clang tools will be better but that's a long bow to assume yet.
I have never once ever under any circumstances had a goddamn meeting where people argued about python bracing rules for code consistency. That alone makes it a truly epic ultra-megawin, for mine. (*but they absolutely should have standardised on ONE of tabs or spaces and I hate not being able to bounce on the braces to see where that awful code's scope actually starts and who wrote this anyway sweary curse I'm a teapot...).
I have never once ever under any circumstances had a goddamn meeting where people argued about python bracing rules for code consistency. That alone makes it a truly epic ultra-megawin, for mine. (*but they absolutely should have standardised on ONE of tabs or spaces and I hate not being able to bounce on the braces to see where that awful code's scope actually starts and who wrote this anyway sweary curse I'm a teapot...).
The whole "OMG it's full of whitespace" thing kept me off Python for years, in part because I'd done a lot of work in text processing in the '90's and realized, "Whitespace is not actually evil... it is just misunderstood" was a fair encapsulation of the problem of whitespace parsing, where "equivalant" and "ignorable" whitespace were perennial problems.
Once I got over that, Python turns out to be pretty awesome, and while I still use C++ for performance-critical things and C for firmware, the clarity and simplicity of Python is unmatched by any of the other dozen-odd languages I've written in.
I agree syntactic whitespace comes with an overhead, but it's more than worth it for the other benefits you get with Python, particularly the ease of using every other library and language on the planet, from lapack to R.
Once I got over that, Python turns out to be pretty awesome, and while I still use C++ for performance-critical things and C for firmware, the clarity and simplicity of Python is unmatched by any of the other dozen-odd languages I've written in.
I agree syntactic whitespace comes with an overhead, but it's more than worth it for the other benefits you get with Python, particularly the ease of using every other library and language on the planet, from lapack to R.
If you ever screw up the whitespace, it's possible that the mistake won't show up in common diffing software, because most diffing software is designed with the assumption that whitespace is insignificant (and hard to display).
Ironically, as soon as you need a tool to make whitespace visible in order to determine which delimiter you're using where, you're just using C-style braces again, only now there are two kinds of braces, which are incompatible, and otherwise visually indistinguishable.
So they should just have made tabs compulsory. Problem solved.
I really don't like the idea of using fixed length of whitespace for delimiting scope instead of using explicit markers. It's not really a language issue, just syntax preference.
It always reminds me of the old Punchcard Fortran fixed column layout
" Columns 1 to 5 were the label field: a sequence of digits here was taken as a label for the purpose of a GOTO or a FORMAT reference in a WRITE or READ statement. Column 6 was a continuation field: a non-blank character here caused the card to be taken as a continuation of the statement on the previous card. Columns 7 to 72 served as the statement field"
" Columns 1 to 5 were the label field: a sequence of digits here was taken as a label for the purpose of a GOTO or a FORMAT reference in a WRITE or READ statement. Column 6 was a continuation field: a non-blank character here caused the card to be taken as a continuation of the statement on the previous card. Columns 7 to 72 served as the statement field"
Nonsense. C++ is fun!
The Zend Engine 3 (aka the stock PHP 7 interpreter) is, according to one HHVM developer, 'embarassingly competitive on the test suites', and it's written in C.
/rant
C++ is probably much nicer to maintain, though. C ends up being macro hell.