
A list of systems, applications, and libraries that are written in C++ - AndreyKarpov
http://www.stroustrup.com/applications.html
======
jacques_chester
The thorough seeding of the list with defunct examples (BeOS, Mac OS < X)
gives off a weird vibe.

There's also the standard halo effect listing. Any sufficiently large company
is using a language / methodology / philosophy / technology you've heard
about. And they're being namechecked on that language / methodology /
philosophy / technology's website.

The classic is Microsoft.

Did you know Microsoft uses Scrum? They do!

Did you know Microsoft uses ISO 9295-424:54 ( _Humungo Software Dev Standard
Written by the SEI, the DoD and a committee of 200 researchers from different
Fortune 50 companies_ )? They do!

(Hint: Microsoft doesn't have a single unified method of development, it's
largely up to each section to decide how they do the work)

~~~
cturner
BeOS is interesting partly because of how it limited use of C++. C++ was the
only supported API for userland, but the kernel was C.

Found a reference: "Creating a driver on BeOS is done using ANSI C; the C++
language requires certain support which is not available in the BeOS kernel
environment."
[http://testou.free.fr/www.beatjapan.org/mirror/www.be.com/ab...](http://testou.free.fr/www.beatjapan.org/mirror/www.be.com/aboutbe/benewsletter/volume_III/Issue7.html#Workshop)

I remember another newsletter article where one of the devs described
techniques for getting C++-like power while remaining within C (heavy use of
function pointers in structs, that kind of thing).

Another: [http://www.haiku-os.org/legacy-
docs/benewsletter/Issue4-51.h...](http://www.haiku-os.org/legacy-
docs/benewsletter/Issue4-51.html)

~~~
leakybucket
The BeOS userland api had base classes with reserved functions that were there
solely to reserve space in the objects vtable becase of the fragile base class
problem:

[http://en.wikipedia.org/wiki/Fragile_binary_interface_proble...](http://en.wikipedia.org/wiki/Fragile_binary_interface_problem)

I wonder how modern C++ frameworks are handling this?

------
matthavener
I'd be interested to see which subset of C++ each company picked. Google's
coding guidelines are always cited, but I can't find many others. MySQL's seem
lacking in details. C++ is such a broad spectrum, I bet some of these
companies only used simple classes and virtual functions, whereas some used
boost.spirit and functors.

[https://dev.mysql.com/doc/internals/en/general-
development-g...](https://dev.mysql.com/doc/internals/en/general-development-
guidelines.html#coding-guidelines-c)

~~~
fafner
I hope nobody uses boost.spirit. It's nearly impossible to debug, increases
compile time dramatically, and increases binary size dramatically as well.
It's a nice idea showing what can be done in C++ but it's really nothing you
should practically use. I think Boost is simply going overboard with stuff
like this.

Another interesting C++ coding guideline are the JSF coding guidelines.
Stroustrup was actually involved in creating them. It's mostly focused in
embedded and critical systems. But unlike what most people expect they highly
recommend stuff like Templates

<http://www.stroustrup.com/JSF-AV-rules.pdf>

~~~
phaedrus
Actually boost.spirit is an excellent library. The fact that it can both parse
and generate made it a great basis for the Io debugger I wrote that wraps gdb;
since gdb uses a text based interface I had to both parse and generate in
order to spoof gdb responses for Io script debugging. Spirit allows me to do
that quite ncely.

Like anything boost spirit has a leaning curve. You could just as easily say
no one should use emacs because it is hard to learn. In fact I personally
don't use emacs because I found it too hard to get going with, but I don't
from there extrapolate that no one else should use it.

The compile time and binary size problems of boost spirit can be addressed by
factoring your grammar into smaller subgrammars in separate compilation units.
The subgrammars can still be combined the same as rules can be.

The obscure error messages can be improved by using typeful programming so
that you get an error like "no conversion from MyRuleADatatype to
MyRuleBDatatype".

Yes these things are still problematic, but how do we get from "X is hard" to
"no one should use X"? See the Clojure author's talk on Simple vs Easy: he
lambasts programmer culture for being obsessed with 'easy' to the detriment of
creating useful stuff. He asks, what if the Foo Fighters said guitars are hard
to play, let's play kazoos because they are easy. Would you listen to the
Kazoo Fighters, he asks.

~~~
ryanmolden
For simple lexing/parsing it likely is overkill, that said for more complex
things it can be nice. I have a lexer for Erlang written with Boost.Spirit on
my Github. I found debugging no worse than the general Chutulu-horror that are
C++ template errors, something you get used to, looking at the root of the
spew is generally your best bet. Also they have built in debug nodes you can
trivially add to your grammar that will spew every step of the lexing/parsing
process so you can easily see where things are going off the rails if your
grammar is wrong. Compile times are definitely increased in my experience,
don't recall the binary bloat though it has been awhile since I played around
with it, a good compiler should be able to fairly aggressively trim it down.
Will it be as optimal as a hand written system (assuming you know what you are
doing)? Unlikely, but it will be much quicker to get up and running if you
know Boost.Spirit.

------
raverbashing
Sincerely, from the bottom of my heart: It doesn't matter

I have some familiarity with some of the systems described (and with other
systems that use C++). Let me put it this way:

\- Large enterprise projects are bad

\- Large enterprise projects in C++ are _very bad_. It's like giving razor
blades to a kindergarten group for a whole afternoon. I wish I was kidding

\- "Done in C++" is not as important as the capabilities of the platform
targeted

C++ is good, and very powerful. And I have a million reasons not to use it
unless absolutely necessary.

If you want to use it I'll give you 3 tips:

\- Focus on STL and maybe Boost (use it sparringly and wisely! don't overdo
it)

\- Avoid inheritance hell

\- Don't go crazy with Templates, in fact don't even use them (except for
what's in STL already)

~~~
Jabbles
So what language would you recommend writing Windows in? Firefox/Chrome? LLVM?

What are your reasons for recommending said language over C++?

~~~
rwmj
Something ML-derived perhaps. Strong typing, mostly functional, but practical.

I once wrote a large part of a CSS+HTML renderer in OCaml (think: the very
core of something like Firefox), and the ability to match over data structures
and use trees naturally was a huge advantage.

ML was devised as a language to write compilers in, so LLVM is covered.

For an operating system you really want a lot of different languages because
it's a huge undertaking that covers many domains. MirageOS is an OS written in
OCaml, so that's a proof that it's possible at least.

~~~
apaprocki
I was under the impression Rust was being developed by Mozilla to eventually
be their language of choice for implementing software like Firefox precisely
because C/C++ leads to too many (security) bugs among other things. At least
one of the reasons, anyway..

~~~
fusiongyro
Just for utter clarity, the FAQ states:

Q: What will Mozilla use Rust for?

A: Mozilla intends to use Rust as a platform for prototyping experimental
browser architectures. Specifically, the hope is to develop a browser that is
more amenable to parallelization than existing ones, while also being less
prone to common C++ coding errors. The name of that project is Servo.

Q: Are you going to use this to suddenly rewrite the browser and change
everything? Is the Mozilla Corporation trying to force the community to use a
new language?

A: No. This is a research project. The point is to explore ideas. There is no
plan to incorporate any Rust-based technology into Firefox.

<https://github.com/mozilla/rust/wiki/Doc-project-FAQ>

~~~
apaprocki
I was being careful and said software _like_ Firefox :) From discussions I had
with people about Rust it seemed obvious that if it reached maturity then it
could be considered for new projects starting from scratch.

------
jballanc
I was one of those who was vehemently anti-C++. Then I read the source code
for LLVM (or, large chunks of it...it's a rather large code base). Now I am of
the opinion that beautiful things can be created in C++ as well, it just takes
considerably more talent than were you to use any other language.

~~~
tjdetwiler
C++ isn't bad by definition, however a large quantity of C++ out there is just
_bad_.

Then again most OOP languages get abused pretty badly.

~~~
betterunix
Actually, C++ is bad by definition. The C++ standard has some serious
deficiencies that make it harder to write reliable code (and forget
maintenance). Part of the problem is that the C++ standard is written with
compiler writers in mind, rather than with C++ users in mind, and so some
things (like not unwinding the stack until an exception is caught, thus
avoiding the double exception fault) are not done, and new problems are simply
layered on (like causing the default behavior for exceptions propagating out
of destructors to be program termination).

At this point, C++ should be placed in the same category as COBOL: it is a
language you learn because you need to maintain some old code that nobody has
time to rewrite or replace.

~~~
kevinnk
"the C++ standard is written with compiler writers in mind, rather than with
C++ users in mind" Just looking at the enormous lengths compilers have to go
through to correctly parse C++ should tell you this isn't true. C++ does have
some rather glaring deficiencies, but the idea that they're there to make
compiler writers lives easier is outrageous to say the least.

~~~
betterunix
Sure, it is hard to write a C++ compiler. Yet neither the C++98 standard nor
TR1 fixed the template/right problem, despite it being a major source of
headaches among C++ programmers, because compiler writers complained about the
complexity it would have added to the grammar. It was not until the majority
of commonly-used C++ compilers began to emit a suggestion about the problem
that the committee finally fixed it in C++11, and even then, the committee had
to convince compiler writers that it was a good idea. That same pattern of
behavior can be seen with the double exception faults: compiler writers were
unwilling to put in the effort needed to catch an exception before the stack
is unwound (without making compiled code slower), and so instead the standard
was updated to further cement the idea that destructors should never throw
exceptions.

No, it is not purely for compiler writers, but compiler writers and library
implementors are a powerful group on the standards committee.

~~~
kevinnk
What you're describing sounds more like "C++ strikes a balance between
features and implementation difficulty" not "C++ is written for compiler
writers." And even that's charitable because it's not like we haven't gotten
hard to implement features either. Templates (especially SFINAE), lambdas, and
even concurrency and generalized attributes are all places where
implementation difficulty was trumped by users. I do agree that
compiler/library writers can slow down good features, but they have an
important position that needs to be heard and weighed with every other voice
too.

------
marme
Most of amazon.com systems are written in perl mason. Very few systems use
c++, I would say not a single major system at Amazon is written in c++. It
definitely should not be included in this list

~~~
justrudd
Disclaimer: I left Amazon in 2008. I've tangentially stayed in contact with a
few people there in my old groups.

I worked in Supply Chain specifically on the FC side of software
(OK...specifically on COFS for those of you who remember) from 2004 till 2007
before moving over to retail. And I can say that all FC software was C and
C++. There were small pockets of Java when I left, but I'd be really surprised
if ALL of FC software has been ported to Java in the last 4 years. You're
talking about 10+ years of software. Software that controls hardware that
works as is. Tons of "bugs" and "features" to port.

And I'd call the software that runs the warehouses a major system.

My team tried to replace a C++ daemon with a Java one and our favourite phrase
became "Oh yeah. Forgot about that business rule".

------
arocks
This list proves nothing. C++ is often used for performance reasons or even as
a target language. Facebook's HipHop compiler converts PHP into C++. I would
argue that it means that Facebook develops in PHP rather than C++.

Similarly Adobe's most recent product Lightroom was about 63% written in Lua
[1] which they attribute to its rapid development.

What would be interesting is a table which shows what percentage of developers
or projects predominantly develop in C++. I am guessing it would be a much
smaller number.

[1]: <http://www.troygaul.com/LrExposedC4.html>

~~~
CCs
Now at Facebook there are about as many C++ developers as PHP. Sounds like a
shift to me...

<http://www.johndcook.com/blog/2012/04/11/facebook-and-cpp/>

~~~
16s
C++ is coming back in a big way because it saves money. It is the king of
performance per watt, per cycle, per transistor which directly translates to
performance per dollar. It cannot be beaten.

[http://www.alejandrosegovia.net/2011/09/08/herb-sutters-
why-...](http://www.alejandrosegovia.net/2011/09/08/herb-sutters-why-c-talk-
sum-up/)

------
blakesmith
Honest question: Is C++ really worth the complexity over something like C? I'd
love to hear people's technology evaluation thought process when choosing C++.
To me, C seems far less complicated, while still providing similar levels of
performance. I tend to enjoy languages that are small and get out of my way,
but if C++ let's me be that much more productive than C, I'd like to make a
serious effort to spend more time with C++. What do I gain from C++ that I
can't get from C? Is it worth the tradeoff?

~~~
twoodfin
The two things I miss most when writing C instead of C++ are RAII and
exceptions. Both relocate and consolidate code unrelated to the intention of a
function (resource management and error handling, respectively), making it
easier to write, read, maintain and debug.

I also find function templates very useful while prototyping: Rather than
having to select concrete data types up front, I write a function "as if" I
have objects that can perform the operations I need. Now I have a concrete set
of requirements (the standards committee calls this a "concept") for my
classes. And if I've done it right, whatever abstract idea I've expressed in
the function template need never be expressed again.

With some practice, it's remarkable how much C++ allows you to remove
redundancy and repetition from your code. All without paying much, if any, of
an abstraction tax.

------
sprash
Seems to be a very old list or it might tell you this: If you start a new
project, don't use C++.

<http://harmful.cat-v.org/software/c++/> tells you everything.

~~~
CCs
The link you have is also old - most of the issues reported there are not
valid anymore with C++11.

BTW, at least for Windows 8 now Microsoft recommends you to start new projects
in JavaScript or C++ (in this order).

~~~
betterunix
C++11 introduces new problems. Programmers are expected to know how a lexical
closure should capture variables from the enclosing scope -- should it be by
reference, or by value? Programmers are also expected to know that when they
capture by reference, sometimes they are really supposed to capture by value
but with smart pointers (and of course, they are expected to know which kind
of smart pointer they need). Instead of fixing the double exception fault,
C++11 just punts on the issue and says that no exceptions are ever allowed to
propagate out of a destructor (which is another way of saying, "destructors
must never signal errors, even for things that are correctable like running
out of disk space).

That Microsoft would recommend JavaScript or C++ is unsurprising, considering
how much business those languages have generated for them and how many
programmers who support the Windows ecosystem are only comfortable in one of
those two languages.

------
gerhardi
Yes, C++ has been and will stay as the language of choice for many major free
and commercial apps. It's not very surprising as there exists quite a lot of
professionals with skills in C++ and the performance of applications written
in C++ is generally very good.

~~~
gregsq
I'm doing mostly embedded work on ARM chips at the moment. Which is a world
away the rooms of Sparc V9's I've also worked on. It's a tighter space and you
can't use too much of C++'s bigger bits. But multiplexing an SPI bus with C++
for example was vastly more efficient coding and performance wise because you
don't need to remember whether some function or other set a mutex and released
it. A specific custom lock in the base class improved code review and
mutability.

It has it's uses.

------
tambourine_man
The list seams very old. ImageReady and AppleWorks died years ago.

------
TheAnimus
The interesting thing about the list to me is how many of these applications
are written in C++ and one or more other languages.

There is a certain monotheistic outlook by most developers, and I fear this
list does nothing to help it. Everyone knows the merrits and use of C++,
surely its not in doubt, but to suggest that its the only solution is frankly
silly.

An example plucked from the list that intreged me is Sophis, the risk system.
The reason is more and more of these systems are been made in Java or .Net, in
fact Sophis itself is using more .Net internally with every new revision. The
reason being that performance issues are normally far more related to the algo
than the language, having a mixture of functional bits thrown in helps the dev
make a leaner algo. Mixing such paradigyms is just easier in .Net than C++.

------
tuzemec
To my knowledge most of the games/game engines are c++. I'm not a hard-core
programmer, but I'm frequently interacting with that breed and almost all
projects that require high performance are implemented in c++.

------
damian2000
He missed off Windows 8; if I'm not mistaken its written primarily in C++?
Also the "native" language for programming against the Windows Runtime SDK is
C++, although it can easily be consumed by others like .NET and JS.

------
nmridul
Not many web frameworks in the list. <http://www.webtoolkit.eu/wt> is a good
one that should have been there ..

------
jcfrei
notable absentee (and probably the most ubiquitous piece of software) - the
linux kernel.

~~~
CCs
The Linux Kernel is C (not C++)

~~~
tjdetwiler
I guess he didn't know how much Linus loves C++.

------
bborud
"I felt a great disturbance in the Force, as if millions of voices cried out
in terror and were suddenly silenced. I fear something terrible has happened."

