blocks|key|1350270|text|使用自定义分配器来使用内存池而不是堆是很有用的。这只是众多例子中的一个。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350271|对于大多数情况，这肯定是一个过早的优化。但在某些情况下(嵌入式设备、游戏等)，它可能非常有用。|1350272|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It can be useful to use custom allocators to use a memory pool instead of the heap. That's one example among many others.

For most cases, this is certainly a premature optimization. But it can be very useful in certain contexts (embedded devices, games, etc).

blocks|key|1350431|text|我还没有用自定义的STL分配器编写过C%2B%2B代码，但我可以想象一个用C%2B%2B编写的can服务器，它使用一个自定义的分配器自动删除响应HTTP请求所需的临时数据。生成响应后，自定义分配器可以立即释放所有临时数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350432|自定义分配器的另一个可能用例(我已经使用过)是编写一个单元测试，以证明函数的行为不依赖于其输入的某一部分。自定义分配器可以用任何模式填充内存区域。|1350433|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I haven't written C++ code with a custom STL allocator, but I can imagine a webserver written in C++, which uses a custom allocator for automatic deletion of temporary data needed for responding to a HTTP request. The custom allocator can free all temporary data at once once the response has been generated.

Another possible use case for a custom allocator (which I have used) is writing a unit test to prove that that a function's behavior doesn't depend on some part of its input. The custom allocator can fill up the memory region with any pattern.

blocks|key|1350550|text|正如我提到的here，我已经看到Intel+TBB的自定义STL分配器通过简单地更改单个|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1350551|std::vector<T>|code-block|syntax|javascript|1350552|至|1350553|std::vector<T,tbb::scalable_allocator<T>+>|1350554|(这是一种将分配器切换为使用TBB漂亮的线程私有堆的快速方便的方法；请参阅page+7+in+this+document)|1350555|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/657783/how-does-intel-tbbs-scalableallocator-work|1|http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=A2FFF3D179B57EC23B9656993289BE8F?doi=10.1.1.71.8289&rep=rep1&type=pdf^0|6|4|0|0|0|0|0|11|N|1|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|F|7|12|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|13|8|@]|9|@]|C|$]]|$1|K|3|L|5|F|7|14|8|@]|9|@]|C|$G|H]]|$1|M|3|N|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|O|3|-4|5|6|7|19|8|@]|9|@]|C|$]]]|P|$Q|$5|R|S|T|C|$U|V]]|W|$5|R|S|T|C|$U|X]]]]

As I mention <a href="https://stackoverflow.com/questions/657783/how-does-intel-tbbs-scalableallocator-work">here</a>, I've seen Intel TBB's custom STL allocator significantly improve performance of a multithreaded app simply by changing a single 

<pre><code>std::vector&lt;T&gt;
</code></pre>

to 

<pre><code>std::vector&lt;T,tbb::scalable_allocator&lt;T&gt; &gt;
</code></pre>

