blocks|key|1464010|text|这可能曾经是真的，但肯定不是更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1464011|只要分配你所需要的内存，当你需要它，并释放它，一旦你完成。|1464012|有太多的程序是挥霍资源的--不要让你的程序成为其中之一。|1464013|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It might have been true once, but it's certainly not better.

Just allocate the memory you need, when you need it and free it up as soon as you've finished.

There are far too many programs that are profligate with resources - don't make yours one of them.

blocks|key|1818422|text|只要给出你需要的确切尺寸。两个大小的电源可能“更好”的唯一原因是允许更快的分配和/或避免内存碎片。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1818423|但是，任何与效率有关的非平凡malloc实现都会在适当的时候以这种方式在内部循环分配。您不需要担心“帮助”malloc；malloc可以自己做得很好。|offset|length|style|CODE|1818424|编辑：|BOLD|1818425|针对您引用的Joel+on+Software文章，Joel在这一节中的观点(如果没有您引用的段落后面的上下文很难正确识别)是，如果您希望频繁地重新分配缓冲区，最好是成倍地重新分配缓冲区，而不是附加的。事实上，这正是std::string和std::vector类在C%2B%2B+(以及其他方面)中所做的。|1818426|这是一个改进的原因并不是因为您通过提供方便的数字来帮助malloc，而是因为内存分配是一项昂贵的操作，并且您试图将所做的次数减少到最低限度。乔尔给出了一个时空权衡的具体例子。他认为，在许多情况下，在需要的内存数量动态变化的情况下，最好是浪费一些空间(通过在每个扩展中分配最多两倍于您所需的空间)，以便节省重复调整精确的n字节所需的时间，每次您需要n更多的字节。|1818427|乘数不一定是2:你可以分配到你所需要的3倍的空间，最后以3的幂分配，或者分配到你所需要的空间的57倍，最后以57的幂分配。分配越多，需要重新分配的次数就越少，但浪费的内存越多。分配两倍的能量，最多是所需内存的两倍，这恰好是一个很好的起点权衡，除非你对自己的需求有更好的了解。|1818428|他顺便提到，这有助于减少“自由链中的分散”，但其原因更多是因为所做拨款的数量和一致性，而不是它们的确切规模。首先，分配和释放内存的次数越多，就越有可能分割堆，而不管分配的大小如何。其次，如果您有多个缓冲区，使用相同的乘法调整算法动态调整大小，那么很可能，如果一个缓冲区的大小为32到64，另一个缓冲区的大小为16到32，那么第二个缓冲区的重新分配就可以与第一个调整算法相匹配。如果一个从25变到60，另一个从16变26，情况就不会是这样了。|1818429|再说一次，如果你只执行一次分配步骤，他所说的都不适用。|1818430|entityMap^0|0|E|6|0|0|3|0|2Z|B|3B|B|0|R|6|4F|1|4T|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@$D|Y|E|Z|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|10|8|@$D|11|E|12|F|J]]|9|@]|A|$]]|$1|K|3|L|5|6|7|13|8|@$D|14|E|15|F|G]|$D|16|E|17|F|G]]|9|@]|A|$]]|$1|M|3|N|5|6|7|18|8|@$D|19|E|1A|F|G]|$D|1B|E|1C|F|G]|$D|1D|E|1E|F|G]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1F|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1G|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1H|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|V|$]]

Just give the exact size you need. The only reason that a power-of-two size might be "better" is to allow quicker allocation and/or to avoid memory fragmentation. 

However, any non-trivial <code>malloc</code> implementation that concerns itself with being efficient will internally round allocations up in this way if and when it is appropriate to do so. You don't need to concern yourself with "helping" malloc; malloc can do just fine on its own.

Edit:

In response to your quote of the Joel on Software article, Joel's point in that section (which is hard to correctly discern without the context that follows the paragraph that you quoted) is that if you are expecting to frequently re-allocate a buffer, it's better to do so multiplicatively, rather than additively. This is, in fact, exactly what the <code>std::string</code> and <code>std::vector</code> classes in C++ (among others) do.

