HN Explorer

Ask HN: Name good examples of Modern C++ usage

82 points by marenkay ↗ HN
Hi folks,

I'm basically looking into making the transition from a C++98 world into what is supposed to be Modern C++.

Since that is a rather opinionated field I'd love to see a few real world examples. Shoot links to your favourite Open Source project :-)

43 comments

[ 115 ms ] story [ 1474 ms ] thread
desdiv
https://github.com/dolphin-emu/dolphin
jchw
ha. As a former contributor to dolphin-emu (very minor though, too busy :() I'd caution against calling it a "good example of Modern C++." It's an amazing program written by super smart people, but some of the things that lurk in there can be quite messy.

Of course, I'm sure it has improved markedly since the Google Code days, but still...

That being said, on the other hand, there ARE some nice usages of modern C++ in certain parts. I also like their choice to move to #pragma once - I know it's non-standard but despite pretty intense arguments it seems to do the job just fine.

jchw
Since Dolphin-emu came up, in the realm of emulators I have to mention byuu's Higan emulator. It's got some really cool stuff going on, though the perfectionism is a bit intense (it has its own STL-replacement!) YMMV for some of the decisions, but seriously, there's a lot of great stuff. I always cite the ARM instruction decoder as being my favorite part, but there's really a lot of great use of cutting edge C++ all over the place. Byuu seems to adopt C++ features roughly as soon as GCC and Clang support them, or maybe sooner...

If you want something a bit more orthodox, or perhaps less depending on how you look at it, on the other end of the spectrum is the intensely engineered "Boost" libraries. Though, to be honest, that may be pushing it as far as "modern C++" goes considering it's written to support older C++98 compilers in many instances.

Qt 5 is one of my all-time favorite C++ projects, although it's again worth noting that it may be pushing it to consider it modern C++. I believe they're currently on C++11 with Qt, so a bit further than C++98. Still... there's plenty to learn about even older C++.

There's more out there, but those are the ones that come to mind for me. I have been out of the C++ game for a while now.

jchw
Oh yeah, one last thing: not an example, but a pretty useful reference- Google's C++ Style Guide.

https://google.github.io/styleguide/cppguide.html

I've not read the whole thing, but it looks pretty solid. Of course, there's a lot of highly subjective suggestions, but I can get behind many of them personally.

gumby
Note that the style guide contains recommendations specific to Google's situation (they note this in the guide). For example they recommend against exceptions because by the time the style guide was written they already had an installed base. Had they started over they would use them.

Having recently started a project from "empty buffer" state we elected to go with C++17 (supported now in both GCC and clang although with some library features still missing). It's worked out well for us, but in my case I approached it as a brand new language rather than an evolution of old C++ (which I'd started in the cfront days and dropped around 2000). In that light it became and expressive and powerful systems programming language that is fun to use.

jchw
To be honest, I still don't use exceptions. They don't really feel all that great in C++, and I think Go has solidified my anti-exceptions attitude. A lot of the STL and standard libraries and even many third party libraries also abstain from using exceptions since they behave poorly across library boundaries on many platforms thanks to the lack of properly standardized ABI, and of course because the standard libraries try to be as unassuming as possible. Of course, you can still more or less safely use exceptions if you control your ecosystem, but since this is the case, it gives a (pardon my french) PHP feeling of inconsistency in many ways.

There may be compelling reasons to use exceptions, but if there were I think they have to be quite compelling to overcome the limitations.

Ace17
> since they behave poorly across library boundaries on many platforms thanks to the lack of properly standardized ABI,

The same also holds for, say, std::string. You can't pass them across library boundaries without a unified ABI. More generally, you can't pass anything STL-ish between library boundaries.

Why make a special case for C++ exceptions?

jchw
Because throwing an exception can bubble across library boundaries, including over C-style APIs that are fully compatible across library boundaries.
mhh__
If your C-api throws and then doesn't handle exceptions, then it's not a C api, it just happens to use the C ABI.
jchw
It's more complicated than that, though, because a C library seldom controls the callstack. Exception throwing is viral.