(this is a quick and convenient way of switching the allocator to use TBB's nifty thread-private heaps; see <a href="http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=A2FFF3D179B57EC23B9656993289BE8F?doi=10.1.1.71.8289&amp;rep=rep1&amp;type=pdf" rel="noreferrer">page 7 in this document</a>)

blocks|key|1350598|text|我正在使用一个使用c%2B%2B作为代码的MySQL存储引擎。我们使用一个自定义分配器来使用MySQL内存系统，而不是与MySQL竞争内存。它允许我们确保使用内存作为用户配置的MySQL使用，而不是“额外”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350599|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'm working with a MySQL storage engine that uses c++ for its code. We're using a custom allocator to use the MySQL memory system rather than competing with MySQL for memory. It allows us to make sure we're using memory as the user configured MySQL to use, and not "extra".

blocks|key|1350678|text|自定义分配器可能有用的一个领域是游戏开发，特别是在游戏控制台上，因为它们只有少量的内存并且没有交换空间。在这样的系统上，您需要确保对每个子系统都有严格的控制，这样一个非关键的系统就不能从一个关键的系统中窃取内存。其他东西，如池分配器，可以帮助减少内存碎片。您可以在以下位置找到一篇关于该主题的长篇、详细的论文：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350679|EASTL+--+Electronic+Arts+Standard+Template+Library|offset|length|1350680|entityMap|0|LINK|mutability|MUTABLE|url|http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html^0|0|0|1E|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

One area where custom allocators can be useful is game development, especially on game consoles, as they have only a small amount of memory and no swap. On such systems you want to make sure that you have tight control over each subsystem, so that one uncritical system can't steal the memory from a critical one. Other things like pool allocators can help to reduce memory fragmentation. You can find a long, detailed paper on the topic at:

<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html" rel="noreferrer">EASTL -- Electronic Arts Standard Template Library</a>

blocks|key|1350740|text|我正在使用一个自定义分配器来计算我的程序的一部分中的分配/释放的数量，并测量它需要多长时间。还有其他方法可以实现这一点，但这种方法对我来说非常方便。特别有用的是，我可以只对我的容器的一个子集使用自定义分配器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350741|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I am using a custom allocator for counting the number of allocations/deallocations in one part of my program and measuring how long it takes. There are other ways this could be achieved but this method is very convenient for me. It is especially useful that I can use the custom allocator for only a subset of my containers.

blocks|key|1350809|text|我正在开发一个mmap-allocator，它允许向量使用内存映射文件中的内存。我们的目标是让使用存储的向量通过mmap直接映射到虚拟内存中。我们的问题是提高读取非常大的文件(>10+is+)到内存而没有复制开销，因此我需要这个自定义分配器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350810|到目前为止，我已经有了自定义分配器的框架(它是从std：：allocator派生的)，我认为这是编写自己的分配器的一个很好的起点。请随意以您想要的方式使用这段代码：|1350811|#include+<memory>
#include+<stdio.h>

namespace+mmap_allocator_namespace
{
++++++++//+See+StackOverflow+replies+to+this+answer+for+important+commentary+about+inheriting+from+std::allocator+before+replicating+this+code.
++++++++template+<typename+T>
++++++++class+mmap_allocator:+public+std::allocator<T>
++++++++{
public:
++++++++++++++++typedef+size_t+size_type;
++++++++++++++++typedef+T*+pointer;
++++++++++++++++typedef+const+T*+const_pointer;

++++++++++++++++template<typename+_Tp1>
++++++++++++++++struct+rebind
++++++++++++++++{
++++++++++++++++++++++++typedef+mmap_allocator<_Tp1>+other;
++++++++++++++++};

++++++++++++++++pointer+allocate(size_type+n,+const+void+*hint=0)
++++++++++++++++{
++++++++++++++++++++++++fprintf(stderr,+"Alloc+%25d+bytes.\n",+n*sizeof(T));
++++++++++++++++++++++++return+std::allocator<T>::allocate(n,+hint);
++++++++++++++++}

++++++++++++++++void+deallocate(pointer+p,+size_type+n)
++++++++++++++++{
++++++++++++++++++++++++fprintf(stderr,+"Dealloc+%25d+bytes+(%25p).\n",+n*sizeof(T),+p);
++++++++++++++++++++++++return+std::allocator<T>::deallocate(p,+n);
++++++++++++++++}

++++++++++++++++mmap_allocator()+throw():+std::allocator<T>()+{+fprintf(stderr,+"Hello+allocator!\n");+}
++++++++++++++++mmap_allocator(const+mmap_allocator+&a)+throw():+std::allocator<T>(a)+{+}
++++++++++++++++template+<class+U>++++++++++++++++++++
++++++++++++++++mmap_allocator(const+mmap_allocator+&a)+throw():+std::allocator<T>(a)+{+}
++++++++++++++++~mmap_allocator()+throw()+{+}
++++++++};
}|code-block|syntax|javascript|1350812|要使用它，请声明一个STL容器，如下所示：|1350813|using+namespace+std;
using+namespace+mmap_allocator_namespace;

vector<int,+mmap_allocator<int>+>+int_vec(1024,+0,+mmap_allocator<int>());|1350814|例如，它可以用来在分配内存时进行日志记录。必需的是重新绑定结构，否则向量容器使用超类分配/释放方法。|1350815|更新:内存映射分配器现在可以在https://github.com/johannesthoma/mmap_allocator上使用，并且是LGPL。你可以在你的项目中使用它。|offset|length|1350816|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/johannesthoma/mmap_allocator^0|0|0|0|0|0|0|F|1B|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|12|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|13|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|16|8|@]|9|@$Q|17|R|18|1|19]]|A|$]]|$1|S|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

I am working on a mmap-allocator that allows vectors to use memory from
a memory-mapped file. The goal is to have vectors that use storage that 
are directly in the virtual memory mapped by mmap. Our problem is to 
improve reading of really large files (>10GB) into memory with no copy
overhead, therefore I need this custom allocator.

So far I have the skeleton of a custom allocator
(which derives from std::allocator), I think it is a good starting 
point to write own allocators. Feel free to use this piece of code
in whatever way you want:

<pre><code>#include &lt;memory&gt;
#include &lt;stdio.h&gt;

namespace mmap_allocator_namespace
{
 // See StackOverflow replies to this answer for important commentary about inheriting from std::allocator before replicating this code.
 template &lt;typename T&gt;
 class mmap_allocator: public std::allocator&lt;T&gt;
 {
public:
 typedef size_t size_type;
 typedef T* pointer;
 typedef const T* const_pointer;

 template&lt;typename _Tp1&gt;
 struct rebind
 {
 typedef mmap_allocator&lt;_Tp1&gt; other;
 };

 pointer allocate(size_type n, const void *hint=0)
 {
 fprintf(stderr, "Alloc %d bytes.\n", n*sizeof(T));
 return std::allocator&lt;T&gt;::allocate(n, hint);
 }

 void deallocate(pointer p, size_type n)
 {
 fprintf(stderr, "Dealloc %d bytes (%p).\n", n*sizeof(T), p);
 return std::allocator&lt;T&gt;::deallocate(p, n);
 }

 mmap_allocator() throw(): std::allocator&lt;T&gt;() { fprintf(stderr, "Hello allocator!\n"); }
 mmap_allocator(const mmap_allocator &amp;a) throw(): std::allocator&lt;T&gt;(a) { }
 template &lt;class U&gt; 
 mmap_allocator(const mmap_allocator&lt;U&gt; &amp;a) throw(): std::allocator&lt;T&gt;(a) { }
 ~mmap_allocator() throw() { }
 };
}
</code></pre>

To use this, declare an STL container as follows:

<pre><code>using namespace std;
using namespace mmap_allocator_namespace;

vector&lt;int, mmap_allocator&lt;int&gt; &gt; int_vec(1024, 0, mmap_allocator&lt;int&gt;());
</code></pre>

It can be used for example to log whenever memory is allocated. What is neccessary
is the rebind struct, else the vector container uses the superclasses allocate/deallocate
methods.

Update: The memory mapping allocator is now available at <a href="https://github.com/johannesthoma/mmap_allocator" rel="noreferrer">https://github.com/johannesthoma/mmap_allocator</a> and is LGPL. Feel free to use it for your projects.

blocks|key|1350917|text|我个人使用Loki::Allocator+/+SmallObject来优化小对象的内存使用-如果你必须处理中等数量的非常小的对象(1到256字节)，它会显示出良好的效率和令人满意的性能。如果我们讨论分配适量的许多不同大小的小对象，那么它的效率可以比标准的C%2B%2B新/删除分配高出约30倍。此外，有一个VC特定的解决方案称为"QuickHeap"，它带来了最好的性能(分配和释放操作分别读取和写入被分配/返回到堆的块的地址，分别高达99。(9)%25的情况-取决于设置和初始化)，但以显著的开销为代价-它需要每个扩展区两个指针，每个新内存块需要一个额外的指针。如果您不需要大量的对象大小(在当前实现中，它为每个对象大小创建一个单独的池，从1到1023字节，因此初始化成本可能会降低整体性能提升，但您可以在应用程序进入其性能关键阶段之前分配/释放一些虚拟对象)，那么对于处理大量(10+000%2B%2B)正在创建和删除的对象来说，这是最快的解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350918|标准的C%2B%2B新/删除实现的问题是，它通常只是C+malloc/free分配的包装器，并且它适用于更大的内存块，比如1024%2B字节。它在性能方面有显著的开销，有时还会有额外的内存用于映射。因此，在大多数情况下，实现自定义分配器的方式是为了最大化性能和/或最小化分配小对象(≤1024字节)所需的额外内存量。|1350919|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I personally use Loki::Allocator / SmallObject to optimize memory usage for small objects — it show good efficiency and satisfying performance if you have to work with moderate amounts of really small objects (1 to 256 bytes). It can be up to ~30 times more efficient than standard C++ new/delete allocation if we talk about allocating moderate amounts of small objects of many different sizes. Also, there's a VC-specific solution called "QuickHeap", it brings best possible performance (allocate and deallocate operations just read and write the address of the block being allocated/returned to heap, respectively in up to 99.(9)% cases — depends on settings and initialization), but at a cost of a notable overhead — it needs two pointers per extent and one extra for each new memory block. It's a fastest possible solution for working with huge (10 000++) amounts of objects being created and deleted if you don't need a big variety of object sizes (it creates an individual pool for each object size, from 1 to 1023 bytes in current implementation, so initialization costs may belittle the overall performance boost, but one can go ahead and allocate/deallocate some dummy objects before the application enters it's performance-critical phase(s)). 

