指针与摘引的一角
指针与引用的一角
指针与引用的一角
2011年09月09日
引用通过指针实现是众所周知的事情，但是指针和引用配合使用的时候遇到一个小问题，现记录于下，以供日后参照。
问题的起因：
通过消息传递的系统，在收到消息的时候需要解析消息。最近做了一次修改，把消息结构体里的部分内容删除以后，其中一部分内容改由内存拼接的方式传递。
简而言之，假设消息的名称为message，message之后紧接着一片内存，内存当中存放着有用的信息。而这片内存信息又没有在消息结构当中用成员变量去描述之。
消息的定义struct Message{int mem1; int mem2; int numofmem3; struct Mem3 mem3[1];};
of cs， mem3是个可以动态增长数量的成员，这也是没办法预计Message结构体超出末端的内存地址的原因。因而也无法为超出末端的内存地址起始的隐藏内存信息在message当中正名。我们假设这片内存里存放了若干个Mem4. 当然了Mem4之前是以某一成员变量的形式存在于Message结构体当中的。
问题的表象：
在正式设计好这么一种机制以后，coding出现问题。解Mem4的时候总是出问题，内存乱七八糟。在解决了一系列便宜错位等错误之后，证实相对位置不会出现问题后，头几个Mem4顺利解析，后面的Mem4全部为0.
问题的分析和经过：
略
问题的结果和结论：
经过反复校对内存地址和内存状态，发现问题，很罕见，所以才记了这片日志。
Message消息在收到以后经过若干次倒手，也就是传递。每次传递都是采用引用方式传递的。简单的描述如：Message* pmsg = GetMessage（）；
Handle（*pmsg）//void Handle（Message& msg）;
{
Handle2（msg）//void Handle2（Message& msg）;
}
我们遇到的问题就出在Handle2类似的函数里面。
结论：因为虽然引用通过指针实现，但是毕竟经过一次封装，内部的实现不可预料，这里的引用取地址以后并不是原来的指针存放的地址。经过若干次倒手后，指针地址已经改变，里面还能查出头几个Mem4成员可能是引用传递的对象大小有待考校吧。
指针与引用的一角
2011年09月09日
引用通过指针实现是众所周知的事情，但是指针和引用配合使用的时候遇到一个小问题，现记录于下，以供日后参照。
问题的起因：
通过消息传递的系统，在收到消息的时候需要解析消息。最近做了一次修改，把消息结构体里的部分内容删除以后，其中一部分内容改由内存拼接的方式传递。
简而言之，假设消息的名称为message，message之后紧接着一片内存，内存当中存放着有用的信息。而这片内存信息又没有在消息结构当中用成员变量去描述之。
消息的定义struct Message{int mem1; int mem2; int numofmem3; struct Mem3 mem3[1];};
of cs， mem3是个可以动态增长数量的成员，这也是没办法预计Message结构体超出末端的内存地址的原因。因而也无法为超出末端的内存地址起始的隐藏内存信息在message当中正名。我们假设这片内存里存放了若干个Mem4. 当然了Mem4之前是以某一成员变量的形式存在于Message结构体当中的。
问题的表象：
在正式设计好这么一种机制以后，coding出现问题。解Mem4的时候总是出问题，内存乱七八糟。在解决了一系列便宜错位等错误之后，证实相对位置不会出现问题后，头几个Mem4顺利解析，后面的Mem4全部为0.
问题的分析和经过：
略
问题的结果和结论：
经过反复校对内存地址和内存状态，发现问题，很罕见，所以才记了这片日志。
Message消息在收到以后经过若干次倒手，也就是传递。每次传递都是采用引用方式传递的。简单的描述如：Message* pmsg = GetMessage（）；
Handle（*pmsg）//void Handle（Message& msg）;
{
Handle2（msg）//void Handle2（Message& msg）;
}
我们遇到的问题就出在Handle2类似的函数里面。
结论：因为虽然引用通过指针实现，但是毕竟经过一次封装，内部的实现不可预料，这里的引用取地址以后并不是原来的指针存放的地址。经过若干次倒手后，指针地址已经改变，里面还能查出头几个Mem4成员可能是引用传递的对象大小有待考校吧。