A valid example would be using a pure, fully ANSI C library with no dependencies in a C++ program, but then, in a callback PASSED to C APIs, accidentally allowing an exception to leak. Then, your runtime will try to unwind the stack and can implode on itself.

There's definitely more valid cases where this can happen, but since C APIs generally do rely on callbacks for many things, it seems like a logical one.

Another case would be C-style dispatch tables like SDLs RW interfaces. Implementing them to interact with C++ classes could definitely cause problems.

Of course, happening to use the C ABI is a valid use case that actually works if you really only use the C ABIs, but once a single exception is raised all bets are off. This kind of sucks.

mhh__
I said not handling the exception, not that one shouldn't use exceptions. Handling, here, could also mean using callbacks so the C code (using the api) can customize things.

If you expose a C api, using C++ code that involves exceptions, then the exceptions should all be handled (caught) inside the C++ code. This means that should the runtime start unwinding, it will not terminate the program.

jchw
Of course. I understand that. But I am arguing that this kind of sucks.

I don't think that it was necessarily avoidable. But for a feature that's seldom used in the standard library and for the stated reasons, a lot of other libraries, it kind of sucks.

There's also other reasons I don't like exceptions, but I'll admit many of them are no longer an issue anymore. On 32 bit Windows, if you were using GCC, which was pretty likely if you were trying to do modern C++ at the time, exceptions were limited to SJLJ and DWARF2 based exceptions which both had their own problems. For one, I'd prefer my production binaries didn't require DWARF2 CFI data. Luckily I believe nowadays in 64bit you can use SEH since it isn't covered by the Borland patent for its AMD64 implementation (do I have that right?)

But I digress. If exceptions were the default and didn't have these issues, I think it would be much better. But since at least some of the issues are still relevant, you simply cannot always use exceptions depending on your needs. And that has an effect on the ecosystem that has led to a lot of mature libraries avoiding them entirely.

I'm definitely not saying you can't use exceptions, just outlining why I don't and why I believe the greater C++ ecosystem isn't all on board for them.

mhh__
I can't really comment on the GCC windows stuff: I do software on Linux, and if I'm on windows then I use VC++ (Or a good programming instead e.g. F#/C# usually). VC++ is modern enough, so the above issue don't even apply very much.

C++ works(TM) with exceptions, AFAIK the vast majority of the ecosystem would use them (Some people e.g. Google and Qt, can't due to existing code). RAII is only really intended to work with exceptions (No return values from constructors, unless! you bodge your own (which you could do, if you were a big organisation))

Edit: Just checked, SEH has been in GCC (64bit) since ~4.8

jchw
Yep. I mentioned it's not an issue anymore, but back when VC++ was less modern and GCC didn't have SEH support, life was much worse.

Now it just has the other aforementioned issues.

Obviously, RAII is better with exceptions, at least in theory. It is annoying having to constantly check if the object is valid or not. However, even the standard library does this, so I don't really think it's uncommon - there was definitely some precedent for RAII without exceptions.

pjmlp
This is one of the reasons I never liked to work with certain C++ teams back on my C++ days and drifted to other languages that don't allow to turn features off, because I always enjoyed having exceptions and RTTI turned on.
jchw
Really? I've used RTTI a handful of times but to be honest with you aside from debugging I very rarely had a use for them. I think C++ could benefit from more powerful reflection, though. Do you have any simple examples of exploiting RTTI to solve problems?
pjmlp
Yep dynamic_cast is not guaranteed to compile with RTTI disabled.

Doing static_cast instead, will open the door to fun surprises if one cannot guaranttee the safety of the pointers given to the library code.

I must add that in those days, we were making use of C++ gui libraries like OWL, followed by VCL and MFC.

agauniyal
Can I post mine :)

Here is a short but useful terminfo parsing library I wrote - https://github.com/agauniyal/termdb

And here is another for console decorations - https://github.com/agauniyal/rang

Recently I worked on a network programming library (still WIP) for college project - https://github.com/c10k/net/tree/develop

And here is a boilerplate to get you all started with Continuous Integration, Unit tests etc etc - https://github.com/agauniyal/cppb

I try to write good code everywhere but since I lack experience so the code might not be perfect. Hence I advise to go light on it. Have a good day :)

