Why on earth are they using C++ for a web browser anyway? That's about the worst possible choice of programming language for that problem domain.
If you want to see an attempt to write a new browser engine in a language that is memory-safe by default, I suggest you check out Mozilla's Servo engine: https://github.com/servo/servo
EDIT: Chrome, Firefox, Safari, IE, Opera
Depends on what you count. Qt can be seen as (part of the) Linux userspace. KDE applications are usually written in C++ (partially in QML+JavaScript), Gtk applications are written in C or Vala (a few in C#). If you don't count DE frameworks basically the only thing left would be libc, which of course is C (but available in some form under every noteworthy OS).
[1] http://git.annexia.org/?p=virt-bmap.git;a=tree
[2] https://stackoverflow.com/questions/27152834/how-to-improve-...
I have a slight preference for the way clang chooses to highlight the entire AST parent node that it thinks is responsible for the error, but the approach g++ takes is perfectly clear.
If you can't get something to be performant with C++, it's pretty unlikely you'll get it to be performant with most other languages.
(Unless you want to try it in fortran)
Try comparing qsort to stl::sort...
Hint: stl::sort is a lot faster. It can inline the comparison function. Ok, it just shows how slow function pointers are. I'm assuming compilers still can't optimize the function pointer away in qsort.
Of course a specialized sorter in C would be faster, one that can inline comparison function. C++ copy pasting automation... err, I mean templates are useful, because it can often inline your function and data type in the algorithm without using function pointers. At cost of generating same or similar algorithm code multiple times bloating the binary.
I wouldn't be surprised if std::unordered_set would yield further speedup. (It doesn't look like you need the order criterion). Other things worth trying are:
* Not using a set at all - it seems most sets only have 3-4 elements. You might as well use a vector. * It doesn't look like your intervals overlap, and it looks like they're already ordered. interval_map may be unnecessary, and it might be worth keeping the data in a simple vector. * You don't want to copy object_set, either. A const-ref is more than enough * And finally, if you want to veer into nit-pick territory, you want to use range-based loops. It might or might not yield better compiled code. It's definitely much more readable.
for (const auto& iter : map->equal_range(window))
for (const auto& obj: iter->second)
f(iter->first->start, iter->first->end, obj.c_str(), opaque);
Let's put it that way: The browser people don't write C++ because they think it's such an awesome language :)
C/C++ is also a poor match to today's CPUs. It's very slow compared to what the hardware is capable of. Compare for example with Intel ispc (https://ispc.github.io/). It gives some idea how much performance we're currently missing.
When C was young, memory latency was typically 1 or 2 clock cycles. There was no pipelining, at most a simple state machine that would finish in a few clock cycles. A branch didn't cost much. A few cycles at most. Neither did a pointer reference. Random access was almost as fast as sequential access.
Today's CPUs have memory latency of 150-300 clock cycles. A modern CPU core can typically retire 1-4 instructions per clock cycle. A single instruction takes typically about 16 clock cycles from decoding until retire. So CPUs have to often execute blind and just guess where the execution flow will go. Branches modify this flow. CPUs simply guess the flow, branch predict. When they're wrong, they just have to invalidate currently executing instructions and start again. Branches are something to avoid. Especially unpredictable ones. Function pointers are branches. Even though they can be predicted, they often just fall out of the branch predictor cache.
We need something that can minimize the costs modern CPUs are bad at. C/C++ is very branchy and uses slow function pointers often (vtable, switch jump tables, etc).
The problem is, there's more variation among CPUs than ever before, even within same instruction set architecture. For x86, not only the costs for instructions are wildly different, but the instruction set support is fragmented.
C/C++ is not the last word. Unsafe and way too slow compared to what current hardware is capable of. The problem is, the language that is safer and a good match just does not exist yet. Some safety can be sacrificed for greater speed, but it should be situational choice by the programmer, not the only way or even default.
C/C++ is what I do at my day job.
High level languages just make it easier for crappy programmers to approximate a working solution.
In 20 years, I don't think I've ever seen a commercial third-party C++ library that I thought was competently designed and implemented. I was about to offer the exception of mysql++, but then I remembered it's an open-source library so it wouldn't count as commercial. C++ seems to breed a lot of crappy but marginally useful code.
I haven't done much Java, and I don't think it's a bad language, I've never seen a Java development environment that I would even wish on my enemies. Java seems to breed bloated over-engineered but under-flexible designs that require the programmer to do way too much of the kind of stuff that we invented computers to do for us in the first place.
When the half dozen browsers that represent about 99.9% of the browswer market all use C++, perhaps the explanation is not "They're all wrong."
I didn't say they're wrong by any means! C++ is the horse and cart. Performance wise, the programming language automobile doesn't exist yet. Of course one should and must use what is currently available!
The best language for writing a web browser does not exist yet. Or for writing other similarly complicated applications with performance requirements.
So, yes, C++ is probably the best language for writing a web browser right now. The cleanest dirty shirt. Certainly not the safest, but out of high level languages it has the best performance. It has large enough work force, important if you're building a large project. C/C++ interfaces with current operating systems natively. And a lot of other considerations make it a sensible choice.
But C/C++ is rather far from what a language could be. It's very bug prone. Overcomplicated. Hard to maintain.
And it is slow. Not compared to other languages, but to CPU performance potential. I can write very fast software in C++ -- if I effectively fall back to assembler or at least compiler intrinsics. In other words, by being a human compiler.
The widespread of UNIX into the industry, killed the other languages because they weren't the UNIX system programming language and other system vendors weren't able to fight against UNIX based Workstations.
So like JavaScript in the browser, C eventually killed the alternatives in the workstation market.
C++ was able to gain industry acceptance because C++ compiler vendors were actually C compiler vendors bundling C++ in their products, since C++ came from AT&T as well.
Additionally, the computers started to be fast enough for mainstream VM based systems.
The business application developers moved along to VM based languages, while the system programmers focused on the languages that were supported by larger OS vendors, C and C++.
All the compiler vendors selling system programming languages compilers that didn't enjoy first class treatment on a mainstream OS, either closed down or changed business.
So 20 years later, C and C++ became the only alternatives for systems programming, unless one wants to play with dead languages.
With Ada being used in projects that required it, or for software scenarios where human life are at risk like aviation, train control systems, medical devices and so on.
And now we are getting beaten every day in security exploits due to daggling pointers and out of bounds errors.
No, disassembly listing is not what I typically use for debugging. Just one of the tools. The point is, something is wrong when disassembly can be easier to understand than source code!
So depressing when you need to deal with it often. Our best tool is not very good.
Well, all this puts bread on my table, so I guess I shouldn't complain too much...
Overloading operators is a great feature, but should be used as sparingly as possible, and only where it makes intuitive sense.
Templates offer even more rope to hang yourself, and even though I'm a late convert to using templates, I would never suggest the feature goes too far. It's kludge fuel, no doubt, but the language needs the feature, and it allows you to do things that are truly useful and elegant.
It never occurred to me that viewing the disassembly could be useful for debugging, and I would imagine it's not normally useful unless you are really doing some pretty sophisticated stuff with the language. It would be extremely educational to understand what the compiler actually does however, but if inspecting the disassembly is instructive on how best to use the language, then I would suspect the language design, or at least the compiler, is doing something wrong.
I do think C++ requires a little too much consideration of how certain operations are implemented, e.g., this very discussion, but it's a price I'm willing to pay for a language that lets me do things any way I want to do them.
I program in Python in my spare time and for small scripting tasks, and can't imagine choosing C++ over Python for any personal project I've done in the past couple years (which tend to be small anyway), but I use C++ at work and am very happy to continue using it after 20 years on and off (mostly on).
I've found that RAII classes like std::unique_ptr have really helped. Errors like an uninitialized pointer are often caused by poor ownership semantics in the program design, and I don't think you escape that in reference counted languages. You'll still have a messy class design without clear ownership, and there are types of resources other than memory to manage (file handles, locks, sockets).
I'm not saying that your colleagues are bad engineers, I've had many troubles with ownership design over the years and still do at times. I just don't think C++ is unique in this regard even if it does force you to think about it more regularly since memory interaction is so common.