The issue with the standard C++ new/delete implementation is that it's usually just a wrapper for C malloc/free allocation, and it works good for larger blocks of memory, like 1024+ bytes. It has a notable overhead in terms of performance and, sometimes, extra memory used for mapping too. So, in most cases custom allocators are implemented in a way to maximize the performance and/or minimize the amount of extra memory needed for allocating small (≤1024 bytes) objects.

blocks|key|1350998|text|对于共享内存，不仅容器头，而且它包含的数据都存储在共享内存中，这一点至关重要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350999|Boost::Interprocess的分配器就是一个很好的例子。然而，正如你可以读到的那样，这一切还不足以使所有here容器共享内存兼容(由于不同进程中不同的映射偏移量，指针可能会“中断”)。|offset|length|1351000|entityMap|0|LINK|mutability|MUTABLE|url|http://www.boost.org/doc/libs/1_50_0/doc/html/interprocess/quick_guide.html#interprocess.quick_guide.qg_interprocess_container|1|http://www.boost.org/doc/libs/1_50_0/doc/html/interprocess/allocators_containers.html#interprocess.allocators_containers.containers_explained.containers^0|0|0|J|0|1L|4|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]|$D|U|E|V|1|W]]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]|N|$5|I|J|K|A|$L|O]]]]

For shared memory it is vital that not only the container head, but also the data it contains are stored in shared memory.

