{"id":5112,"date":"2017-01-03T10:17:41","date_gmt":"2017-01-03T10:17:41","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/memory-management-with-std-allocator\/"},"modified":"2023-09-18T17:24:14","modified_gmt":"2023-09-18T17:24:14","slug":"memory-management-with-std-allocator","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/memory-management-with-std-allocator\/","title":{"rendered":"Memory Management with std::allocator"},"content":{"rendered":"

What is common between all containers of the Standard Template Library? They have a type parameter Allocator<\/span> that is by default std::allocator<\/span>. The job of the allocator is to manage the lifetime of its elements. That means allocating and deallocating memory for its elements and initializing and destroying them.<\/p>\n

<\/p>\n

 <\/p>\n

I write in this post about the containers of the Standard Template Library, but this includes std::string<\/span>. For simplicity reasons, I will use the term container for both.<\/p>\n

What is special about std<\/span>::allocator<\/span>?<\/p>\n

On the one hand, it makes a difference if std::allocator<\/span> allocates elements for a std::vector<\/span> or pairs of std::map<\/span>. <\/p>\n

<\/p>\n

\n
template<\/span><\n    class<\/span> T<\/span>,\n    class<\/span> Allocator<\/span> = std::allocator<T>\n> class<\/span> vector<\/span>;\n\n\ntemplate<\/span><\n    class<\/span> Key<\/span>,\n    class<\/span> T<\/span>,\n    class<\/span> Compare<\/span> = std::less<Key>,\n    class<\/span> Allocator<\/span> = std::allocator<std::pair<const<\/span> Key, T> >\n> class<\/span> map<\/span>;\n<\/pre>\n<\/div>\n
 <\/p>\n
On the other hand, an allocator needs a bunch of attributes, methods, and functions to do its job.<\/p>\n
The interface<\/h2>\n
<\/p>\n
\n\n\n\n
\n
 1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n 9\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n22\n23\n24\n25<\/pre>\n<\/td>\n
\n
\/\/ Attributes<\/span>\nvalue_type                               T\npointer                                  T*\nconst_pointer                            const<\/span> T*\nreference                                T&\nconst_reference                          const<\/span> T&\nsize_type                                std::size_t<\/span>\ndifference_type                          std::ptrdiff_t<\/span>\npropagate_on_container_move_assignment   std::true_ty\nrebind                                   template<\/span>< class<\/span> U<\/span> > struct<\/span> rebind { typedef<\/span> allocator<U> other; };\nis_always_equal                          std::true_type\n\n\/\/ Methods<\/span>\nconstructor\ndestructor\naddress\nallocate\ndeallocate\nmax_size\nconstruct\ndestroy\n\n\/\/ Functions<\/span>\noperator<\/span>==\noperator<\/span>!=\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
In short, here are the essential members of std::allocator<T><\/span>.<\/p>\n
The inner class template rebind<\/span> (line 10) is one of these important members. Thanks to the class template, you can rebind a std::allocator<\/span> of type T to a type U. The heart of std::allocate<\/span> are the two methods allocate<\/span> (line 17) and deallocate<\/span> (line 18). Both methods manage the memory in which the object is initialized with construct<\/span> (line 20) and destroyed with destroy<\/span> (line 21). The method max_size<\/span> (line 19) returns the maximum number of objects of type T for which std::allocate<\/span> can allocate memory. <\/p>\n
Of course, you can directly use std::allocator<\/span>.<\/p>\n
<\/p>\n
\n\n\n\n
\n
 1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n 9\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n22\n23\n24\n25\n26\n27\n28\n29\n30\n31\n32\n33\n34\n35\n36\n37\n38\n39\n40\n41\n42\n43\n44\n45\n46\n47\n48\n49<\/pre>\n<\/td>\n
\n
\/\/ allocate.cpp<\/span>\n\n#include <memory><\/span>\n#include <iostream><\/span>\n#include <string><\/span>\n \nint<\/span> main(){\n  \n  std::cout << std::endl;\n\n  std::allocator<int<\/span>> intAlloc; \n\n  std::cout << \"intAlloc.max_size(): \"<\/span> << intAlloc.max_size() << std::endl;\n  int<\/span>* intArray = intAlloc.allocate(100);\n\n  std::cout << \"intArray[4]: \"<\/span> << intArray[4] << std::endl;\n \n  intArray[4] = 2011;\n\n  std::cout << \"intArray[4]: \"<\/span> << intArray[4] << std::endl;\n \n  intAlloc.deallocate(intArray, 100);\n\n  std::cout << std::endl;\n \n  std::allocator<double<\/span>> doubleAlloc;\n  std::cout << \"doubleAlloc.max_size(): \"<\/span> << doubleAlloc.max_size() << std::endl;\n  \n  std::cout << std::endl;\n\n  std::allocator<std::string> stringAlloc;\n  std::cout << \"stringAlloc.max_size(): \"<\/span> << stringAlloc.max_size() << std::endl;\n \n  std::string* myString = stringAlloc.allocate(3); \n \n  stringAlloc.construct(myString, \"Hello\"<\/span>);\n  stringAlloc.construct(myString + 1, \"World\"<\/span>);\n  stringAlloc.construct(myString + 2, \"!\"<\/span>);\n \n  std::cout << myString[0] << \" \"<\/span> << myString[1] << \" \"<\/span> << myString[2] << std::endl;\n \n  stringAlloc.destroy(myString);\n  stringAlloc.destroy(myString + 1);\n  stringAlloc.destroy(myString + 2);\n  stringAlloc.deallocate(myString, 3);\n  \n  std::cout << std::endl;\n  \n}\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
I used in the program three allocators. One for an int<\/span> (line 11), one for a double<\/span> (line 26), and one for a std::string<\/span> (line 31). Each allocator knows the maximum number of elements it can allocate (lines 14, 27, and 32).<\/p>\n
Now to the allocator for int: std::allocator<int> intAlloc<\/span> (line 11). With intAlloc<\/span> you can allocate an int<\/span> array of 100 elements (line 14). The access to the 5th element is not defined because, firstly, it has to be initialized. That changes in line 20. Thanks to the call intAlloc.deallocate(intArray, 100)<\/span> (line 22)  I deallocate the memory.  <\/p>\n
The handling of the std::string allocator is more complex. The stringAlloc.construct<\/span> calls in den lines 36 – 38 trigger three constructor calls for std::string.<\/span> The three stringAlloc.destroy<\/span> calls (lines 42 – 44) do the opposite. At the end (line 34), the memory of myString<\/span> is released.<\/p>\n
And now the output of the program.<\/p>\n
\"allocator\"<\/p>\n
C++17<\/h3>\n
With C++17, the interface of std::allocator<\/span> becomes a lot easier to handle. A lot of its members are deprecated.<\/p>\n
<\/p>\n
\n\n\n\n
\n
 1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n 9\n10\n11\n12\n13\n14<\/pre>\n<\/td>\n
\n
\/\/ Attributes<\/span>\nvalue_type                               T\npropagate_on_container_move_assignment   std::true_ty\nis_always_equal                          std::true_type\n\n\/\/ Methods<\/span>\nconstructor\ndestructor\nallocate\ndeallocate\n\n\/\/ Functions<\/span>\noperator<\/span>==\noperator<\/span>!=\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
But the key answer is this post is still missing.<\/p>\n
Why does a container need an allocator?<\/h2>\n
I have three answers.<\/p>\n
    \n
  1. The container should be independent of the underlying memory model<\/strong>. For example, the  Intel Memory Model<\/a> on x86 architectures uses six variants:<\/span>tiny, small, medium, compact, large, <\/span><\/em>and huge<\/em>. I want to stress the point explicitly. I speak from the Intel Memory Model, not the memory model as the base of multithreading.<\/li>\n
  2. The container can separate the memory allocation and deallocation from initializing and destroying their elements<\/strong>. Therefore, a call of vec.reserve(n)<\/span> of a  std::vector vec<\/span> allocates only memory for at least n elements. The constructor for each element will not be executed. (Sven Johannsen<\/strong>)<\/li>\n
  3. You can adjust the allocator of the container precisely to your needs.<\/strong> Therefore, the default allocators are optimized for not-so-frequent memory calls and big memory areas. Under the hood, the C function std::malloc<\/span> will typically be used. Therefore, an allocator using preallocated memory can significantly boost performance. An adjusted allocator also makes a lot of sense if you need a deterministic timing behavior for your program. With the default allocator of a container, you have no guarantee of how long a memory allocation will take. Of course, you can use an adjusted allocator to give you enriched debugging information.  <\/li>\n<\/ol>\n
    What’s next?<\/h2>\n
    Which strategies for requesting memory exist? That’s the question I want to answer in the next post.<\/a><\/span><\/p>\n
     <\/p>\n
     <\/p>\n
     <\/a><\/p>\n
     <\/p>\n
     <\/p>\n","protected":false},"excerpt":{"rendered":"
    What is common between all containers of the Standard Template Library? They have a type parameter Allocator that is by default std::allocator. The job of the allocator is to manage the lifetime of its elements. That means allocating and deallocating memory for its elements and initializing and destroying them.<\/p>\n","protected":false},"author":21,"featured_media":5111,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[364],"tags":[556,498,493],"class_list":["post-5112","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-embedded","tag-allocator","tag-memory","tag-new-delete"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5112","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=5112"}],"version-history":[{"count":2,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5112\/revisions"}],"predecessor-version":[{"id":8287,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5112\/revisions\/8287"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5111"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}