blocks|key|2754458|text|c%2B%2B标准只是说，在用new分配的指针上使用delete[]，在用new[]分配的指针上使用delete是未定义的行为。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2754459|因此，这样做可能会工作，也可能不会，这取决于实现。它可能会让你的房子着火。|2754460|例如，假设这些函数基于使用malloc()和free()的底层缓冲区。|2754461|在大多数实现中，new和delete将使用与项目的大小和地址完全相同的缓冲区(这里是int)|2754462|new[]和delete[]更为复杂。它们不仅必须在缓冲区中存储size项，还必须在缓冲区中存储size的值。实现可以在实际项之前存储size。这意味着基础缓冲区的指针与指向第一项的指针不同，第一项是由new[]返回的值|2754463|混合数组和非数组版本将在无效指针上调用free()，即malloc从未返回的指针。这将崩溃或触发异常|2754464|当然，所有这些都是由实现定义的。|2754465|entityMap^0|B|3|M|8|X|5|1A|6|0|0|0|8|3|C|6|16|3|0|0|5|6|8|W|4|1C|4|1V|4|2T|5|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|12|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|13|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|14|8|@$9|15|A|16|B|C]|$9|17|A|18|B|C]|$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1O|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1P|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|1Q|8|@]|D|@]|E|$]]]|S|$]]

The c++ standard just says that using <code>delete[]</code> on a pointer allocated with <code>new</code>, and using <code>delete</code> on a pointer allocated with <code>new[]</code> is undefined behavior.

So doing this may work, or may not, depending on implementations. It may set your house on fire.

For instance, just suppose that these functions are based on an underlying buffer using malloc() and free().

<code>new</code> and <code>delete</code> will, in most implementations, use a buffer which has exactly the size and address of the item (here an <code>int</code>)

<code>new[]</code> and <code>delete[]</code> are more complex. They must store in the buffer not only <code>size</code> items, but also the value of <code>size</code>. An implementation could store <code>size</code> before the actual items. This would mean that the pointer of the underlying buffer is not the same as the pointer to the first item, which is the value returned by <code>new[]</code>

Mixing array and non array versions would then call free() on invalid pointers, ie pointers that were never returned by malloc. This will crash or trigger an exception

Of course, all this is implementation defined.