The allocator of <a href="http://www.boost.org/doc/libs/1_50_0/doc/html/interprocess/quick_guide.html#interprocess.quick_guide.qg_interprocess_container" rel="nofollow">Boost::Interprocess</a> is a good example. However, as you can read <a href="http://www.boost.org/doc/libs/1_50_0/doc/html/interprocess/allocators_containers.html#interprocess.allocators_containers.containers_explained.containers" rel="nofollow">here</a> this allone does not suffice, to make all STL containers shared memory compatible (Due to different mapping offsets in different processes, pointers might "break").

blocks|key|1351114|text|我曾经使用过的一个例子是使用资源非常有限的嵌入式系统。假设你有2k的内存可用，你的程序必须使用其中的一些内存。你需要在堆栈之外的地方存储4-5个序列，另外你需要非常精确地访问这些东西的存储位置，这是一种你可能想要编写自己的分配器的情况。默认的实现会使内存碎片化，如果你没有足够的内存并且不能重启你的程序，这可能是不可接受的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1351115|我正在做的一个项目是在一些低功耗芯片上使用AVR-GCC。我们必须存储8个可变长度的序列，但有一个已知的最大值。standard+library+implementation+of+the+memory+management是围绕malloc/free的一个薄包装器，它通过在每个已分配的内存块前添加一个指针，指向刚刚超过该已分配内存块的末尾，从而跟踪项目的放置位置。当分配一个新的内存块时，标准分配器必须遍历每个内存块，以找到下一个可用块，其中可以容纳所请求的内存大小。在桌面平台上，对于这几个项目来说，这将是非常快的，但您必须记住，与之相比，这些微控制器中的一些非常慢和原始。此外，内存碎片问题是一个巨大的问题，这意味着我们真的别无选择，只能采取不同的方法。|offset|length|1351116|所以我们所做的就是实现我们自己的memory+pool。每个内存块都足够大，可以容纳我们需要的最大序列。这提前分配了固定大小的内存块，并标记了当前正在使用的内存块。我们通过保留一个8位整数来做到这一点，其中每一位都表示是否使用了某个块。我们在这里牺牲了内存使用，试图让整个过程更快，在我们的例子中，这是合理的，因为我们正在推动这个微控制器芯片接近它的最大处理能力。|1351117|我还可以看到在嵌入式系统的上下文中编写自己的自定义分配器的其他许多情况，例如，如果序列的内存不在主ram中，就像在these+platforms上经常发生的情况一样。|1351118|entityMap|0|LINK|mutability|MUTABLE|url|http://www.nongnu.org/avr-libc/user-manual/malloc.html|1|https://en.wikipedia.org/wiki/Memory_pool|2|https://en.wikipedia.org/wiki/Modified_Harvard_architecture^0|0|1K|1K|0|0|G|B|1|0|1L|F|2|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]]|A|$]]|$1|H|3|I|5|6|7|14|8|@]|9|@$D|15|E|16|1|17]]|A|$]]|$1|J|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]|T|$5|M|N|O|A|$P|U]]]]

