|
rapped_memcached_result_length(const void* self)
88 {
89 return memcached_result_length((const memcached_result_st*)self);
90 }
91
92 int MCWRAPPER_CALL wrapped_memcached_delete(void* p,const char* key,size_t klength)
93 {
94 return memcached_delete((memcached_st*)p,key,klength,0);
95 }
96
97 int MCWRAPPER_CALL wrapped_memcached_exist(void* p,const char *key,size_t klength)
98 {
99 return memcached_exist((memcached_st*)p,key,klength);
100 }
101
102 int MCWRAPPER_CALL wrapped_memcached_flush(void* p)
103 {
104 return memcached_flush((memcached_st*)p,0);
105 }
106
107 int MCWRAPPER_CALL wrapped_memcached_cas(void* p,const char* key,size_t klength
108 ,const char* data,size_t dlength,uint64 cas)
109 {
110 return memcached_cas((memcached_st*)p,key,klength,data,dlength,0,0,cas);
111 }
112
113 int MCWRAPPER_CALL wrapped_memcached_increment(void* p,const char* key
114 ,size_t klength,uint32 step,uint64* value)
115 {
116 return memcached_increment((memcached_st*)p,key,klength,step,value);
117 }
118
119 int MCWRAPPER_CALL wrapped_memcached_decrement(void* p,const char* key
120 ,size_t klength,uint32 step,uint64* value)
121 {
122 return memcached_decrement((memcached_st*)p,key,klength,step,value);
123 }
124
125 int MCWRAPPER_CALL wrapped_memcached_increment_with_initial(void* p
126 ,const char* key,size_t klength,uint64 step,uint64 initial,uint64* value)
127 {
128 return memcached_increment_with_initial((memcached_st*)p,key,klength,step,initial,0,value);
129 }
130
131 void MCWRAPPER_CALL wrapped_memcached_result_free(void* result)
132 {
133 memcached_result_free((memcached_result_st*)result);
134 }
135
136 int MCWRAPPER_CALL wrapped_memcached_decrement_with_initial(void* p
137 ,const char* key,size_t klength,uint64 step,uint64 initial,uint64* value)
138 {
139 return memcached_decrement_with_initial((memcached_st*)p,key,klength,step,initial,0,value);
140 }
通过gcc在Mingw32的环境下编译该代码文件，并生成相应的动态库文件(MemcachedFunctionsWrapper.dll)，需要说明的是该动态库将静态依赖之前生成的libmemcached-8.dll，这一点可以在Mingw32下通过ldd命令予以验证。
剩下需要做的是去除之前声明的纯虚接口，直接导出一个C++的封装实现类，在该类的实现中，同样利用Windows API中的LoadLibrary和GetProcAddress方法动态加载之前生成的libmemcached函数封装动态库(MemcachedFunctionsWrapper.dll)。该C++类的类声明和上一篇中实现类的声明完全一致，这里就不在重复给出了。测试用例的代码也基本相同，只是不需要再通过C接口函数获取该C++类的对象指针了，而是可以直接将该C++类的头文件包含进测试用例所在的工程，目前之所以这样做是为了测试方便，一旦顺利通过测试用例后，可以再考虑将该C++类放到一个独立的VC工程中，并生成相应的dll文件，以便该模块可以被更多其他的VC程序调用，从而提高了程序整体的复用性。
在执行测试用例之前，这次的心情不再像上一次那样兴奋，只是默默的等待测试结果的正确返回。然而此时，在控制台窗口突然打印出一条libmemcached中的错误提示信息，看到该信息后，立刻切换到VMWire虚拟机中运行的Linux，查看memcached守护进程打印出的结果。出人意料的是，memcached没有任何反应，再结合libmemcached刚刚输出的错误信息，使我马上意识到测试用例并没有驱动libmemcached正常的工作，甚至根本就没有连接到Linux中的memcached服务器。想到这里，我首先关闭了Linux中iptables的防火墙，然后在我的Windows主机中通过telnet的方式，直接登录memcached服务器监听的端口，最后再切换回Linux查看memcached服务器的反应，这次memcached输出了一条客户端连接的信息，基于此可以证明主机(Windows)和VMWire虚拟机中的Linux之间的Socket通讯是正常的。带着忐忑的心情，再次执行了我的测试用例，果不其然，libmemcached输出了同样的错误信息，Linux端的memcached服务器也同样是没有任何反应。
这时已经是深夜了，人的大脑也进入了一种麻木的状态，于是决定上床休息，因为之前的经验告诉我，在这个时候离开电脑冷静的思考往往会分析到问题的本质，并做出正确的判断。
七、最后的决策：
这一次我的选择是暂时放弃移植libmemcached到VC的想法，原因如下：
1. libmemcached版本更新过快，从0.52到0.53的发布仅仅时隔两周，而且每两个版本之间的代码差异也非常大，甚至代码的目录组织结构也是如此，这 |