The reason that this is an improvement is not because you are helping out <code>malloc</code> by providing convenient numbers, but because memory allocation is an expensive operation, and you are trying to minimize the number of times you do it. Joel is presenting a concrete example of the idea of a time-space tradeoff. He's arguing that, in many cases where the amount of memory needed changes dynamically, it's better to waste some space (by allocating up to twice as much as you need at each expansion) in order to save the time that would be required to repeatedly tack on exactly <code>n</code> bytes of memory, every time you need <code>n</code> more bytes.

The multiplier doesn't have to be two: you could allocate up to three times as much space as you need and end up with allocations in powers of three, or allocate up to fifty-seven times as much space as you need and end up with allocations in powers of fifty-seven. The more over-allocation you do, the less frequently you will need to re-allocate, but the more memory you will waste. Allocating in powers of two, which uses at most twice as much memory as needed, just happens to be a good starting-point tradeoff until and unless you have a better idea of exactly what your needs are.

He does mention in passing that this helps reduce "fragmentation in the free chain", but the reason for that is more because of the number and uniformity of allocations being done, rather than their exact size. For one thing, the more times you allocate and deallocate memory, the more likely you are to fragment the heap, no matter in what size you're allocating. Secondly, if you have multiple buffers that you are dynamically resizing using the same multiplicative resizing algorithm, then it's likely that if one resizes from 32 to 64, and another resizes from 16 to 32, then the second's reallocation can fit right where the first one used to be. This wouldn't be the case if one resized from 25 to 60 and and the other from 16 to 26.

And again, none of what he's talking about applies if you're going to be doing the allocation step only once.

blocks|key|1818454|text|这完全取决于给定的libc实现malloc(3)。这取决于该实现按照它认为合适的顺序保留堆块。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1818455|回答这个问题--不，不是“更好”(这里所说的“更好”，你的意思是…？)如果您要求的大小太小，malloc(3)会在内部保留更大的块，所以只需保持您的确切大小即可。|1818456|entityMap^0|9|4|F|9|0|1A|9|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|R|8|@]|D|@]|E|$]]]|I|$]]

This is totally dependent on the given <code>libc</code> implementation of <code>malloc(3)</code>. It's up to that implementation to reserve heap chunks in whatever order it sees fit.

To answer the question - no, it's not "better" (here by "better" you mean ...?). If the size you ask for is too small, <code>malloc(3)</code> will reserve bigger chunk internally, so just stick with your exact size.

blocks|key|1464072|text|有点不相干。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1464073|实际上，Malloc分配的内存略多于您的请求，因为它有自己的标头需要处理。因此，最佳存储可能类似于4k-12字节..。但这取决于具体实施情况。|offset|length|style|CODE|1464074|在任何情况下，作为一种优化技术，您没有理由聚集到比您需要的更多的存储。|1464075|entityMap^0|0|1D|5|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

It's somewhat irrelevant.

Malloc actually allocates slightly more memory than you request, because it has it's own headers to deal with. Therefore the optimal storage is probably something like <code>4k-12</code> bytes... but that varies depending on the implementation.

In any case, there is no reason for you to round up to more storage than you need as an optimization technique.

blocks|key|1464107|text|您可以使用来根据处理器的字大小分配内存；任何旧的2的幂都不行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1464108|如果处理器有一个32位字(4个字节)，那么以4个字节为单位分配.按2字节分配可能没有帮助，因为处理器更喜欢从4字节边界开始的数据。|1464109|另一方面，这可能是一种微观优化。大多数内存分配库的设置都是为了返回位于正确位置并将留下最少的碎片的内存。如果您分配了15个字节，库可能会删除并分配16个字节。一些内存分配器根据分配大小有不同的池。|1464110|总之，分配所需的内存量。让分配库/经理为您处理实际金额。在正确性和健壮性上投入更多的精力，而不是担心这些琐碎的问题。|1464111|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