One example of I time I have used these was working with very resource constrained embedded systems. Lets say you have 2k of ram free and your program has to use some of that memory. You need to store say 4-5 sequences somewhere that's not on the stack and additionally you need to have very precise access over where these things get stored, this is a situation where you might want to write your own allocator. The default implementations can fragment the memory, this might be unacceptable if you don't have enough memory and cannot restart your program.

One project I was working on was using AVR-GCC on some low powered chips. We had to store 8 sequences of variable length but with a known maximum. The <a href="http://www.nongnu.org/avr-libc/user-manual/malloc.html" rel="nofollow">standard library implementation of the memory management</a> is a thin wrapper around malloc/free which keeps track of where to place items with by prepending every allocated block of memory with a pointer to just past the end of that allocated piece of memory. When allocating a new piece of memory the standard allocator has to walk over each of the pieces of memory to find the next block that is available where the requested size of memory will fit. On a desktop platform this would be very fast for this few items but you have to keep in mind that some of these microcontrollers are very slow and primitive in comparison. Additionally the memory fragmentation issue was a massive problem that meant we really had no choice but to take a different approach.

So what we did was to implement our own <a href="https://en.wikipedia.org/wiki/Memory_pool" rel="nofollow">memory pool</a>. Each block of memory was big enough to fit the largest sequence we would need in it. This allocated fixed sized blocks of memory ahead of time and marked which blocks of memory were currently in use. We did this by keeping one 8 bit integer where each bit represented if a certain block was used. We traded off memory usage here for attempting to make the whole process faster, which in our case was justified as we were pushing this microcontroller chip close to it's maximum processing capacity.

There's a number of other times I can see writing your own custom allocator in the context of embedded systems, for example if the memory for the sequence isn't in main ram as might frequently be the case on <a href="https://en.wikipedia.org/wiki/Modified_Harvard_architecture" rel="nofollow">these platforms</a>.

blocks|key|1351178|text|Andrei+Alexandrescu关于分配器的CppCon+2015演讲的必备链接：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1351179|https://www.youtube.com/watch?v=LIb3L4vKZ7U|offset|length|1351180|好的事情是，仅仅是设计它们就会让你思考如何使用它们:-)|1351181|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|17|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

Obligatory link to Andrei Alexandrescu's CppCon 2015 talk on allocators:

<a href="https://www.youtube.com/watch?v=LIb3L4vKZ7U" rel="noreferrer">https://www.youtube.com/watch?v=LIb3L4vKZ7U</a>

The nice thing is that just devising them makes you think of ideas of how you would use them :-)

