Nobody Understands C++: Intro (2007)

But surely GP cannot be talking about std::bind in the context of

> Ever since C++ got lambdas, I would say that bind should be considered deprecated

since both came about in C++11.

Given the context of the article, GP is most likely talking about boost::bind, which was intended as a replacement API for std::bind1st, std::bind2nd (which were deprecated in C++11 and removed in C++17), and largely fills the same niche that std::bind does (except with surprisingly many caveats / differences between the two).

Please keep the quality of conversation high here. Thank you.

The main difference between Java and C++ in the features you listed boils down to a key difference between Java and C++: object ownership and lifecycle management.

Java's "let's just heap allocate the world and let the JVM sort itself out" allows Java developers to be oblivious to the need to actually think about the life cycle of any object at all. That's fine for some uses, and definitely most of Java's uses, but it's also something that prevents Java from even being considered an option in performance-minded applications. It also gets Java developers to develop incomplete mental models of how computers work. For example, a Java developer who does not understand pointers/references is also a Java developer who fails to understand Java's value and reference types. A Java developer who doesn't understand constructors has also more pressing matters to concern himself with.

In C++, there's a conscientious effort to ensure developers have full control over the life cycle of each and every single object ever instantiated throughout an app session. Smart pointers were added to provide clear semantics on how heap allocated objects should be owned and shared. Move semantics were added because developers want to transfer ownership of resources instead of having to deep copy objects around. These features are aimed at performance and memory safety in a language that by design allows developers to handle low-level details if they want to.

Then there's the backwards compatibility. Perfect forwarding is basically syntactic sugar to get rvalue references to work as expected.

> The worst thing is that after it finally compiles I feel I can't be sure if I've followed all the rules and best practices correctly or if it's going to blow up spectacularly and potentially unsafely at runtime.

The same goes for any programming language. You mentioned Java. I know people who work at an unicorn whose hiring process consists of putting together a Java web service, and they outright rejects people who present a project that hasn't been onboarded onto PMD or SpotBugs. We're talking about companies who hire experts and enforce code reviews, and they still enforce the use of linters and static code analyzers.

Basically most of the complexity I mention comes from memory management. It's just a lot of details to know about and keep in your head. It's the price to pay for the flexibility and power.

In Java you need to understand references and object lifecycles or you get memory leaks and slow applications.

Actually, I work on a performance sensitive application and it's written in Java and it's a good choice for it, since the performance comes from algorithmic complexity, mostly from asymptotic complexity. A C++ rewrite wouldn't significantly impact the performance of the application.

That's basically the point: your complain is not really about C++. You're complaining about a computational problem that some programming languages abstract away with a heavy performance tradeoff. Programming languages that allow developers to manage memory will also force developers to think through memory management and object life cycles. This is not a problem caused by or specific to C++. That's the natural consequence of programming computers.

> Actually, I work on a performance sensitive application and it's written in Java and it's a good choice for it, since the performance comes from algorithmic complexity, mostly from asymptotic complexity. A C++ rewrite wouldn't significantly impact the performance of the application.

I'm sorry for being blunt, but if you think performance-sensitive applications stay at the algorithmic complexity level, you are definitely not dealing with a performance-sensitive application. You're just not writing naive code.

To go straight to the point, performance-sensitive applications are applications where low-level details, such as if memory is allocated at all, if an object is copied or not, and if some data is kept in cache, represent critical performance regressions. We're talking about details beyond cache locality, and keeping that cache hot is a critical feature. Algorithms alone don't cut it.

I recommend checking out the talk from Timur Doumler on low-latency C++ to see what I'm referring.

https://m.youtube.com/watch?v=EzmNeAhWqVs