月份：2016年4月

C++默认构造函数

在C++中，如果不为某个struct/class实现一个构造函数，那么编译器就会自动为这个类添加一个默认构造函数，而这个默认构造函数什么也不干。

但是我却从来不知道，默认构造函数在不同的情况下，会出现不一样的效果（当然这是C++03之后的标准).

先看一段代码:

struct test {
int a;
int b;
};


void *operator new(size_t sz)
{
void *p = malloc(sz);
for (size_t i = 0; i < sz; i++)
((char *)p)[i] = 0x01;
return p;
}
int main()
{
struct test *t1 = new test;
struct test *t2 = new test();
printf("t1:%x-%x\n", t1->a, t1->b);
printf("t2:%x-%x\n", t2->a, t2->b);
return 0;
}

重载new操作符是为了把分配出来的内存弄脏。然后观察new test和new test()的区别。

结果出人意料，t1的值就是内存中被污染的值，然后t2的值却全部被清0，而造成这种现象的惟一的区别就是new之后类型是否带有括号。

这就是C++03版本的新增内容，当没有实现构造函数时，编译器为你自动生成的构造函数是有两种用途的。当你在使用new T()构造对象时，默认的构造函数会对各变量执行清0操作，其实应该就是memset为0. 而在使用new T来构造对象时，其默认构造函数是任何事也不做的。

总觉得这么做违背了语言的一致性的设计， 但是不管怎么说有了这个，在写struct定义时在一定的情况下就可以省掉默认构造函数了。

迭代器模式

在写C++代码时，首先接触的就是迭代器。甚至于设计模式都有一种模式叫迭代器模式。虽说网上到处都说迭代器用于隐藏数据结构的细节，但我却一直没有真正搞明白为什么需要迭代器去隐藏数据结构细节。

在写C++代码时，一般我每用一个数据结构都会去查一下，他大致是如何实现的（不然用起来不太放心:D)。

因此一般情况下我在c++下都是使用类似类似for(size_t i = 0; i < vector.size(); i++)的方式去遍历vector的每个元素。

直到最近的一次重构我才大概明白什么时候去使用迭代器模式。

首先大致说一下zproto的作用。

zproto是一个序列化/反序列化的工具，类似google protobuf，但是实现更简单，更轻量级。

在实现之初，我是希望zproto.c可以实现syntax和serialize/unserialize的核心功能，然后再为每种不同的语言写一组操作本语言数据结构的函数，即可通过zproto.c来实现bind功能。但我又不想做成callback接口。

由于zproto所有字段都是可选的，因此某一字段可能是不存在的，在encode和decode时，zproto.c必须知道上一次有效的字段是哪一个。

因此接口就变成了这个样子：

void zproto_encode_tag(struct zproto_buffer *zb, struct zproto_field *last,
struct zproto_field *field, int32_t count);
void zproto_encode(struct zproto_buffer *zb, struct zproto_field *last,
struct zproto_field *field, const char *data, int32_t sz);
struct zproto_field *zproto_decode_tag(struct zproto_buffer *zb, struct zproto_field *last,
struct zproto_record *proto, int32_t *sz);

从接口就可以看出，在写bind代码时，每次都需要维护上一个有效有字段，这其实从一定程度上暴漏了zproto.c作为core的实现细节而且加重了写bind代码的负担，这一度让我觉得很恶心。

几次想把last放入zproto_buffer字段中，但这样就需要在zproto_buffer中维护一个栈的结构，因为record(结构体）中有field(字段），field又可能是record类型。 这样一来就增加了实现复杂度，与我的初衷不符。因此也就迟迟没有动手。

直到最近在一次写C++的代码时，再一次用到迭代器(遍历map中的所值)时，突然觉得这个问题可以用迭代器来解决。

使用迭代器实现后的接口如下：

void zproto_encode_array(struct zproto_buffer *zb, struct zproto_field_iter *iter,
int32_t count);
void zproto_encode(struct zproto_buffer *zb, struct zproto_field_iter *iter,
const char *data, int32_t sz);
int zproto_decode_field(struct zproto_buffer *zb, struct zproto_record *proto,
struct zproto_field_iter *iter, int32_t *sz);
int zproto_decode(struct zproto_buffer *zb, struct zproto_field_iter *iter,
uint8_t **data, int32_t *sz);

明显可以看出，接口和内聚性都提高了很多。在写bind代码时再也不需要维护上一次有效的字段了，因为在encode时已经被记入iter了。

当然代价肯定了也是有的，就是多实现了一组迭代器的函数，不过我认为这代代价是值得的。

由于zproto已经完全屏蔽了细节，因此在写bind代码时可以只关心本语言的数据结构的存取，而不会由于不懂zproto的实现细节导致传入错误的last_field造成zproto.c工作异常，大大降低了心理的包袱。

可以结总出迭代器一般用于提供给其他模块遍历时才使用（其实从标准库就可以看出，只是我自己没领会到^_^!)，迭代器数据结构也不一定只存储用于遍历的数据，只要方便达到目的也可以存一些冗余数据，比如zproto.c中的迭代器会存储上一次有效的字段。

现在再反思为什么以前写代码都不会用到迭代器模式其实都很清楚了。

在写C语言时，模块一般都是提供某种属性或某种行为的而不会提供遍历的特性，这种情况下也就没有必要去为此模块提供一个迭代器。

而在模块内部的数据结构, 其实也没有必要去实现一个迭代器，有时候直接操作成员去访问可以更直观更高效。

同样在C++开发时也并非说，实现了一个容器类数据结构就需要去为他实现一个迭代法器，如果此数据结构仅仅为优化特定模块而生。那么直接去访问有时后反而代码更少更简洁，也并不会造成什么坏的影响。

还是那句话，没有银弹，什么时候合适什么时候不合适还是要靠自己判断。