blocks|key|1566725|text|不久前，我发现这个解决方案对我非常有用：Fast+C%2B%2B11+allocator+for+STL+containers。它在VS2017上(~5倍)和在GCC上(~7倍)略微加速了STL容器。它是一个基于内存池的专用分配器。它只能与STL容器一起使用，这要归功于您所要求的机制。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1566726|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/moya-lang/Allocator^0|K|13|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Sometime ago I found this solution very useful to me: <a href="https://github.com/moya-lang/Allocator" rel="nofollow noreferrer">Fast C++11 allocator for STL containers</a>. It slightly speeds up STL containers on VS2017 (~5x) as well as on GCC (~7x). It is a special purpose allocator based on memory pool. It can be used with STL containers only thanks to the mechanism you are asking for.

blocks|key|1566785|text|自定义分配器是在释放内存之前安全擦除内存的一种合理方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1566786|template+<class+T>
class+allocator
{
public:
++++using+value_type++++=+T;

++++allocator()+noexcept+{}
++++template+<class+U>+allocator(allocator+const&)+noexcept+{}

++++value_type*++//+Use+pointer+if+pointer+is+not+a+value_type*
++++allocate(std::size_t+n)
++++{
++++++++return+static_cast<value_type*>(::operator+new+(n*sizeof(value_type)));
++++}

++++void
++++deallocate(value_type*+p,+std::size_t)+noexcept++//+Use+pointer+if+pointer+is+not+a+value_type*
++++{
++++++++OPENSSL_cleanse(p,+n);
++++++++::operator+delete(p);
++++}
};
template+<class+T,+class+U>
bool
operator==(allocator<T>+const&,+allocator+const&)+noexcept
{
++++return+true;
}
template+<class+T,+class+U>
bool
operator!=(allocator<T>+const&+x,+allocator+const&+y)+noexcept
{
++++return+!(x+==+y);
}|code-block|syntax|javascript|1566787|推荐使用由Hinnant提供的分配器样板：https://howardhinnant.github.io/allocator_boilerplate.html)|offset|length|1566788|entityMap|0|LINK|mutability|MUTABLE|url|https://howardhinnant.github.io/allocator_boilerplate.html^0|0|0|L|1M|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@$I|V|J|W|1|X]]|A|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

A custom allocator is a reasonable way to securely erase memory before it is deallocated.
<pre><code>template &lt;class T&gt;
class allocator
{
public:
 using value_type = T;

 allocator() noexcept {}
 template &lt;class U&gt; allocator(allocator&lt;U&gt; const&amp;) noexcept {}

 value_type* // Use pointer if pointer is not a value_type*
 allocate(std::size_t n)
 {
 return static_cast&lt;value_type*&gt;(::operator new (n*sizeof(value_type)));
 }

 void
 deallocate(value_type* p, std::size_t) noexcept // Use pointer if pointer is not a value_type*
 {
 OPENSSL_cleanse(p, n);
 ::operator delete(p);
 }
};
template &lt;class T, class U&gt;
bool
operator==(allocator&lt;T&gt; const&amp;, allocator&lt;U&gt; const&amp;) noexcept
{
 return true;
}
template &lt;class T, class U&gt;
bool
operator!=(allocator&lt;T&gt; const&amp; x, allocator&lt;U&gt; const&amp; y) noexcept
{
 return !(x == y);
}
</code></pre>
Recommend using allocator boilerplate by Hinnant:
<a href="https://howardhinnant.github.io/allocator_boilerplate.html" rel="nofollow noreferrer">https://howardhinnant.github.io/allocator_boilerplate.html</a>)

What are some really good reasons to ditch <code>std::allocator</code> in favor of a custom solution? Have you run across any situations where it was absolutely necessary for correctness, performance, scalability, etc? Any really clever examples?

Custom allocators have always been a feature of the Standard Library that I haven't had much need for. I was just wondering if anyone here on SO could provide some compelling examples to justify their existence.

Compelling examples of custom C++ allocators?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有什么真正好的理由抛弃std::allocator，转而使用定制的解决方案？您是否遇到过为了正确性、性能、可伸缩性等而绝对需要它的情况？有什么非常聪明的例子吗？自定义分配器一直是标准库的一个特性，但我并没有太多的需求。我只是想知道这里是否有人能提供一些令人信服的例子来证明它们的存在。

问定制C++分配器的令人信服的例子？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问定制C++分配器的令人信服的例子？EN