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.
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.
But since it's not in STL, everyone will use a bit different implementations for something this mundane and common.
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.
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.
To implement a growing allocation , you'll have to create a custom vector, pretty much.
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;
});
vec.map([](int i){
return i*i;
});
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);
}That, however, violates the separation of concerns principle by mangling together data structures and algorithms.
It’s going to be pretty important for us: http://aturon.github.io/2018/04/24/async-borrowing/
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.
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.