You may want to allocate memory in terms of the processor's word size; not any old power of 2 will do. 

If the processor has a 32-bit word (4 bytes), then allocate in units of 4 bytes. Allocating in terms of 2 bytes may not be helpful since the processor prefers data to start on a 4 byte boundary.

On the other hand, this may be a micro-optimization. Most memory allocation libraries are set up to return memory that is aligned at the correct position and will leave the least amount of fragmentation. If you allocate 15 bytes, the library may pad out and allocate 16 bytes. Some memory allocators have different pools based on the allocation size. 

In summary, allocate the amount of memory that you need. Let the allocation library / manager handle the actual amount for you. Put more energy into correctness and robustness than worry about these trivial issues.

blocks|key|268018|text|以今天的内存数量和速度，我不认为它是相关的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|268019|此外，如果要经常分配内存，最好考虑自定义内存池/预分配。|268020|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|$]]

With today's amount of memory and its speed I don't think it's relevant anymore.

Furthermore, if you're gonna allocate memory frequently you better consider custom memory pooling / pre-allocation.

blocks|key|268048|text|总有测试..。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|268049|您可以尝试一个在循环中分配内存的“示例”程序。通过这种方式，您可以看到编译器是否以2的幂神奇地分配内存。使用这些信息，您可以尝试使用两个策略分配相同数量的总内存:随机大小块和2个大小块的功率。|268050|不过，如果有任何差异的话，我只希望能有大量的内存。|268051|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There is always testing...

You can try a "sample" program that allocates memory in a loop. This way you can see if your compiler magically allocates memory in powers of 2.
With that information, you can try to allocate the same amount of total memory using the 2 strategies: random sized blocks and power of 2 sized blocks.

I would only expect differences, if any, for large amounts of memory though.

blocks|key|268074|text|如果您正在分配某种可扩展的缓冲区，需要为初始分配选择某个数字，那么是的，2的幂是很好的选择。如果您需要为struct分配内存，那么只需要malloc(sizeof(struct+))。对于2级功率分配的建议源于内部碎片的低效率，但是针对多处理器系统的现代malloc实现正在开始使用CPU本地池来分配足够小的分配量，从而防止了当多个线程同时尝试malloc时导致的锁争用，并且由于碎片而花费更多的时间被阻塞。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|268075|通过只分配所需的内容，可以确保数据结构在内存中的填充更加密集，从而提高缓存命中率，这对性能的影响要比内部碎片大得多。有些情况下，使用非常老的malloc实现和非常高端的多处理器系统，显式填充分配可以提供加速，但在这种情况下，您的资源将更好地用于获得一个更好的malloc实现并在该系统上运行。预填充还会降低代码的可移植性，并防止用户或系统在运行时选择malloc行为，无论是以编程方式还是使用环境变量。|268076|过早的优化是万恶之源。|268077|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If you're allocating some sort of expandable buffer where you need to pick some number for initial allocations, then yes, powers of 2 are good numbers to choose. If you need to allocate memory for struct foo, then just malloc(sizeof(struct foo)). The recommendation for power-of-2 allocations stems from the inefficiency of internal fragmentation, but modern malloc implementations intended for multiprocessor systems are starting to use CPU-local pools for allocations small enough for this to matter, which prevents the lock contention that used to result when multiple threads would attempt to malloc at the same time, and spend more time blocked due to fragmentation.

By allocating only what you need, you ensure that data structures are packed more densely in memory, which improves cache hit rate, which has a much bigger impact on performance than internal fragmentation. There exist scenarios with very old malloc implementations and very high-end multiprocessor systems where explicitly padding allocations can provide a speedup, but your resources in that case would be better spent getting a better malloc implementation up and running on that system. Pre-padding also makes your code less portable, and prevents the user or the system selecting the malloc behavior at run-time, either programmatically or with environment variables.

