[1]:https://www.amazon.com/C-Crash-Course-Josh-Lospinoso/dp/1593...

So, sure, all the code from people learning "modern C++" is smart pointers and ranges, but to get work done you have to call this library that takes raw pointers and you're immediately out of your depth.

C++ soldiers on because it can support such things and adapt to decades of changing hardware and philosophy. But the pain of using and composing libraries in C++ is not just about not having cargo or npm - it's the lack of consensus on data types for anything beyond C primitives.

Everything uses/supports standard library containers or interfaces now.

Also it's still completely normal to use raw pointers or references when a function doesn't care about ownership.

I am an old man, and to me 2011 doesn't feel ancient, but fair. C++ 11 has unique_ptr and shared_ptr (if your library uses a previous generation of smart pointers you're in worse trouble than if it had raw pointers) and that's what you'd probably teach in class today.

> Also it's still completely normal to use raw pointers or references when a function doesn't care about ownership.

This is true. So you can't tell. And, with a different hat on it's also something that Kate Gregory has given talks about. As the new maintainer for several MLOC of C++ what can I conclude about this function that takes a raw pointer to a foo ?

Maybe, it just wants to look at a foo, immediately and then has no further interest in it.

Maybe, it will mutate the foo, immediately, and then loses interest.

Maybe, it will hang on to this pointer and use it later, who knows when. Thus, now it "owns" the foo, I hope it will clean up after it ceases using it because I can't now.

Maybe, I'm supposed to provide an "empty" foo and the contents of it afterwards are the primary result of the function.

Those are pretty different, so it's disappointing that we don't learn which it is from the function signature.

Some projects in mind:

C++/SFML/SDL2 game programming using modern C++

Interpreter/compiler construction in modern C++

Explains how to implement things in modern C++ (e.g.unique_ptr) without modern C++ (maybe just use C)

Solving somewhat complex problems with standard data structures (maps, trees, hashtables, etc.) and doing it in the modern, efficient way is the kind of thing I'm really looking for.

In Python it's easy (which isn't to say everything should use Python) because you don't have to do anything but use the builtin datastructures and solve your problem.

Maybe modern C++ works the same way but if it does, I still need someone to show it since that isn't how it used to be (to my knowledge).

Eventually I just gave up and use raw pointers. My theory is that since people don't care about JVM not returning memory to system, they should also not care a bout a few MBs of memory leak in my small game.

I still occasionally write C++ when I need to, but it's been a long time since I actually enjoyed doing it.

Go is an improved C that includes garbage collection (as is needed to make bug-free concurrent programming easier).

Fast forward 20 years, and everything is Python or R.

The author talks about high frequency trading and finance applications, but it does not seem he has ever worked in the field. Production HFT is written in C++.

Also, security is generally important in this sector. Both C++ and Python do not have a good track record when it comes to security. C++ has a lot of guns to shoot yourself in the foot. Python is essentially un-typed which means that errors only show up on runtime. Where I live most financial software is still being developed in Java.

Modern Python also has optional static type checking that is already essentially standard for new code.

You have to write unit tests anyway to validate other useful properties about your code. If you’re not close to 100% you’re doing it wrong. Even 100% coverage is a fairly low bar these days.

In more general quant and financial engineering applications, I think it was ecosystem inertia as much as anything. Many of the simulation and solver frameworks were based on physics libraries written in C++, and quantlib was built on top of Boost. C++ just became a de facto lingua franca for anyone doing that kind of work, and they weren't primarily programmers, so they weren't going to spend a lot of time learning other languages and ecosystems when they were already comfortable with and productive in C++.

Besides, for high-frequency transactions I think there are better alternatives (e.g.:Rust).

Edit: this is a subjective impression, not a statement of a fact. Please feel free to disagree.

I agree that the python standard library is really useful.

unfortunately, some of the libs put performance first over ease-of-use. which can be a drag.

and then there is compiling boost which is usually a thing where i need to set aside a day or two to get it working on a new platform / project.

However, Python's standard library is stuck with urllib, although these days they have the courtesy to tell any poor fool looking at the documentation that Requests exists, if you do use the standard library you get very primitive HTTPS handling, and so many wrong defaults.

Because these standard libraries have so many users, Hyrum's law means that you have to work very hard to fix anything.

This, of course, causes everyone to roll their own String, which is probably almost as bad.

So, now we have a zillion String libraries, all of which suck.

All because the C++ standard library doesn't provide a decent String.

If you look for example at other implementations like fbstring, the main benefit is performance.

The containers according to [1] are array, vector, deque, forward_list, list, *set, *map, stack, queue and priority_queue. All of these are good general implementations that can and should be used for most C++ software.

