6 ms·
> 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 com
by vardump 8y ago
> 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.
- BurnGpuBurn 8y agoMemory 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.
- NullPrefix 8y agothis is implementation specific. Care to tell which compiler are you talking about?
- jcelerier 8y ago> 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.
- gmadsen 8y agowhat? ha, that is the text book approach to reallocating an array for additional values to get log complexity
- vardump 8y agoI'm not so sure I'd want a 2GB vector to grow to 4GB, etc.
- jhasse 8y agoWhy not?
- dbaupp 8y agoO(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.
- BeeOnRope 8y agoOld 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.
- ChrisSD 8y agoIn such extreme cases you can (and should) use your own allocation strategy.
- vardump 8y agoYeah, 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.
- ChrisSD 8y agoWhy wouldn't writing an allocator class be enough for mmap?
- EpicEng 8y agoWhich 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.
- deleted 8y ago[deleted]
- jcelerier 8y ago> 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/detail/algorithms.hpp https://github.com/OSSIA/libossia/blob/master/OSSIA/ossia/de...). And it's already provided by Boost if you use it.
- vardump 8y agoYeah, 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.
- michal_f 8y agoAs to mem allocation in vector: https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md https://github.com/facebook/folly/blob/master/folly/docs/FBV...