1.deleteԴ?源码?
2.源码解析kafka删除topic
3.Vue2剥丝抽茧-响应式系统之set和delete
4.Hadoop学习之fileSystem.delete方法
5.BoltDB源码解析（七）Put和Delete操作
deleteԴ??
源代码如下：#include<stdio.h>
#include<stdlib.h>
int main(){
int a[5];
int *p=a; //定义一个整型指针变量p,使它指向一个5个元素的一维数组.
int i;
printf("Please input:");
for(i=0;i<5;i++)
scanf("%d",p+i); //使用指针移动的方式,输入5个整型数组元素.
int *q=(int*)malloc(sizeof(int)*5); //malloc函数动态分配5个整型数的地址空间。
printf("Please input:");
for(i=0;i<5;i++)
scanf("%d",源码q+i); //使用数组下标的方式输入5个整型元素。
for(i=0;i<5;i++)
if(p[i]>q[i]){
int t=p[i];
p[i]=q[i];
q[i]=t;
}
for(i=0;i<5;i++) //使用指针p和q分别访问两组数据
printf("%d",源码p[i]);
putchar('\n');
for(i=0;i<5;i++)
printf("%d",q[i]);
putchar('\n');
printf("p=%x\n",p); //分别输出交换后的两组数。
printf("a=%x\n",源码a);
printf("q=%x\n",q);
free(q);
q=NULL;//按十六进制方式输出p、a和q的源码地址。
return 0;
}
运行结果如下：
扩展资料：
指针的源码纯净卡盟源码初始化、动态分配内存的源码方法
指针的初始化
对指针进行初始化或赋值只能使用以下四种类型的值 :
1. 0 值常量表达式，例如,源码在编译时可获得 0 值的整型 const对象或字面值常量 0。
2. 类型匹配的源码对象的地址。
3. 另一对象末的源码下一地址。
4. 同类型的源码另一个有效指针。
把 int 型变量赋给指针是源码非法的,尽管此 int 型变量的值可能为 0。但允
许把数值 0 或在编译时可获得 0 值的源码 const 量赋给指针:
int ival;
int zero = 0;
const int c_ival = 0;
int *pi = ival; // error: pi initialized from int value of ival
pi = zero;// error: pi assigned int value of zero
pi = c_ival;// ok: c_ival is a const with compile-time value of 0
pi = 0;// ok: directly initialize to literal constant 0
除了使用数值 0 或在编译时值为 0 的 const 量外,还可以使用 C++ 语言从 C 语言中继承下来的预处理器变量 NULL，该变量在 cstdlib头文件中定义,源码其值为 0。
如果在代码中使用了这个预处理器变量,源码则编译时会自动被数值 0 替换。因此,把指针初始化为 NULL 等效于初始化为 0 值 [3] :
// cstdlib #defines NULL to 0
int *pi = NULL; // ok: equivalent to int *pi = 0;
动态分配内存的方法
new可用来生成动态无名变量
（1）new可用来生成动态无名变量
如 int *p=new int;
int *p=new int []; //动态数组的大小可以是变量或常量；而一般直接声明数组时，数组大小必须是常量
又如：
int *p1;
double *p2;
p1=new int⑿；
p2=new double [];
l 分别表示动态分配了用于存放整型数据的内存空间，将初值写入该内存空间，并将首地址值返回指针p1；
l 动态分配了具有个双精度实型数组元素的数组，同时将各存储区的首地址指针返回给指针变量p2；
对于生成二维及更高维的数组，应使用多维指针。
以二维指针为例
int **p=new int* [row]; //row是二维数组的行，p是指向一个指针数组的指针
for(int i=0; i<row; i++)
p[i]=new int [col]; //col是二维数组的列，p是指向一个int数组的指针
删除这个二维数组
for(int i = 0; i < row;i++)
delete []p[i]; //先删除二维数组的列
delete []p;
⑵使用完动态无名变量后应该及时释放，要用到 delete 运算符
delete p; //释放单个变量
delete [ ] p;//释放数组变量（不论数组是几维）
相比于一般的变量声明，使用new和delete 运算符可方便的使用变量。
百度百科-指针
百度百科-动态分配内存
源码解析kafka删除topic
本文以kafka0.8.2.2为例，解析如何删除一个topic以及其背后的关键技术和源码实现过程。
删除一个topic涉及两个关键点：配置删除参数以及执行删除操作。
首先，配置参数`delete.topic.enable`为`True`，这是Broker级别的配置，用于指示kafka是否允许执行topic删除操作。
其次，执行命令`bin/kafka-topics.sh --zookeeper zk_host:port/chroot --delete --topic my_topic_name`，此命令指示kafka删除指定的topic。
若未配置`delete.topic.enable`为`True`，topic仅被标记为删除状态，而非立即清除。此时，通常的做法是手动删除Zookeeper中的topic信息和日志，但这仅会清除Zookeeper的vb源码 面部数据，并不会真正清除kafkaBroker内存中的topic数据。因此，最佳做法是配置`delete.topic.enable`为`True`，然后重启kafka。
接下来，我们介绍几个关键类和它们在删除topic过程中的作用。
1. **PartitionStateMachine**：该类代表分区的状态机，决定分区的当前状态及其转移。状态包括：NonExistentPartition、NewPartition、OnlinePartition、OfflinePartition。
2. **ReplicaManager**：负责管理当前机器的所有副本，处理读写、删除等具体操作。读写操作流程包括获取partition对象，再获取Replica对象，接着获取Log对象，并通过其管理的Segment对象将数据写入、读出。
3. **ReplicaStateMachine**：副本的状态机，决定副本的当前状态和状态之间的转移。状态包括：NewReplica、OnlineReplica、OfflineReplica、ReplicaDeletionStarted、ReplicaDeletionSuccessful、ReplicaDeletionIneligible、NonExistentReplica。
4. **TopicDeletionManager**：管理topic删除的状态机，包括发布删除命令、监听并开始删除topic、以及执行删除操作。
在删除topic的过程中，分为四个阶段：客户端执行删除命令、未配置`delete.topic.enable`的流水、配置了`delete.topic.enable`的流水、以及手动删除Zookeeper上topic信息和磁盘数据。
客户端执行删除命令时，会在"/admin/delete_topics"目录下创建topicName节点。
未配置`delete.topic.enable`时，繁星刷源码topic删除流程涉及监听topic删除命令、判断`delete.topic.enable`状态、标记topic为不可删除、以及队列删除topic任务。
配置了`delete.topic.enable`时，额外步骤包括停止删除topic、检查特定条件、更新删除topic集合、激活删除线程、执行删除操作，如解除分区变动监听、清除内存数据结构、删除副本数据、删除Zookeeper节点信息等。
关于手动删除Zookeeper上topic信息和磁盘数据，通常做法是删除Zookeeper的topic相关信息及磁盘数据，但这可能导致部分内存数据未清除。是否会有隐患，需要进一步测试。
总结而言，kafka的topic删除流程基于Zookeeper实现，通过配置参数、执行命令、管理状态机以及清理相关数据，以实现topic的有序删除。正确配置`delete.topic.enable`并执行删除操作是确保topic完全清除的关键步骤。
Vue2剥丝抽茧-响应式系统之set和delete
深入解析 Vue2 源码，理解响应式系统中的 set 和 delete 方法。
首先，数组的set 和 delete 方法并不直接触发组件更新。数组的响应性需要通过数组方法如 push 或 splice 来实现。
若需替换数组元素，可利用 splice 方法间接实现。同时，提供 set 方法供操作，简化数组元素替换流程。
对于对象的 set 方法，Vue2 通过观察对象属性变化触发更新。在 updateComponent 方法中，对象属性未直接参与观察，导致 c 属性非响应式。svn命令源码
通过 set 方法添加响应式属性 c，但 Watcher 未被重新触发。这是因为 c 属性的 Dep 对象在 set 函数中并未收集到相关依赖。解决办法是手动调用 Dep 对象，使 c 属性收集依赖，进而触发 Watcher。
将触发 Watcher 的逻辑整合至 set 函数中，通过修改 Dep 收集所有对象属性的依赖。虽然 a 和 b 属性的依赖被收集，但 c 属性的依赖可能被遗漏。手动执行 Dep 可增加 c 属性收集依赖的机会。
对象的 del 方法则需执行对象的 Dep 来删除属性。由于 Dep 存在于闭包中，无法直接访问，执行对象的 Dep 可实现属性删除的响应式。
综上所述，通过为对象收集依赖，结合 set 和 del 方法，使得数组、对象的修改和删除操作也变为响应式。这不仅增强了 Vue2 的灵活性，也为开发者提供了更为简便的使用体验。
Hadoop学习之fileSystem.delete方法
Hadoop中FileSystem.delete方法用于删除文件或目录。该方法接受两个参数：一个Path，代表要删除的路径；一个布尔值，表示是否进行递归删除。
在源码中，该方法的实现逻辑如下。当指定删除的目标路径为文件时，无论参数recursive为true还是false，方法都能正常执行。而当目标路径为目录时，情况则有所不同。若参数recursive为true，则会递归地删除目录内的所有子文件和子目录，直至目录被空目录所替代，最终被删除。若参数recursive为false，则仅删除空目录，若目录内有文件或子目录，将抛出异常。小说后端源码因此，在使用此方法时，需根据实际情况合理设置参数，避免误删重要文件或目录。
举例说明，若要删除名为"example.txt"的文件，可以这样调用方法：FileSystem.delete(new Path("/path/to/example.txt"), false)。若要删除名为"example"的目录及其内容，调用方法时需设置recursive为true，如：FileSystem.delete(new Path("/path/to/example"), true)。
总结而言，FileSystem.delete方法提供了删除文件或目录的便利功能，通过合理设置参数，可灵活实现不同场景下的删除需求。在实际应用中，需根据目标路径的性质和预期结果，正确使用此方法，以避免不必要的数据丢失或系统异常。
BoltDB源码解析（七）Put和Delete操作
Put和Delete的实现
上一篇文章我们了解了BoltDB的Get API的实现。现在，我们来探讨Put和Delete API的实现：
Put API的主要功能是将一对键值对插入到Bucket中，如果键已经存在，则更新对应的值。首先，进行一些限制条件的检查，例如Put操作是否由写事务发起的，因为Put只能由写事务调用。此外，还需要检查键和值的大小是否符合限制条件。需要注意的是，Put操作和Get操作一样，这里也使用了Cursor来定位键应该放置的位置。
在实际的Put操作中，会调用Cursor的一个不显眼的方法：
这个方法实际上非常有用，它从当前Bucket的B-tree的根节点开始，一直到Cursor定位到的leaf page，为每个page创建一个对应的node结构。当然，如果一个page已经有对应的node，就直接使用它。
为什么要这么做呢？这是因为事务篇中提到的修改操作具有“传染性”，修改B-tree的leaf节点会导致从root到leaf的所有page都需要修改，而BoltDB的修改操作都是在page对应的node里进行的，不是直接在page上修改，因此需要为这些page建立node结构。具体建立node结构的是Bucket的node方法：
Bucket的node方法有两处需要注意，一个是新建的node会被追加到parent node的children中，记录下这些修改的node之间的关系，这个children在node持久化时会有用(node.spill方法)。另一个是node的数据是如何从page中读取的，这是由node的read方法完成的。
node建立好之后，就在要修改的leaf对应的node上调用put方法：
node的put方法相对简单，它是在inodes数组上查找对应的位置，如果exact为true，表示找到了相同的key，直接更新value；如果exact为false，相当于找到了应该插入的位置，然后在对应的inode上记录数据。我们来看一下inodes数组的定义：
inodes数组是node实际存储数据的地方，由多个inode组成，每个不同的key对应一个不同的inode，inode之间是按key排序的。对于leaf节点来说，inode里使用key和value；对于branch节点来说，inode里使用key和pgid，pgid代表一个child page的id。value和pgid不会同时使用。
put方法结束后，当前的Put操作也就结束了。也就是说，Put操作所做的仅仅是把新增或修改的数据放入到它所在的page对应的node内存中。
顺便提一下Delete操作，它和Put操作非常类似，在建立起node结构之后，在对应的node的inodes数组中删除找到的key相等的inode就完成了，这里不再展开。
那么，什么时候会把这些node里的数据持久化到DB文件里呢？是在整个写事务commit的时候。
事务的Commit实现
下面是事务commit的代码简化，保留了重要部分：
Commit的整体流程比较长，下面一点一点进行说明。
tx.root.rebalance()，这个root是root Bucket，rebalance是对root Bucket下所有子Bucket的所有node进行rebalance。这是什么意思？注意node的初始数据虽然来自一个page，但在经历了一些Delete操作后，有些node里面的数据可能过少，这时会先把这个node和它的左兄弟或右兄弟node合并(node的rebalance方法)，合并后node数会减少，但不存在node里数据过少的情况。这个操作对应于B-tree的merge操作，只不过这些node都是Go的内存结构，合并起来非常简单。当然，合并后把这些node spill到page的操作，需要的page总数也会减少。
tx.root.spill()，这个方法是把root Bucket下所有子Bucket的所有node的内容都写入这个事务分配的dirty page里。注意这些dirty page是这个事务临时分配在内存里的，结构和DB文件的page完全一样，但还不是mmap映射的DB的page。
刚开始看到spill这个方法时，感觉它代价有些高，感觉像是把整个B-tree都走了一遍。后来仔细看才发现不是这么回事。这个spill只对有node结构的节点进行处理，那些没修改过的page没有对应的node，根本不会处理。
注意在经过多次Put操作后，node里存放的数据可能出现一个page写不下的情况，比如insert了几千个key value。spill会先把这样的node split成多个大小合适的node(node的split方法)，然后把这些node分别写入不同的page中。这个操作对应于B-tree的split操作。和rebalance方法类似的道理，因为这些node都是Go的内存结构，split起来非常容易。
if tx.meta.pgid > opgid，这个判断是看当前事务需要的page数是否大于事务执行前DB文件有的page数，如果大于，说明DB文件放不下了，就调用db.grow增大文件，以容纳新增的page。
紧接着是freelist的持久化操作，因为写事务可能使用了freelist里的一些page，同时也可能释放了一些page到freelist里，所以freelist很可能发生了变化，需要持久化。
tx.write()，这个方法就是把所有的临时分配的dirty page都写入DB文件对应的page里。
tx.writeMeta()，这个方法是把这个tx里的meta写到meta0或者meta1里面（写事务会交替写这两个meta page，这也是个常用技术，叫ping-pong buffer）。它的代码值得看一下：
首先把meta写到临时分配的buf里，然后用文件IO写到DB文件里，最后调用fdatasync，把OS文件的buffer cache持久化到磁盘上。至此，写事务的所有数据都已经落盘完毕。后面新开启的事务会因为这个meta的txid是最大的，而选择使用这个最新的meta page。而这个meta page包括最新的root bucket，最新的freelist，最新的pgid，这些总体构成了一个DB的最新版本，保证新开启的事务读到最新版本的数据。
看tx.write()和tx.writeMeta()的实现可以发现，写入数据用的是db.ops.writeAt，而这个方法默认值就是File.WriteAt方法，所以实际写入文件用的是文件IO，而不是直接写mmap内存。而BoltDB使用mmap一开始就把mmap映射的内存标记为只读的，压根不允许直接写mmap内存。为什么要这么做呢？
猜测可能是为了安全。前面讲到Get操作为了性能是zero copy的，发现Get返回来的value是mmap上数据的指针，如果mmap设置为可读写的，应用程序代码五花八门，可能会通过指针一不小心修改了mmap上的数据，这样的修改因为走的不是API是无法保证事务的。把mmap设置为只读的消除了这种可能性。反过来说，如果mmap设置为可读写的，Get就不能返回mmap上的指针了，为了安全一定要copy一份数据出来才行，降低了Get的性能。
这里还有个很自然而且很重要的问题是，如果事务commit失败了呢，BoltDB如何保证事务的原子性（ACID的A），确保这个写事务的所有操作，不论是落盘的，还是没落盘的，都不会生效？
原子性要求，不管是commit走到哪一步，哪怕是已经把修改的数据，甚至包括修改的freelist已经落盘，只要最终事务commit失败，都不能对正确性产生任何影响。这里的正确性是指，数据库的状态（有实际的key value数据，freelist， pgid等共同构成）必须是在这个写事务运行之前的状态，数据不能被破坏，这个写事务也不能留下可被后续事务读到的任何更新。
要做到原子性貌似挺难的，因为事务的commit里包括很多步骤，这些步骤都不是原子性的。不过重要的一点是，不论commit运行到哪一步，因为tx.writeMeta是最后一步，只有这一步运行成功commit才算成功，如果说commit失败了，那么tx.writeMeta一定是没运行，或者运行了半截，这个meta page没写完整，机器断电了。总之，这些情况下我们不会得到一个合法的新的meta page(这种情况下meta的validate方法会失败，因为meta的checksum不对)。这时候ping-pong buffer的meta page就起重要的作用了，因为交替写meta page的原因，即使这个写事务新的meta page没写成功，这个写事务运行前版本的meta page还在，而这个meta page包括这个写事务运行前的DB版本所有的状态（kv数据，freelist，pgid等）。这个meta page会被后续事务使用，就像那个失败的写事务从来没有运行过一样。而那个写事务留下的kv数据的page，freelist的page，即使是持久化了，也因为没有写成新的meta，没有机会被用到。
还有个自然的疑问，即使这个失败的写事务写的page因为没有合法的meta无法被引用，不会影响正确性，但无法被引用是不是也意味着这些page无法被回收，浪费了磁盘空间？
答案是也不会。在原来版本的meta里的free list和pgid的共同作用下，这些page会被视为free的，还可以使用，不会出现无法回收这些page的情况。
还有个疑问，既然BoltDB交替写meta0和meta1，是不是连续两个事务commit正好在写meta时失败，数据库就废了？
仔细研究发现，还是没事！因为写事务的txid也是meta的一部分，一个写事务失败，导致txid不会增长，下一次写事务的txid还是一样，meta的交替写是因为txid的变化引起的，既然没变化，就不交替了。所以下一个写事务即使写meta还失败了，也还是写的上一个写事务写的那个meta，不会把两个meta都写坏。
总结一下，ping-pong buffer的meta page真是设计得精巧，是BoltDB达到原子性的关键！
