Hacker News Reader

Comment by jhartmann | Hacker News Reader

A lot of people state that Python/PHP/Ruby/Javascript on the dynamic language side and Java and other JVM languages on the statically typed side and much quicker to develop than C++, but being a very experienced Java programmer and a decent Javascript programmer I find that I can program just as fast with C++ as long as you use the right choices of libraries and use C++11 or greater. With libraries like Boost, fbfolly, wangle, etc. I find it can be just as quick to develop C++ code as with other languages. I think too many people think C++ is a huge investment above other languages due to past experience, but I feel that it is just not true anymore. Thanks for this post, I think it shows just how quick it is to write performant modern C++, when you stand on the shoulders of other libraries. Just like the other languages.

View on HN

I think the crux of the development time arguments is that alternatives (eg Django, Rails) are often monolith projects that let you do everything (database modelling, controllers and templating) all in a single convenient, well documented and thoroughly battle-tested library.

You highlight the daunting prospect of moving to C++. You need to pick half a dozen separate libraries and glue them together. Sure, once you've done that a few times it's pretty quick, but it's a scary prospect for a Django dev who can program in C.

Modern C++ is indeed pretty productive. It's the tooling and compile times that hold it back.

Tooling is getting better, CMake is awesome. Modules would reduce compile times significantly but it seems C++17 won't include them, so we'd have to wait a bit longer.

Perhaps you mean link time? If you're spending a lot of time compiling you are probably suffering from other problems. Most of C++'s issues with compilation come from needing to re-compile entire .cpp files because of a change in a depending .h file. If you properly forward your class declarations instead of including a header in a .h file, don't do template meta meta magic, and think about physical design a bit, your compilation time should be under control.

What I mean by physical design is, if a particular function is prone to be edited constantly, keep that function definition in it's own .cpp file.

of course I'll agree that in this day and age, we shouldn't worry about those sorts of things.

You can usually get a noticeable speedup using unity builds, even when using something like Incredibuild. That suggests that more source files is not the answer. (I am not going to speculate as to why things are this way; it simply appears to be the case.) I'm not sure it makes a great deal of sense to separate compilation time from link time anyway (and you should also consider device reboot or program startup time as well). It all adds up to the same thing: shameful turnaround times.

This has been a problem on every C++ project I've worked on over the past 15 years, and it only seems to be getting worse. And scaled up by increasing team size, that makes it even more of a serious problem.

I hope your parting shot was intended to be that we shouldn't have to worry about this today, i.e., that we should be able to expect more from our tools, and that the current tools are shit. Because we absolutely should worry about it! This is people's time we're talking about. That isn't any less valuable than it used to be.

Often with large C++ codebases the link step can be the bottleneck. Not only it can't be easily parallelized for a single target, but even if you have multiple independent binary targets, the high memory usage of the link step makes it hard to run multiple lds at the same time.

I have seen optimized builds run faster than debug builds simply because many symbols where being removed during optimization speeding up the link step.

But when you do need generics and use templates, you are forced to write lots of code in .h files. There is very little you can do in that case to speed up build times, without resorting to devious things like PIMPL.

Unfortunately, even PIMPL won't help with templated code, unless you resort to manual template instantiation which is tedious.

A lot of C++ compile time is simply generating and optimizing all the code. Modules don't help with this.

Modern C++ style generally requires making a whole bunch of little functions and classes and counting on them to be inlined and SROA'd away. This works remarkably well for runtime, but it exacts a big compilation performance hit simply because you're optimizing so much code.

Interesting anecdote, I was writing a ray tracer recently and instead of using real recursion I tried using a recursive template instead (because who needs i-cache). Basically, every bounce of a ray was a different function with <current_bounce + 1> until <max_bounces>.

The actual ray-tracing code wasn't that long at all, but if you turned max_max_bounces up (say, 100+) "code-gen" time in visual studio blew up to over one minute. That was the moment when I appreciated what everyone was saying about C++ compile times being quite slow if you (mis)use templates.

