想起之前看过一句话，原文是英文记得不是很清晰了，
大概的意思“ date structure决定了你程序的上限，program 决定了你程序的下限”。
回想这段时间新建项目中用到的东西，再回望下过去，体会越发深刻。
2016年4月开启了几个项目
收费端软件
值得记录有以下几点
- 很早很早以前都是用 线程不断while循环， 中间再Sleep(300)//ms
- 现在用的比较多的是 用同步（Event）通知，否则一直等待。（上层再加个while(bLoop) 在析构的时候bLoop=0，这样可以就把这个线程 走完。）
这中间不知道减少了多少CPU 计算量。
2.多个事件通知，如何防止读脏数据，如何顺序同步（异步编程方式）
- 很早很早之前是直接通知，中间处理 全程要加锁
- 放入队列(FIFO 根据具体业务需求)，在处理FIFO的pop的时候才加锁或不加锁（ 1.锁很轻，2.而且一般是单个线程去pop，所以不需要加锁。 ）
- 异步方式的接口，所有接口都是异步来做（返回值，返回数据，都是这样， 这样会增加负担， 明明一次就可以处理的事情， 需要分2次来处理。）
比如我调用Login()接口，还需要在callback中返回 Login()的结果。
如果我调用 GetAccountList(),在callback中需要 处理ret,同时还要在这里处理 获取的数据的buffer.
(这里如果是窗口对象，还必须要弄成单例的，这样才好再middleware中处理login窗口对象的登录结果。并显示。（否则不好在middleware中处理login窗口对象的登录结果)
Tips:对于多个地方调用的类，一般都是做成单例，比如log信息显示（各个地方都要用）
3.异步这些接口 如何传递数据
我这边因为各种原因，别人认为应该不同的业务放到不同的callback中，我个人不太喜欢这种方式，虽然开发起来比较独立，
但是太大，后期代码不好看(阅读)，
如果做成一个callback 中，再分发各个业务，就比较容易看。（代码少好几倍了）
-
如果用指针，那么很多接口的数据的状态需要自己保存
比如我再callback中 调用void* pParam， 那么这个可以是对象指针，可以是结构体指针， 可以是分类MainMsg，SubMsg。
如果是callback分类，那么用结构体还是，在callback中多加几个形参？ 我个人是比较喜欢加形参，这个可以确定编程结构
在callback中是这样设计
Switch(nMainMsg)
{
case 1:
{
if(nSubMsg ==0)
else if(nSubMsg ==1)
else
{
}
break;
}
case 1:
//......
break;
default:
break;
}
如果只有void* 当做区分不同业务的参数，那么需要传结构体
XX struct
{
int MainMsg;
int SubMsg;
void* pInstance;//一般是对象指针
//...
}
如果不想管理结构体 生命周期，
那就可以callcack 中加入MainMsg,SubMsg, 对象指针不用传， 直接自己弄成单例。
如果放到SubClass中， 一般都是放入到 单例对象mainClass的队列中， 队列再处理分发到SubClass