It has far from "literally" everything. It doesn't have async/await, doesn't have a sane way to create simple web servers, doesn't have map/find/filter/etc on collections, at least not a version that won't span multiple lines or the whole screen because they require mandatory arguments (begin, end) that are useless 99% of the time because you want to operate on the whole collection anyway, etc.

> It doesn't have async/await,

That's just a C# idiom, and far from being the right or sane way to handle concurrency.

Meanwhile C++ has active objects and futures and other concurrency design patterns.

> doesn't have a sane way to create simple web servers

Check POCO.

> doesn't have map/find/filter/etc on collections, at least not a version that won't span multiple lines or the whole screen because they require mandatory arguments (begin, end) that are useless 99% of the time because you want to operate on the whole collection anyway, etc.

That's a very silly complaint. You acknowledge that C++ does have map/find/filter (which at this stage is rather obvious to anyone who ever used C++) but somehow you're complaining that C++'s interfaces require programmers to specify where the collections should start and finnish.

> but somehow you're complaining that C++'s interfaces require programmers to specify where the collections should start and finnish.

I think it is a valid complaint. Most of time you want to apply something like "find" to the whole collection.

I'd also love to have C++ standard maps (esp. unordered_map) where I only pay for what I use. Namely, due to C++ spec I have to pay for the nodes instead of having a flat, CPU cache efficient, buffer. In other words, a different map type where other items are allowed to move in memory when something is inserted or removed.

Oh, while we're at it, it'd be nice if vectors etc. could realloc instead of allocating a completely new memory region and freeing the old one when more space is required.

A more ergonomic allocator story for specifying alternative allocators would also be very nice for some niches, like when you need to avoid fragmentation or require better performance in embedded development.

> I think it is a valid complaint. Most of time you want to apply something like "find" to the whole collection.

frankly, this is a very overstated problem. It's trivial to write a header with such functions (e.g. https://github.com/OSSIA/libossia/blob/master/OSSIA/ossia/de...). And it's already provided by Boost if you use it.

Yeah, it's trivial to do that.

But since it's not in STL, everyone will use a bit different implementations for something this mundane and common.

I'd rather say, (mostly) everybody will use Boost.

Or folly. Or something else. Which leads to the awful package management story. (Maybe modules will help.)

As to mem allocation in vector: https://github.com/facebook/folly/blob/master/folly/docs/FBV...

Memory allocation by STL has been broken for as long as I remember, which is at least twelve years or so. It's been a while but if I remember correctly it doubled its allocation every time it ran out or space.

> It's been a while but if I remember correctly it doubled its allocation every time it ran out or space.

why would you call this "broken" ? That's one of the most optimal solutions for reallocations if you append values continuously, since it will reallocate only logarithmically.

Which libs _don't_ use that allocation strategy? The fact that you think it's broken only means you don't really know what you're talking about.

what? ha, that is the text book approach to reallocating an array for additional values to get log complexity

I'm not so sure I'd want a 2GB vector to grow to 4GB, etc.

In such extreme cases you can (and should) use your own allocation strategy.

Yeah, but I'm not entirely clear how I'd for example get std::vector to use a mmap'ed range, that I could zero-copy grow.

Also in that case I might want to grow it by a fixed amount, once it grows past a certain threshold.

It's a shame one needs to write another vector implementation just for that.

Why wouldn't writing an allocator class be enough for mmap?

Probably not, because the allocators don't expose the "extend" or "realloc" concept, so all you'll see from within your allocator is a request for an entire new region that vector wants in order to copy the new stuff into.

To implement a growing allocation , you'll have to create a custom vector, pretty much.

How would you ensure nothing was used in the region after the original allocation?

O(n^2) time for n push_back calls would be worse, so some sort of multiplication/exponential growth is required for the "fits all" default vector and its default growth strategy.

Old versions of MSVC used a 3/2 growth factor which led to less extreme jumps for large vectors, although also a lot more copies when filling a small vector. I'm not sure if that's still true.

Why not?

I think you mean amortized constant complexity, or O(1).

this is implementation specific. Care to tell which compiler are you talking about?

> That's just a C# idiom

Not just C#, Python and JS also have it already. And async-await is the first time ever where I've thought that yes, this is a good way to do single-threaded async (event-queue-ish) or even multi-threaded things.

> Check POCO.

Thanks for the hint, I will check it out.

> but somehow you're complaining that C++'s interfaces require programmers to specify where the collections should start and finnish.

Take a look at: http://www.modernescpp.com/index.php/higher-order-functions The c++ functions are unnecesarely verbose compared to other languages.

This

    transform(vec.begin(), vec.end(), vec.begin(),[](int i){
        return i*i;
    });

could be much more readable as

    vec.map([](int i){ 
        return i*i;
    });

Also makes for-of the better choice in my opinion because if you're going to write more code, I'd rather write code that is readable.