Premature optimization is the root of all evil.

blocks|key|1464265|text|为了扮演魔鬼的提倡者，下面是Qt是如何做到的：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1464266|假设我们在QString字符串中追加了15000个字符。然后，当QString耗尽空间时(在可能的15000中)发生以下18个重新分配:+4、8、12、16、20、52、116、244、500、1012、2036、4084、6132、8180、10228、12276、14324、16372。最后，QString分配了16372个Unicode字符，其中15000个被占用。
上述价值观似乎有点奇怪，但以下是指导原则：
QString一次分配4个字符，直到大小达到20。从20到4084，每次增加一倍。更准确地说，它的下一个幂是2，-+12。(一些内存分配器在请求两个的确切幂时表现最差，因为它们每个块使用几个字节来记账。)从4084开始，它按2048个字符(4096字节)的块前进。这是有意义的，因为现代操作系统在重新分配缓冲区时不会复制整个数据；物理内存页被简单地重新排序，实际上只需要复制第一个和最后一个页面上的数据。|blockquote|style|BOLD|1464267|我喜欢他们在从智能手机到服务器场的代码中预测操作系统特性的方式。考虑到他们比我更聪明，我认为上述特性在所有现代OSes中都可以使用。|1464268|entityMap|0|LINK|mutability|MUTABLE|url|https://doc.qt.io/qt-5/containers.html#growth-strategies^0|E|2|0|0|7K|C|9R|E|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|F|7|W|8|@$A|X|B|Y|G|H]|$A|Z|B|10|G|H]]|9|@]|C|$]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|12|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]]]

Just to play devil's advocate, here's how <a href="https://doc.qt.io/qt-5/containers.html#growth-strategies" rel="nofollow noreferrer">Qt</a> does it:

<blockquote>
 Let's assume that we append 15000
 characters to the QString string. Then
 the following 18 reallocations (out of
 a possible 15000) occur when QString
 runs out of space: 4, 8, 12, 16, 20,
 52, 116, 244, 500, 1012, 2036, 4084,
 6132, 8180, 10228, 12276, 14324,
 16372. At the end, the QString has 16372 Unicode characters allocated,
 15000 of which are occupied.
 
 The values above may seem a bit
 strange, but here are the guiding
 principles:
 
 QString allocates 4 characters at a
 time until it reaches size 20. From 20
 to 4084, it advances by doubling the
 size each time. More precisely, it
 advances to the next power of two,
 minus 12. (Some memory allocators
 perform worst when requested exact
 powers of two, because they use a few
 bytes per block for book-keeping.)
 From 4084 on, it advances by blocks of
 2048 characters (4096 bytes). This
 makes sense because modern operating
 systems don't copy the entire data
 when reallocating a buffer; the
 physical memory pages are simply
 reordered, and only the data on the
 first and last pages actually needs to
 be copied.
</blockquote>

I like the way they anticipate operating system features in code that is meant to perform well from smartphones to server farms. Given that they're smarter people than me, I'd assume that said feature is available in all modern OSes.

blocks|key|1818650|text|在重新分配时，应该使用realloc()而不是malloc()。http://www.cplusplus.com/reference/clibrary/cstdlib/realloc/|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1818651|总是用两个人的力量？这取决于你的程序在做什么。如果你需要重新处理你的整个数据结构，当它增长到2的幂，是的，这是有意义的。否则，只需分配所需的东西，不要占用内存。|1818652|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cplusplus.com/reference/clibrary/cstdlib/realloc/^0|W|1O|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

You should use realloc() instead of malloc() when reallocating.
<a href="http://www.cplusplus.com/reference/clibrary/cstdlib/realloc/" rel="nofollow noreferrer">http://www.cplusplus.com/reference/clibrary/cstdlib/realloc/</a>

Always use a power of two? It depends on what your program is doing. If you need to reprocess your whole data structure when it grows to a power of two, yeah it makes sense. Otherwise, just allocate what you need and don't hog memory.

