6 ms·

So nice to see that attitude. Exceptions, as implemented in C++, turn it into a dynamically typed language. If working with code written by others (libraries, b

• jcelerier 9y ago
  most containers have a "reserve" method which does this. for maps you can use boost's flat_map (ordered) or ska::flat_hash_map (hashed) which both use linear storage that you can reserve. and if for some reason you can't you can still pass your own allocator with preallocated memory, or use boost::pool_allocator
  • 112233 9y ago
    Right. My point was that there is no mechanism to do top level resource allocation, like exceptions do for top level error catching. Allocators are fine, but they are not enough for this, really: // big task will create map<int, int> with 1000 elements MyAllocator a; a.reserveMemory(????); // <-- what to put here? bigtask(a);
    • jcelerier 9y ago
      > My point was that there is no mechanism to do top level resource allocation How could it make sense if bigtask(a) is a separate function, maybe in another DLL / shared object ? Maybe bigtask is not even written in C++ but in C, Rust, D, whatever. Maybe it's not even using malloc but directly OS primitives.
      • 112233 9y ago
        Of course. What I meant is that if I am writing bigtask myself, then preallocating resources for any non-table-like data structure (like map) means I cannot use STL as it is now, even with custom allocators. I have to write custom data structures, or deal with any allocation potentially erroring out.
        • jcelerier 9y ago
          > I cannot use STL as it is now, even with custom allocators. if you are ready to take the runtime hit you could use the polymorphic allocator support and pass your allocator object down the chain. See http://en.cppreference.com/w/cpp/memory/polymorphic_allocator http://en.cppreference.com/w/cpp/memory/polymorphic_allocato... ; http://en.cppreference.com/w/cpp/container/vector http://en.cppreference.com/w/cpp/container/vector ; http://en.cppreference.com/w/cpp/container/map http://en.cppreference.com/w/cpp/container/map . I don't understand why you are making a distinction between table-like and non-table-like containers: both can take allocators. But in general, I don't really understand why you would want to do this: how do you expect your code to differentiate between the containers that you want to be affected by the memory changes and the ones that you don't want to ? If you don't want to make this difference and have a blanket coverage of, say, every std::vector called by your function it means that you cannot use any external library in your function, since other libraries may have other allocation requirements that your code would break. This looks like this would completely break encapsulation. The cleanest thing to do is to do like RapidJSON for instance and just pass allocator objects in your functions : http://rapidjson.org/md_doc_tutorial.html#MoveSemantics http://rapidjson.org/md_doc_tutorial.html#MoveSemantics
          • 112233 9y ago
            > I don't understand why you are making a distinction between table-like and non-table-like containers: both can take allocators. Because for map<> in general I cannot know how much allocations and of what size will it need to store 1000 elements. I might glean it for particular implementation of STL, but not via any api. Doing anything bearssl-like, "No dynamic allocation whatsoever", just does not work with STL. > you cannot use any external library in your function, since other libraries may have other allocation requirements that your code would break. Exactly. Most C++ libraries are not made with the idea of allowing you to police resource allocation. It's malloc all the way.