Comment by arinlen | Hacker News Reader

Comment by arinlen | Hacker News Reader

Parent Full thread

> Modern C++ it's overcomplicated and from what I can see all the best software engineers I met in my careen write very simple C++98 code, maybe a bit of C++11 but that's it.

I'm sorry but this assertion does not pass the smell test.

Sticking with C++11 means you do not have std::make_unique, and any claim that these "best software engineers" not only fail to use smart pointers but also refuse to even consider instantiating a std::unique_ptr in a safe, standard way and for no reason at all is something that lacks any credibility.

> Modern C++ is for experienced C++ developers

It really isn't. "Modern" C++ is just the same old C++ with useful features that improve the developer experience (see aggregate initialization, for starters,nested namespace definitions, utf8 character literals, structured binding, etc) and don't require developers to resort to in-house trickery passed around through tribal knowledge to implement basic features (move semantics, constexpr, etc).

> It's just disappointing...

Speak for yourself. It's fantastic that people continue to improve the language and make everyone's life easier, instead of being stuck in the C++98 mud. Each and every single major standard release since C++98 brought huge productivity and safety improvements that everyone stands to benefit. Even standardizing stuff from Boost and the like is a major step forward.

It's totally fine that you personally prefer to not benefit from any of the improvements that sprung in the past two decades, but don't presume for a minute that you represent anyone beyond yourself when making Luddite-like claims.

> Sticking with C++11 means you do not have std::make_unique, and any claim that these "best software engineers" not only fail to use smart pointers

Pretty much every non-trivial C++ engine i've seen has its own equivalents for memory management. Even a game engine development book i bought in ~2001 (meaning it was written before then) had a chapter dedicated to implementing smart pointers.

Which doesn't mean that they are any better than the provided standard implementations.

They are there because it makes sense to have them. Now you don't have build and maintain your own ship.

> Which doesn't mean that they are any better than the provided standard implementations.

That standard implementation is a thin wrapper over malloc(). That standard malloc() is not necessarily good enough. The performance is not great, but worst of all when you have many small objects, they are scattered all over address space. Chasing many random pointers is expensive.

While it’s technically possible to use custom memory management with std::unique_ptr with that that second template argument with custom deleter, it complicates things. The code often becomes both simpler and faster when using custom smart pointers instead.

That’s not specific to videogames, applies to all performance-critical C++. These standard smart pointers are good for use cases with a small count of large long-lived objects. For large count of small things, the overhead is too large, people usually do something else instead.

> That standard malloc() is not necessarily good enough.

The operative word is "it enough".

Let's not fool ourselves by claiming that all memory allocations take place in hot paths, and that all conceivable applications require being prematurely optimized to the extreme because they absolutely need to shave off that cycle from an allocation.

Meanwhile people allocate memory in preparation of a HTTP request, or just before the application is stuck in idle waiting for the user to click on the button that closes the dialog box.

It makes absolutely zero sense to proselytize about premature optimization when no real world measurements are on the table.

Let’s not pretend all conceivable applications are, or should be, written in C++.

People mostly stopped using C++ to develop web servers which handle web requests, because they moved to Java, C#, PHP, Ruby, Python, etc. People mostly stopped using C++ to develop GUI apps which handle these buttons, because they moved to Java, C#, and now JavaScript/TypeScript.

What’s left for C++ is software (or sometimes individual DLLs consumed from other languages) which actually need it to achieve the required performance. Even despite the language is unsafe, low-level, and relatively hard to use which directly affects software development costs.

But at the same time, straightforward C++ code with no tricks is still orders of magnitude faster than Python or PHP, and usually faster than Java and C#. So you still don't need custom allocators etc to be "good enough" most of the time.

I agree about Python or PHP.

However, for Java or modern C#, in my experience the performance is often fairly close. When using either of them, very often one doesn’t need C++ to be good enough.

Here’s an example, a video player library for Raspberry Pi4: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo As written on that page, just a few things are in C++ (GLES integration, audio decoders, and couple SIMD utility functions), the majority of things are in C#. Still, compared to VLC player running on the same hardware, the code uses same CPU time, and less memory.

> However, for Java or modern C#, in my experience the performance is often fairly close.

Aren't you contradicting yourself? You started off complaining malloc of not being good enough, but now it's suddenly ok to tolerate Java and C#'s performance drop when compared to C++?

Which one is it?

> * Let’s not pretend all conceivable applications are, or should be, written in C++.*

This is a discussion on C++.

> People mostly stopped using C++ to develop web servers which handle web requests, because they moved to Java, C#, PHP, Ruby, Python, etc.

I'm not sure you understood what I said, or thought things through.

By the way, the top performing web framework in the Tech Empower benchmark is a C++ framework which uses C++'s standard smart pointers.

https://github.com/drogonframework/drogon

Also, one of the most popular web frameworks for Python started off as an April Fools joke. I'm not sure what's your point.

Lastly, the main reason why C++ ceased to be the most popular choice in some domains was because it was during a very long time the most popular choice in some domains, and still remains one of the most popular choices. Some of the reasons why C++ dropped in popularity is the fact that some vendors decided to roll their own alternatives while removing support for C++. Take for instance Microsoft, which was once responsible for making C++ the only tool in town for professional software development. Since it started pushing C# for all sorts of web applications, multi-platform applications, and even desktop applications, and also pushing the adoption of those technologies as a basic requirement to distribute apps in its app store, developers can only use technologies that exist. But does that say anything about the merits of C++?

> I'm not sure what's your point.

Over time, it became less important for C++ to be a good general-purpose language. When performance of idiomatic C++ is good enough, using C++ is often a bad idea: it delivers comparable performance to C# or Java, but it’s more expensive to use. While technically C++ has desktop GUI frameworks, web frameworks and others, they aren’t hugely popular: due to development costs, people typically prefer higher level memory safe languages for that stuff.

For use cases like videogames, HPC and similar, C++ has very little competition, because that level of performance is borderline impossible to achieve in other languages. It’s for these use cases people care about costs of malloc, cache-friendly RAM access patterns, and other things which are less than ideal in idiomatic C++.

Ironically Microsoft is the only OS vendor for mainstream platforms that still ships a GUI SDK that gives tier 1 treatment to C++ with WinUI, and even then the tooling is really clunky (back to VC++ 6.0 COM days).

On the Apple and Google side that ship has long sailed, with C++ used only on the lower OS levels, and as basis for MSL.

Naturally there are still the GUIs for game consoles left (although XBox dashboard uses React Native, with the previous generation being UWP, PS 4 famously used WebGL), and special purpose embedded devices.

For the longest time I've written my own smart pointers to manage the lifetime of pretty much anything that needs a cleanup - database connections, query objects, file handles, threads, mutexes and yes raw pointers.

All of this code built just fine on pre c++11 compilers, ran reliably, was performant and easy to maintain.

Rolling your own smart pointers is not something I'd discourage.

It might be easy to maintain to you. Somebody who has to pick up that codebase later would have to spend time and effort figuring out all those custom smart pointers and their idiosyncrasies. If all they do in the end is the same as unique_ptr & shared_ptr, it's all wasted time.

> Somebody who has to pick up that codebase later would have to spend time and effort figuring out all those custom smart pointers and their idiosyncrasies.

If we're still on the topic of game engines, someone who cannot easily figure out a smart pointer implementation has no place working with the game engine's code in the first place.

Unreal Engine has its own implementation for that stuff and it took me literally minutes to get to grips with it - same with the custom engines in companies i worked at before. This has absolutely never been a real problem in practice.

Reply on news.ycombinator.com