rahkiin
LLVM is my favorite C++ project. (Together with clang and swift)
mhh__
LLVM is a very interesting project when it comes to C++ style. It is very much modern C++, except that they implement quite a lot of stuff themselves (e.g. RTTI and dynamic_cast/dyn_cast). Certainly very well engineered, but I wonder whether some of the techniques are strictly necessary (It works well, so I'm not complaining)
atemerev
Doesn't contain many "modern" features, but nevertheless, probably the best C++ code I ever saw, and it is usually hard for me to give any praise for C++.

Stockfish chess engine (currently 1st place by Elo). I am really impressed:

https://github.com/official-stockfish

nick0garvey
https://github.com/facebook/folly
fishnchips
+1 to Folly for elegant modern code, but their use of shared pointers is nothing to be proud of, at least in the C++ world.
Frogolocalypse
I've yet to find a valid use for a shared_ptr. A unique_ptr is great to use for polymorphism but I've always thought if you can't figure out what owns what in memory in a program, you haven't planned it very well.
pjmlp
Then I imagine you never had the fun of feature driven software development by consultants at enterprise level.

Being one, this works like this.

Company X, which main business has 0% to do with software development requires a new feature on an application being used at deparment Y.

They send out an RFP to several consulting companies, the one that gets the gig, sends a few developers, which get a configured devenv from company X IT department and implemente the requested features and go away.

Manual memory management languages became out of fashion in such kind of companies, because it is almost impossible to jump into a gigantic ball of mud, while keeping track of all ownerships.

Frogolocalypse
I understand that you have legacy requirements to support elements that previous developers have used, but that doesn't explain why someone would use a shared_ptr in the first place. The great thing about unique_ptrs is that they take away the manual memory management. It is a complete PITA not having them. I can even see the use in weak_ptrs. My issue is with shared. I can't see how their use wouldn't lead to larger problems in code.
pjmlp
Well, Windows projects with COM everywhere, and no access to the complete code, with responsibilities scattered across feature teams.

Thankfully I only use C++ nowadays when we need to bind native libraries into Java or .NET projects, so since 2006 I never had to deal with such horror scenarios any longer.

Frogolocalypse
I 'learned' (bumbled) through c++ almost 30 years ago. I formally learned both c and c++ properly through uni more recently. I'm not sure I'll ever use another language if i want to build something that is complex but i need to be really fast. I love c but the more complex the problem, the more infeasible it gets to use. But c++? There isn't a processing problem that you can come up with that you couldn't use c++ to resolve it with. Love the language.
mabynogy
- variadic template arg (static va_start/end)

- rvalue&& (avoid few copies)

- enum class (enum with a size and a namespace)

tcbawo
I've been impressed by the Sea star Project (http://www.seastar-project.org/). It was developed to build a high throughput database (ScyllaDB) but has since been used in several other projects. I recently spent some time evaluating it as a starting point for a new application.

Also, a fan of the elegance on display is this serialization library: https://github.com/msgpack/msgpack-c

marenkay
Ladies and gents, thanks a lot; those are some nice starting points!
cottonseed
Two previous Reddit threads on this topic:

https://www.reddit.com/r/cpp/comments/489f9l/open_source_pro...

https://www.reddit.com/r/cpp/comments/5sxrun/what_are_some_e...

My list:

SeaStar and ScyllaDB https://github.com/scylladb/seastar https://github.com/scylladb/scylla

Cap'n Proto https://github.com/sandstorm-io/capnproto

LLVM

range-v3 https://github.com/ericniebler/range-v3

Facebook folly https://github.com/facebook/folly

easylambda https://github.com/haptork/easylambda

thrust https://github.com/thrust/thrust

xtensor https://xtensor.readthedocs.io/en/latest/numpy.html