I have settled on Lua and C/C++ as my principle language/environment and it is a real joy. I think anyone who is 'into' C++ and hasn't yet grok'ed what Lua can do for them is going to have a good time if they dig deeper. Lua can do anything those other languages can do. And you can write C++ for the hard stuff.

I'm sort of surprised it doesn't come up more in this environment, but modern C++, Lua, and LuaJIT .. these things appear, to me, far more valuable than given by the hoipolloi ..

The point is, an investment in C++ does not mean you can't 'have all the fun toys too', because .. you can. And boy do they kick ass.

For network-facing software, though, the memory safety problem is a huge one. It's one you just don't have with Python, PHP, Ruby, JavaScript, and Java. And I don't see any solution to it in the near future.

Do you have any pointers to learn modern C++?

Some resources:

The Definitive C++ Book Guide and List : http://stackoverflow.com/questions/388242/the-definitive-c-b...

I like the breakdown of books by their goals in this FAQ : https://isocpp.org/wiki/faq/how-to-learn-cpp

I would say 'C++ Primer 5th Edition' and 'The C++ Programming Language 4th Edition' are good.

And of course, Effective Modern C++, although the other Effective series books from Meyers are a must read.

http://www.informit.com/store/c-plus-plus-primer-97803217141...

http://shop.oreilly.com/product/0636920033707.do

http://www.informit.com/store/c-plus-plus-programming-langua...

http://www.informit.com/store/effective-c-plus-plus-55-speci...

Hi there, I'm interested in learning C++ but is it worth waiting for the C++17 spec to be finalised first? Will there be any significant changes in C++17?

Don't wait. Learning C++11 will put you ahead of the majority of C++ programmers. Learning C++14 put you on the bleeding edge.

After sitting down and getting everything actually working between 2000-2010, C++ now seems to be on a steady path of improvement with major releases every three years with no plans to stop.

So, it's not a matter of waiting for things to finalize. It just deciding to go ahead and climb on board the moving train.

If one is choosing C++ then performance is probably a part of the requirements equation.

These books discuss performant (and sometimes complex) C++ code - in the domain of computer graphics.

http://www.amazon.com/Physically-Based-Rendering-Second-Edit...

http://www.amazon.com/Real-Time-Collision-Detection-Interact...

About how to use the new threading standard: https://www.manning.com/books/c-plus-plus-concurrency-in-act...

Stroustrup's C++ book is good - the tour in the early part of the book covers many aspects quickly but the rest of the book is helpful reference for explaining parts that are only briefly touched on in the first bit (or if you don't quite "get it").

Also, the rest of the book is well written and worth reading for completeness, if not rather lengthy.

Does modern C++ have a decent story for writing nonblocking concurrent code yet? Something that could compete with async-await in C# or monads in functional programming?

A networking library based on Asio has been proposed for C++17. In the meantime, use Asio.

http://think-async.com/

http://think-async.com/Asio/AsioStandalone

!! I've always heard that Asio is great, but never bothered to look because I don't like introducing Boost's 450 megs of compiler-test-suite-worthy C++ to my >45kb programs. But, as a stand-alone library. That's interesting!

Well, threads just became a part of the standard with C++11. As to how to use them, there is a decent story, you just have to type it yourself :)

https://www.manning.com/books/c-plus-plus-concurrency-in-act...

await is coming, maybe even in C++ 17. Visual Studio already implements it. Way more efficient than the C# implementation too (coroutines)

Promises are already there.

Promises are not really there. The C++11 version of std::future is missing future::then, which makes it useless for most concurrent tasks. You can launch subtasks on other threads and wait for the result with this future implementation, but you can't asynchronously wait for results of tasks in the same thread.

This will also only be fixed in C++17. Boost future already implements more of this, but afaik it's still flagged as experimental, so it could change again. And afaik there were also some pending discussions about how futures should interact with schedulers/executors.

Not really familiar with async-await but perhaps std::future and std::promise are helpful?? Less low-level than threads to some extent.