Those examples aren't really the same though. Transform is a free function which operates on anything that satisfies 'ForwardIterator', map would be a member function of the vector class.

Theoretically you could add helper functions to all suitable containers which calls through to transform (I think this is what you're suggesting). But it would feel very heavyweight and add a lot of cruft to the std library.

You could also add your own utlity free function similar to

  template<class T, class F>
  void mymap(T &t, const F &f){
      std::transform(t.begin(), t.end(), t.begin(), f);
  }

> could be much more readable as vec.map([](int i){ return i*i; });

That, however, violates the separation of concerns principle by mangling together data structures and algorithms.

Rust is also getting async/await

Which de-sugars to generators, which is similar to, but different from, the various C++ coroutine proposals. I haven’t dug into this one yet though...

It’s going to be pretty important for us: http://aturon.github.io/2018/04/24/async-borrowing/

What you want is ranges v3.

That only saves a few characters. And "map" is already a data type in C++. How are you going to explain to a student that ambiguity, that you can "map a vector, but oh yeah map is also this container type" ?

Conceptually, I hate the word "map" to describe a transform. What does a real-world, paper map do? It associates locations drawn on the paper with real-world, physical places. That doesn't have any commonality whatsoever to morphing a group of objects. The term is misused.

It removes enough characters to turn it from unreadable mess to legible code. Point is mainly to remove the 3 completely unnecessary parameters, doesn't matter if it's called transform or map.

> C++ will always have a place because it's a language that literally has (or will have) everything.

I don't think that's true at this stage. Nowadays, beyond legacy code, C++ is used mainly in embedded, number-crunching, and cross-platform GUI applicationd, and that's about it. Meanwhile the world has moved on to web services and web apps, where C++ is nowhere to be seen, and other competing lower-level programming languages are starting to eat away C++'s lunch.

Most of my work is done in Java, .NET and JavaScript, C++ is the only native alternative that I can easily plug into all of them when I need native interop.

Go is not an option until they get their story straight with 2.0.

Swift is nice, but really it will never go beyond being an Apple platform language.

Native/Kotlin is doing its baby steps.

D seemed like a nice alternative, but they are such a small community without any big corporation support, that the language might already have lost its opportunity.

Rust would be the best alternative, but it still lacks the tooling integration story regarding IDE, graphical debuggers and OS vendors support.

Yes, no one is doing pure apps anymore in 100% C++, Java and .NET are slowly migrating to bootstrapped runtimes, but the language is not going away for the foreseeable future.

Kids are learning to program on Arduino devices using C++.

Microsoft already has some ongoing Rust projects, but Visual Rust is not yet here.

AAA Games, compilers specially LLVM and GCC, OS, HPC, Fintech, deep learning, GPGPU shaders, GUI composition engines, IoT, medical devices, car infotainment systems, VFX software might be a niche, but it is a very big niche.

One of the good things about polyglot development is that one doesn't need to silo himself/herself as developer X and be worried if language X is suitable for full stack development across all domains of computing.

EDIT: typos

> Go is not an option until they get their story straight with 2.0

Would you mind expanding on this point? Where I work, we do lot of C++ for the reasons you described but I have started to learn Go to see if its a suitable replacement.

From my point of view, no generics, error handling boilerplate, no real enums (although there is a kind of workaround).

There are other issues regarding tooling, specially for the use cases that I care, like dynamic loading into other platforms (JVM and .NET), GPU programming and graphical debuggers.

So naturally many C++ dev did not felt at home with Go.

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Those pain points are the biggest roadmap points on a possible 2.0 version.

https://blog.golang.org/go2draft

C++ (Rust as well) is for high complexity problems that need high performance solutions. It's not just a few narrow application areas. For example, all major HTML and JS engines are also written in C++. I wouldn't call them (just) GUI applications. I bet that all offline renderers for professional CGI are also C++.

Don't forget high performance games; which is a huge market, highly complex, and very competitive.

It's already written, but things require absolute efficiency and high performance, like HPC and ML cannot be done without C++.

I develop some HPC code, and most of them is infeasible without C++.

Other languages' high performance libraries PIL and numPy is written with C & C++.

NVidia GPUs are now designed explicitly for running C++ code efficiently.

CppCon 2017: Olivier Giroux "Designing (New) C++ Hardware”

https://www.youtube.com/watch?v=86seb-iZCnI

Assuming another systems language, e.g. Rust, does indeed replace C++'s use cases, it is still a very long path until it gets this adoption level from hardware vendors.

>C++ is used mainly in embedded, number-crunching, and cross-platform GUI

You forgot a couple: your OS, your web server, image and video codecs, and basically any other low-ish level abstraction you rely on. The world isn't built on web apps.

I agree with you except that there is sizable chunk of back-end code that is using C++ or at least calling it.