blocks|key|2754493|text|int+*a,+*b;
a+=+new+int[10];
b+=+new+int(12);
b+=+a;+//+I+know+there's+memory+leak,+but+let's+ignore+it+first
delete+[]+b;+//+line+L|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|2754494|unstyled|2754495|是否会成功删除整个阵列？|blockquote|2754496|2754497|2754498|是的，由于指针a被设置为指向一个包含10个整数的数组，因此将成功释放内存|offset|length|style|CODE|2754499|a+=+new+int[10];|2754500|然后将相同的内存位置地址存储到b中|2754501|b+=+a;|2754502|因此，delete[]行正确地释放了数组块|2754503|delete+[]+b;|2754504|正如您所说的，代码还会泄漏最初由b分配和指向的整数变量12。|2754505|作为旁注，调用delete[]来释放与数组无关的内存(特别是静态类型不匹配-参见expr.delete/p3)将会触发未定义的行为。|2754506|2754507|现在对于一些内部来说，在分配内存时，大小信息存储在哪里。|2754508|编译器具有一定的自由度(cfr。§5.3.4/10)当涉及到内存分配请求时(例如，它们可以“分组”内存分配请求)。|2754509|在没有提供分配器的情况下调用new时，无论它是否调用malloc，它都是由实现定义的|2754510|new.delete.single|2754511|2754512|执行一个循环:在循环中，函数首先尝试分配请求的存储空间。未指明该尝试是否涉及对标准C库函数malloc的调用。|2754513|2754514|2754515|假设它调用malloc()+(在最近的Windows系统中称为UCRT)，那么尝试分配空间就意味着使用paged+virtual+memory进行记账，而这正是malloc通常所做的。|2754516|您的大小信息将与有关如何分配所请求的内存的其他数据一起传递。|2754517|像glibc这样的C库负责对齐、内存保护和新页面的分配(如果需要)，所以这可能会通过系统调用在内核中结束。|2754518|没有“标准”的方法来从地址获取信息，因为它是一个实现细节。正如许多人所建议的那样，如果你需要这样的信息，你可以|2754519|使用数组类型存储somewhere|2754520|use+sizeof()的大小|unordered-list-item|2754521|
|2754522|更适合C%2B%2B：使用std::vector<>|2754523|2754524|该信息还与内存分配相关联，这两种情况都是次要的(即用L行替换|2754525|b+=+a+%2B+1;+delete+[]+b;|2754526|或|2754527|a%2B%2B;+delete+[]+a;|2754528|将以泪水结束，因为这些地址没有与有效的分配相关联。|2754529|entityMap|0|LINK|mutability|MUTABLE|url|https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/|1|https://en.wikipedia.org/wiki/Virtual_memory#Paged_virtual_memory|2|https://en.wikipedia.org/wiki/GNU_C_Library^0|0|0|0|0|0|7|1|0|0|F|1|0|0|3|8|0|0|G|1|0|7|8|0|0|0|0|E|3|Q|6|0|0|0|0|0|0|5|8|V|4|0|1F|K|1|0|0|1|5|2|0|0|0|4|8|0|0|9|D|0|0|Q|1|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2M|8|@]|9|@]|A|$B|C]]|$1|D|3|-4|5|E|7|2N|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|2O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|E|7|2P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|E|7|2Q|8|@]|9|@]|A|$]]|$1|K|3|L|5|E|7|2R|8|@$M|2S|N|2T|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|2U|8|@]|9|@]|A|$B|C]]|$1|S|3|T|5|E|7|2V|8|@$M|2W|N|2X|O|P]]|9|@]|A|$]]|$1|U|3|V|5|6|7|2Y|8|@]|9|@]|A|$B|C]]|$1|W|3|X|5|E|7|2Z|8|@$M|30|N|31|O|P]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|32|8|@]|9|@]|A|$B|C]]|$1|10|3|11|5|E|7|33|8|@$M|34|N|35|O|P]]|9|@]|A|$]]|$1|12|3|13|5|E|7|36|8|@$M|37|N|38|O|P]]|9|@]|A|$]]|$1|14|3|-4|5|E|7|39|8|@]|9|@]|A|$]]|$1|15|3|16|5|E|7|3A|8|@]|9|@]|A|$]]|$1|17|3|18|5|E|7|3B|8|@]|9|@]|A|$]]|$1|19|3|1A|5|E|7|3C|8|@$M|3D|N|3E|O|P]|$M|3F|N|3G|O|P]]|9|@]|A|$]]|$1|1B|3|1C|5|E|7|3H|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|E|7|3I|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|H|7|3J|8|@]|9|@]|A|$]]|$1|1G|3|-4|5|E|7|3K|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|E|7|3L|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|E|7|3M|8|@$M|3N|N|3O|O|P]]|9|@$M|3P|N|3Q|1|3R]|$M|3S|N|3T|1|3U]]|A|$]]|$1|1K|3|1L|5|E|7|3V|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|E|7|3W|8|@]|9|@$M|3X|N|3Y|1|3Z]]|A|$]]|$1|1O|3|1P|5|E|7|40|8|@]|9|@]|A|$]]|$1|1Q|3|1R|5|E|7|41|8|@]|9|@]|A|$]]|$1|1S|3|1T|5|1U|7|42|8|@$M|43|N|44|O|P]]|9|@]|A|$]]|$1|1V|3|1W|5|E|7|45|8|@]|9|@]|A|$]]|$1|1X|3|1Y|5|1U|7|46|8|@$M|47|N|48|O|P]]|9|@]|A|$]]|$1|1Z|3|-4|5|E|7|49|8|@]|9|@]|A|$]]|$1|20|3|21|5|E|7|4A|8|@$M|4B|N|4C|O|P]]|9|@]|A|$]]|$1|22|3|23|5|6|7|4D|8|@]|9|@]|A|$B|C]]|$1|24|3|25|5|E|7|4E|8|@]|9|@]|A|$]]|$1|26|3|27|5|6|7|4F|8|@]|9|@]|A|$B|C]]|$1|28|3|29|5|E|7|4G|8|@]|9|@]|A|$]]|$1|2A|3|-4|5|E|7|4H|8|@]|9|@]|A|$]]]|2B|$2C|$5|2D|2E|2F|A|$2G|2H]]|2I|$5|2D|2E|2F|A|$2G|2J]]|2K|$5|2D|2E|2F|A|$2G|2L]]]]

<pre><code>int *a, *b;
a = new int[10];
b = new int(12);
b = a; // I know there's memory leak, but let's ignore it first
delete [] b; // line L
</code></pre>

<blockquote>
 Will the entire array be deleted successfully?
</blockquote>

Yes, memory will successfully be freed since the pointer <code>a</code> was set to point to an array of 10 integers

<pre><code>a = new int[10];
</code></pre>

then the same memory location address is stored into <code>b</code>

<pre><code>b = a;
</code></pre>

therefore the <code>delete[]</code> line correctly deallocates the array chunk

<pre><code>delete [] b;
</code></pre>

As you stated the code also leaks the integer variable 12 that was originally allocated and pointed to by <code>b</code>.

As a sidenote calling <code>delete[]</code> to free memory not associated with an array (specifically with a static type mismatch - see [expr.delete]/p3) would have triggered undefined behavior.

<hr>

Now for some internals on where is the size information stored when allocating memory.

Compilers have some degree of freedom (cfr. §5.3.4/10) when it comes to memory allocation requests (e.g. they can "group" memory allocation requests).

When you call <code>new</code> without a supplied allocator, whether it will call <code>malloc</code> or not, it is implementation defined

[new.delete.single]

<blockquote>
 Executes a loop: Within the loop, the function first attempts to allocate the requested storage.
 Whether the attempt involves a call to the Standard C library function malloc is unspecified.
</blockquote>

Assuming it calls <code>malloc()</code> (on recent Windows systems it calls the <a href="https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/" rel="nofollow">UCRT</a>), attempting to allocate space means doing book-keeping with <a href="https://en.wikipedia.org/wiki/Virtual_memory#Paged_virtual_memory" rel="nofollow">paged virtual memory</a>, and that's what malloc usually does.

Your size information gets passed along together with other data on how to allocate the memory you requested.

C libraries like <a href="https://en.wikipedia.org/wiki/GNU_C_Library" rel="nofollow">glibc</a> take care of alignment, memory guards and allocation of a new page (if necessary) so this might end up in the kernel via a system call.

There is no "standard" way to get that info back from the address only since it's an implementation detail. As many have suggested, if you were to need such an info you could

<ul>
<li>store the size somewhere</li>
<li>use <code>sizeof()</code> with an array type</li>
<li>even better for C++: use a <code>std::vector&lt;&gt;</code></li>
</ul>

That info is furthermore associated with a memory allocation, both of your secondary cases (i.e. substituting the <code>L</code> line with 

<pre><code>b = a + 1; delete [] b;
</code></pre>

or

<pre><code>a++; delete [] a;
</code></pre>

will end in tears since those addresses aren't associated with a valid allocation.

For example:

<pre><code>int *a, *b;
a = new int[10];
b = new int(12);
b = a; // I know there's memory leak, but let's ignore it first
delete [] b; // line L
</code></pre>

What will happen? Will the entire array be deleted successfully?

What if line L is replaced by this:
 b = a + 1;
 delete [] b;

Or by this:
 a++;
 delete [] a;

And, lastly, if the length of an dynamic array is associated with the starting address, or in other words, associated with the array itself, do we have any way to get the length of it without using another variable to store the length?

Thanks a lot!

In C++, is the length information of a dynamic array associated with the pointer or the address of the first element?

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

例如：int *a, *b;a = new int[10];b = new int(12);b = a; // I know there's memory leak, but let's ignore it firstdelete [] b; // line L会发生什么呢？是否会成功删除整个阵列？如果将行L替换为:b...

问在C++中，动态数组的长度信息是否与第一个元素的指针或地址相关联？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C++中，动态数组的长度信息是否与第一个元素的指针或地址相关联？EN