Some classes of software require better performance or certain special guarantees and then it makes sense to consider specialized implementations.

[1] https://en.cppreference.com/w/cpp/container

Added up with "And when your project scales, Replace asyncio with uvloop, Coroutine with gevent, http.server with gunicorn and everything else with a cython based alternative".

Or personally I just say 'Use go instead' to someone who's just getting into programming for developing a project which could potentially scale.

So here are some facts:

* A good reference for the C++ standard library is https://en.cppreference.com

* The standard library is not as large as .NET or Java, but it covers many essential concepts of which the containers and algorithms are the best known. Besides classics like doubly-linked lists, dynamic arrays (std::vector) or maps, there's also sets, a singly-linked list, stack, queue and priority queue. All data structures have complexity guarantees defined in the C++ standard, which is surprisingly very rare for programming languages.

* The algorithms include sorting and searching but don't stop for example at a simple sort and instead also include a partial and stable sort. Besides binary search and linear search, there's also functions like https://en.cppreference.com/w/cpp/algorithm/lower_bound or https://en.cppreference.com/w/cpp/algorithm/equal_range and several functions for working with heaps, such as make_heap, push_heap, etc. Other interesting algorithms include those for permutations, counting, working with ranges and modifier functions like rotate, sample or random_shuffle. C++ offers a world-class algorithms library.

* The numeric library offers support for many pseudo-random number generation algorithms, and many distributions (https://en.cppreference.com/w/cpp/numeric/random). There are dozens of usual (https://en.cppreference.com/w/cpp/numeric/math) and less usual (https://en.cppreference.com/w/cpp/numeric/special_functions) mathematical functions in there.

* For systems programming there's the date and time utilities, file system, threads and atomics.

* Although standard for most languages at this point, C++ does offer regular expression support in the standard library.

* Many other smaller types and functions such as tuples, complex numbers, a modern union type (std::variant), streams, etc.

When the above is not enough, there's boost, a series of high-quality libraries with a long history which are like an extension of the standard library. My personal favorites from boost include state machines, graphs, numeric conversions, logging, program options, signals (subject-observer implementation) and ASIO for all sorts of IO.

But there's tons of stuff in there, from additional algorithms and containers to JSON parsers to HTTP and web sockets, from process and shared object management to userland threads, IPC, lockfree data structures and so on and so forth.

And if that's still not enough, there's almost certainly another library for it. C++ is one of the most popular programming languages out there and it has decades of history behind it.

Rust is being added to the Linux kernel and is making inroads in domains where C and C++ have historically been used. It can match (and sometimes exceed) the performance of C and C++ but with better memory safety and sound concurrency.

C++ won't go away anytime soon, but it's practically disingenuous to call C++ "the new Python".

With how slow the c++ community moves and how much debt they have I think it’s game over in most arenas

The trade-off was more overhead, but faster development and fewer errors due to not needing to manage memory or other low-level details.

Java is easier to write than C++ and is more portable than C++, but needs more time to get fast and more memory to work with.

By way of comparison, Rust offers all of the speed of C++ and similar low overhead with practically none of the footguns that C++ is known for.

The overall use of the language grew because everything in IT grew a lot during that time, so the niches where Java sucks grew larger than all of the C++ niches at the start.

The real question is if Rust will leave any niche. It looks like it won't, but this is not the kind of question one can really answer.

* Julia is now at the point that it can be used for interactive development and experimentation without time-to-compile issues;

* the Julia ecosystem is coming along nicely; and

* Julia has always provided near-C performance in production.

C++ is certainly not becoming the language of wannabe research data scientists that made Python grow so much, but of course there are fields where it is growing and there are fields where adoption is decreasing.

I doubt that HFT used Python before a C++ wave swept it, since speed has always been a concern, so I am skeptical of the article.

As to the "Rust is the C++ killer" crowd... show me a really big project using mainly Rust now, as there are uncountable using C++, a network simulator, a desktop application, a physical simulation engine, an operating system, a compiler, anything really big. You perhaps will find one or two, compared to thousands for C++. The best that you can hope is to see Rust seriously compete with Rust 15 years from now. And then overtaking it, perhaps. Best case scenario.

Rust isn't the anything killer, Rust is Rust. That's why it's so special; it's really in a league of it's own.

For starters, the Rust compiler is self hosted and is written in Rust. Many important parts of Firefox are written in Rust. The Linux kernel just added support for Rust. A moment's Googling could turn up plenty of other examples.

If I have to whip something up quickly, python nearly looks like the pseudo-code your would write on your paper napkin, while C++ will make you battle with pointers, references, and static typing first. For a larger project, you're better off with Rust, Go, or pretty much anything else.