I'd recommend to take a look at Seastar: http://www.seastar-project.org/

Briefly: "Seastar is event-driven and supports writing non-blocking, asynchronous server code in a straightforward manner that facilitates debugging and reasoning about performance." -- http://www.scylladb.com/2015/02/20/seastar/

Concurrency model: "Seastar futures/promises/continuations (f-p-c) are a subset of reactive programming.

Seastar performance derives from the sharded, cooperative, non-blocking, micro-task scheduled design, and f-p-c are a friendlier way of feeding tasks to the scheduler.

Seastar’s f-p-c do have some optimizations relative to other f-p-c designs. They trade off thread safety, which is unneeded due to the sharded design, for scheduling efficiency, and have a very low memory footprint." -- http://www.seastar-project.org/faq/

If you'd like to find out more, here are a few links with more information (including examples and tutorials):

- https://github.com/scylladb/seastar/wiki

- https://github.com/scylladb/seastar/blob/master/doc/tutorial...

- http://www.seastar-project.org/futures-promises/

- http://blog.cloudius-systems.com/2015/04/29/seastar-tutorial...

- http://www.slideshare.net/TzachLivyatan/seastar-sayeret-lamb...

In terms of practical applications, ScyllaDB (fully compatible--and significantly faster--drop-in replacement of Apache Cassandra) relies on Seastar: http://www.scylladb.com/

ScyllaDB has been discussed here before: https://news.ycombinator.com/item?id=10262719

I agree. I got websocket server and client apps running in modern c++ in just a few days of tinkering in my free time. It took no longer than when setting up servers in Clojure, which is quite a productive language as well.

It's refreshing to hear other people think the same thing. Most of development time isn't spent physically going code. By picking C you get a high performance layer which can save a lot in infrastructure headaches and has the best performance analysis tools like vtune.

That said I've found nodejs slightly nicer for distr

Just curious, how is nodejs nicer for distribution than a binary file?

Ah bummer, looks like my response was cut off :(

If you can bundle all your dependencies into a static file you're right, C/C++ is actually better as you have no install requirements.

However in terms of maintaining your dependencies, nodejs can be pretty great with package management coming with the npm tool. When you want to share your code with the world, and for someone else to actually use it, nodejs is easier.

In C/C++ you can use CMake to have external dependencies on git projects which is the best I've seen that you can do. If you know of any other tools that help with these problems please tell!

I would love you to show us the C++ equivalent of this trivial PHP code:

    <?php
    $data = json_decode(file_get_contents('data.json'));
    foreach ($data as $obj) {
        echo $obj->x . ',' . $obj->y . "\n";
    }

That's the entire script.

Take a look at JSON for Modern C++: https://github.com/nlohmann/json

Perhaps this example (benchmark, actually) is close enough: https://github.com/nlohmann/json/blob/master/benchmarks/benc...

Note that the above also performs mini-benchmark with multiple iterations, dumping parsed data to another file, and finishes with a clean-up of the aforementioned dump target file.

The core (read, parse, write) can be simplified to:

  std::ifstream input_file("data.json");
  nlohmann::json data;
  data << input_file;
  std::cout << data;

No no no, this won't compile. Write the complete code, with all the includes, main function, etc. And write it correctly, iterating over the data, accessing the object fields.

All right, then: This one is complete (compiles, runs, iterates through the data, accessing only fields "x" and "y"):

  #include <fstream>
  #include <json.hpp>
  
  int main()
  {
  	std::ifstream input_file("data.json");
  	nlohmann::json data;
  	data << input_file;
  	for (auto obj : data)
  		std::cout << obj["x"] << ',' << obj["y"] << '\n';
  }

There is _absolutley_ no value for a language to provide handy built-in functions that are trivially made available by a library.

If we were talking about language constructs/semantics or flow-control abilities, I'd have a very different opinion - but not having a json decoder builtin, is no reason to use or not use a language.

Don't dodge the question. Use any available library you want, just type the code that will compile.

Reply on news.ycombinator.com