blocks|key|268172|text|当我分配一个缓冲区时，它可能需要不断增长以容纳尚未确定的大小数据，我以2-+1的幂开始，每次它耗尽空间时，我都会使用以前的大小加1的两倍。这使得我不必担心整数溢出；只有当以前的大小为SIZE_MAX时，大小才会溢出，此时分配就已经失败，2*SIZE_MAX%2B1+==+SIZE_MAX也是如此。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|268173|相反，如果我只使用2的功率，每次增加一倍，我可能会成功地获得一个2%5E31字节的缓冲区，然后在下一次将大小加倍时重新分配到0字节的缓冲区。|268174|正如一些人所评论的那样，对于某些malloc实现来说，功耗为2-负-+12是很好的，我们可以同样地以2-+12的幂开始，然后加倍，然后在每一步中增加12.|268175|另一方面，如果您只是分配不需要增长的小缓冲区，那么就请求您所需的大小。别想猜什么对麦洛克有好处。|268176|entityMap^0|3A|O|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|S|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|M|$]]

When I'm allocating a buffer that may need to keep growing to accommodate as-yet-unknown-size data, I start with a power of 2 minus 1, and every time it runs out of space, I realloc with twice the previous size plus 1. This makes it so I never have to worry about integer overflows; the size can only overflow when the previous size was SIZE_MAX, at which point the allocation would already have failed, and <code>2*SIZE_MAX+1 == SIZE_MAX</code> anyway.

In contrast, if I just used a power of 2 and doubled it each time, I might successfully get a 2^31 byte buffer and then reallocate to a 0 byte buffer next time I doubled the size.

As some people have commented about power-of-2-minus-12 being good for certain malloc implementations, one could equally start with a power of 2 minus 12, then double it and add 12 at each step...

On the other hand if you're just allocating small buffers that won't need to grow, request exactly the size you need. Don't try to second-guess what's good for malloc.

When we use <code>malloc()</code> to allocate memory, should we give the size which is in power of two? Or we just give the exact size that we need?
 Like

<pre><code>//char *ptr= malloc( 200 ); 
char *ptr= malloc( 256 );//instead of 200 we use 256
</code></pre>

If it is better to give size which is in the power of two, what is the reason for that? Why is it better?

Thanks

Edit

The reason of my confusion is following quote from Joel's blog <a href="http://www.joelonsoftware.com/articles/fog0000000319.html" rel="noreferrer">Back to Basics</a>

<blockquote>
 Smart programmers minimize the
 potential distruption of malloc by
 always allocating blocks of memory
 that are powers of 2 in size. You
 know, 4 bytes, 8 bytes, 16 bytes,
 18446744073709551616 bytes, etc. For
 reasons that should be intuitive to
 anyone who plays with Lego, this
 minimizes the amount of weird
 fragmentation that goes on in the free
 chain. Although it may seem like this
 wastes space, it is also easy to see
 how it never wastes more than 50% of
 the space. So your program uses no
 more than twice as much memory as it
 needs to, which is not that big a
 deal.
</blockquote>

Sorry, I should have posted the above quote earlier. My apologies! 

Most replies, so far, say that allocating memory in the power of two is a bad idea, then in which scenario its better to follow Joel's point about <code>malloc()</code>? Why did he say that? Is the above quoted suggestion obsolete now?

Kindly explain it. 
Thanks

Is it better to allocate memory in the power of two?

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

当我们使用malloc()分配内存时，应该给出大小为2的大小吗？还是我们只给出我们需要的尺寸？喜欢//char *ptr= malloc( 200 ); char *ptr= malloc( 256 );//instead of 200 we use 256如果给出两种力量的大小更好，那是什么原因呢？为什么更好？谢谢编...

问用两倍的力量分配内存更好吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用两倍的力量分配内存更好吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用两倍的力量分配内存更好吗？
EN