在7.11回来到8月中了,广告系统基本完成。在这过程之中碰到了很多的问题,很多细节方面没有处理好。因此做个总结，做个备忘，避免以后遇到相同或者类似的问题能快速正确的解决。
1.关于知识面，及新事物吸收
(1)库的使用
开源库：一个是google的ctemplate,另一个是haxx的curl库。
HTTP库：http请求解析，http组织响应
其他库
关于库的使用：
首先需要阅读帮助文档快速找到库的使用方法，其次对于一些使用的函数的细节需要看帮助文档，没有文档则看源码。不能任意凭借函数名自己去猜测其功能，对公司以前的库的使用，关键几个函数要看看其实现，避免在使用处理中出现错误。最后要做单元测试,测试各种情况下是否符合处理逻辑。
编译中要注意事项:都是使用静态库
curl 在windows中,编译时在工程定义宏HTTP_ONLY，使用curl静态库时,定义宏CURL_STATICLIB
连接类库要附加ws_32.lib,对libc.lib根据情况决定是否要忽略
curl 在linux中，./configure时，需要制定--disable-ldap --disable-ldaps，其他根据帮助确定是否要指定。在使用curl库时,需要在之前指定 -lidn -lrt
ctemplate 在windows中使用该库需要指定编译条件 /D CTEMPLATE_DLL_DECL=
关于原子操作在linux中有可能编译出现错误提示，需要根据系统情况指定编译条件
如 -march=i686
(2)关于HTTP协议
早在在看nginx时，就已经看过HTTP协议，也是知道HTTP 请求和响应时的格式，但是在使用时只是简单的根据现有的HTTP的相关类库，没有仔细考虑清楚，在响应时也没有设置想要响应信息。说明很多东西不仅仅是看过之后就好了，在实际使用时必定要多思考，考虑清楚为什么这么做，这么做是否符合协议要求，是否浏览器和服务器能解析。
(3)关于多线程
线程间数据同步,考虑锁是否可递归。
线程避免多次启动，造成不意外的错误。
(4)IO模型
异步阻塞IO:io multiplexing（非阻塞IO+select/epoll）
异步非阻塞IO:linux aio/windows 不了解
(5)multiplexing两种模型:Reactor,Proactor
multiplexing:Reactor,Proactor
Reactor:使用IO multiplexing，关心IO就绪事件
1.注册读就绪事件和相应的事件处理器；
2.事件分离器等待事件；(select/epoll)
3.事件到来，激活分离器，分离器调用事件对应的处理器；(分别处理读写事件)
4.事件处理器完成实际的读操作，处理读到的数据，注册新的事件，然后返还控制权。
Proactor:使用异步IO（如AIO），只关注完成事件
1. 处理器发起异步操作，并关注I/O完成事件；(在发起异步操作的时候会填充缓冲区地址，大小之类信息)
2. 事件分离器等待操作完成事件；
3. 分离器等待过程中，内核并行执行实际的I/O操作，并将结果数据存入用户自定义缓冲区，最后通知事件分离器读操作完成；
4. I/O完成后，通过事件分离器呼唤处理器；
5. 事件处理器处理用户自定义缓冲区中的数据；
2.关于STL方面
容器的选择方面有失误，vector用惯了就会习惯就是用vector,在删除偏多的时候vector没有list效率高。而效率方面是必须要着重考虑的。
关于容器的删除，迭代器会失效的问题，2种方法进行删除是安全的，1使用erase返回删除后的下一个迭代器的位置,2增加一个迭代器保存删除前的下一个位置。
使用 container.erase(iter++)这种方法可能会失效，在deque中有碰到过。
其次,在容器中存储上大结构或类则存指针，在key上能存简单数据类型就存简单数据类型。
stl exception 需要看看
3.关于类设计
在整个类中的整体设计有所欠缺，需要增加这方面知识。
内部接口方面：尽量简化操作。特别是主要函数中必须逻辑清楚，可以将相关功能进行分解细化，这样接口明确，方便阅读维护。其次在返回值上要清晰描述各种含义
数据类型方面：内部数据类型及锁的考虑以及各结构中字节排序问题。（可能和经验也有关系）
4.关于指针和内存
在内存使用上必须在使用之前就想好需要分配和释放的各种可能，可以使用内存池进行管理，也可以使用share_ptr进行引用计数管理（这个没有用过）
内存池大小控制，可以根据实际环境调节好内存池的大小，避免无休止的分配内存。
内存回收后指针失效和关联指针内存统一回收：
这两点必须要引起注意，在后期测试过程中很多Bug会是由于这些问题引起的。在使用过程之前最后将各种关系画草图，描述好各种情况，便于得知在某处删除或回收
内存，那么是否有相关的指针指向其他内存块，这些内存块是否也要回事。
内存的测试问题：
在windows下试了几个工具感觉没什么效果。
在linux中使用valgrind，这个工具比较强大，能够较好的知道程序是由于何种原因退出，在运行过程中哪些访问是无效的，哪些内存使用是泄露的，哪些是可能泄露的
只要在gcc/g++生成时加入-g那么还会显示出是在哪个cpp中的哪个函数和哪行是出现问题。
C++内存管理看看
5.关于测试和调试
windows 上VC9/VC10 DLL测试，1.启动DLL，加载到附加进程中设断点调试 2.在启动DLL前，打开cpp，在启动DLL的工程中，设断点调试
linux 上，多线程可以在启动程序后，查看进程号，gdb -attach 附加到进程中进行调试。gdb调试没有IDE调试方便，可能gdb用的少了
6.关于细节
考虑内部整体的处理流程的时候在第一次考虑后没有想的太细致。在初步流程写完后，发现还有很多细节处理上需要修改，这种情况可能允许出现
但是有的一些细节考虑上自己没搞好，浪费了时间比如url参数的值是字符串还是int值之类，
亦或是将linux中本该用usleep的用成了sleep这两者之间差的一个量级，就因为这多调试了2天。
因此，总的来说，写代码比较快，但是如何避免在写完之后继续的为了这些细小的错误而花费更多的时间去调整修正亦或是测试之后才能根据反馈结果再去修改，
这些都是会造成工作效率的低下。
PS:对象声明引用，引用其他位置的类。
7.关于学习计划
c++内存管理，
UNP，
BOOST库，
网络编程方面的，
设计模式方面的，
pthreads programming,
windows 核心编程/网络编程，
makefile深入学习,
使用vi开发,而非简单实用
算法导论，
TCP协议卷一
1.关于知识面，及新事物吸收
(1)库的使用
开源库：一个是google的ctemplate,另一个是haxx的curl库。
HTTP库：http请求解析，http组织响应
其他库
关于库的使用：
首先需要阅读帮助文档快速找到库的使用方法，其次对于一些使用的函数的细节需要看帮助文档，没有文档则看源码。不能任意凭借函数名自己去猜测其功能，对公司以前的库的使用，关键几个函数要看看其实现，避免在使用处理中出现错误。最后要做单元测试,测试各种情况下是否符合处理逻辑。
编译中要注意事项:都是使用静态库
curl 在windows中,编译时在工程定义宏HTTP_ONLY，使用curl静态库时,定义宏CURL_STATICLIB
连接类库要附加ws_32.lib,对libc.lib根据情况决定是否要忽略
curl 在linux中，./configure时，需要制定--disable-ldap --disable-ldaps，其他根据帮助确定是否要指定。在使用curl库时,需要在之前指定 -lidn -lrt
ctemplate 在windows中使用该库需要指定编译条件 /D CTEMPLATE_DLL_DECL=
关于原子操作在linux中有可能编译出现错误提示，需要根据系统情况指定编译条件
如 -march=i686
(2)关于HTTP协议
早在在看nginx时，就已经看过HTTP协议，也是知道HTTP 请求和响应时的格式，但是在使用时只是简单的根据现有的HTTP的相关类库，没有仔细考虑清楚，在响应时也没有设置想要响应信息。说明很多东西不仅仅是看过之后就好了，在实际使用时必定要多思考，考虑清楚为什么这么做，这么做是否符合协议要求，是否浏览器和服务器能解析。
(3)关于多线程
线程间数据同步,考虑锁是否可递归。
线程避免多次启动，造成不意外的错误。
(4)IO模型
异步阻塞IO:io multiplexing（非阻塞IO+select/epoll）
异步非阻塞IO:linux aio/windows 不了解
(5)multiplexing两种模型:Reactor,Proactor
multiplexing:Reactor,Proactor
Reactor:使用IO multiplexing，关心IO就绪事件
1.注册读就绪事件和相应的事件处理器；
2.事件分离器等待事件；(select/epoll)
3.事件到来，激活分离器，分离器调用事件对应的处理器；(分别处理读写事件)
4.事件处理器完成实际的读操作，处理读到的数据，注册新的事件，然后返还控制权。
Proactor:使用异步IO（如AIO），只关注完成事件
1. 处理器发起异步操作，并关注I/O完成事件；(在发起异步操作的时候会填充缓冲区地址，大小之类信息)
2. 事件分离器等待操作完成事件；
3. 分离器等待过程中，内核并行执行实际的I/O操作，并将结果数据存入用户自定义缓冲区，最后通知事件分离器读操作完成；
4. I/O完成后，通过事件分离器呼唤处理器；
5. 事件处理器处理用户自定义缓冲区中的数据；
2.关于STL方面
容器的选择方面有失误，vector用惯了就会习惯就是用vector,在删除偏多的时候vector没有list效率高。而效率方面是必须要着重考虑的。
关于容器的删除，迭代器会失效的问题，2种方法进行删除是安全的，1使用erase返回删除后的下一个迭代器的位置,2增加一个迭代器保存删除前的下一个位置。
使用 container.erase(iter++)这种方法可能会失效，在deque中有碰到过。
其次,在容器中存储上大结构或类则存指针，在key上能存简单数据类型就存简单数据类型。
stl exception 需要看看
3.关于类设计
在整个类中的整体设计有所欠缺，需要增加这方面知识。
内部接口方面：尽量简化操作。特别是主要函数中必须逻辑清楚，可以将相关功能进行分解细化，这样接口明确，方便阅读维护。其次在返回值上要清晰描述各种含义
数据类型方面：内部数据类型及锁的考虑以及各结构中字节排序问题。（可能和经验也有关系）
4.关于指针和内存
在内存使用上必须在使用之前就想好需要分配和释放的各种可能，可以使用内存池进行管理，也可以使用share_ptr进行引用计数管理（这个没有用过）
内存池大小控制，可以根据实际环境调节好内存池的大小，避免无休止的分配内存。
内存回收后指针失效和关联指针内存统一回收：
这两点必须要引起注意，在后期测试过程中很多Bug会是由于这些问题引起的。在使用过程之前最后将各种关系画草图，描述好各种情况，便于得知在某处删除或回收
内存，那么是否有相关的指针指向其他内存块，这些内存块是否也要回事。
内存的测试问题：
在windows下试了几个工具感觉没什么效果。
在linux中使用valgrind，这个工具比较强大，能够较好的知道程序是由于何种原因退出，在运行过程中哪些访问是无效的，哪些内存使用是泄露的，哪些是可能泄露的
只要在gcc/g++生成时加入-g那么还会显示出是在哪个cpp中的哪个函数和哪行是出现问题。
C++内存管理看看
5.关于测试和调试
windows 上VC9/VC10 DLL测试，1.启动DLL，加载到附加进程中设断点调试 2.在启动DLL前，打开cpp，在启动DLL的工程中，设断点调试
linux 上，多线程可以在启动程序后，查看进程号，gdb -attach 附加到进程中进行调试。gdb调试没有IDE调试方便，可能gdb用的少了
6.关于细节
考虑内部整体的处理流程的时候在第一次考虑后没有想的太细致。在初步流程写完后，发现还有很多细节处理上需要修改，这种情况可能允许出现
但是有的一些细节考虑上自己没搞好，浪费了时间比如url参数的值是字符串还是int值之类，
亦或是将linux中本该用usleep的用成了sleep这两者之间差的一个量级，就因为这多调试了2天。
因此，总的来说，写代码比较快，但是如何避免在写完之后继续的为了这些细小的错误而花费更多的时间去调整修正亦或是测试之后才能根据反馈结果再去修改，
这些都是会造成工作效率的低下。
PS:对象声明引用，引用其他位置的类。
7.关于学习计划
c++内存管理，
UNP，
BOOST库，
网络编程方面的，
设计模式方面的，
pthreads programming,
windows 核心编程/网络编程，
makefile深入学习,
使用vi开发,而非简单实用
算法导论，
TCP协议卷一
扫一扫
74
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
