Only Power Do I Need.

Long-term study, endless practice, strict self-discipline.
随笔 - 16, 文章 - 0, 评论 - 1, 引用 - 0
数据加载中……

VS2008转到定义，提示符号未定义。 Go to definition. The symbol 'XXX' is not defined.

删除项目对应的NCB文件，NCB与SLN对应，一个项目又叫解决方案（而不是工程）只有一个。
删除后重新打开等绿条读完。

无效。

靠，无效你说个屁啊。

又删除SLN文件对应的SUO文件和NCB文件，打开项目，等绿条读完。

有效了。

原因不明，待补。

posted @ 2012-02-23 15:42 夜舞 阅读(2607) | 评论 (0) | 编辑 收藏

(转)CreateWindowEx返回句柄为0, GetLastError却返回0 .

这个问题真是奇怪, 明明CreateWindowEx失败了, 却, 紧跟着GetLastError却返回0说成功. fuck widnows!

其实创建窗口失败是因为, 我们注册的窗口处理函数里面 没有处理 WM_CREATE 等几个窗口刚创建的时候发送给窗口的几个消息, 在窗口处理函数里面调用 DefWindowProc() 搞定.

/////////////////
哈哈哈哈哈哈~~~~~俺终于自己调出来了，来公布正确答案！！！
原来是WndProc没有写对，没有处理好一些系统消息，比如WM_CREATE~
只要在WndProc正确处理了就好，哪怕是调用DefWindowProc也好~
再通过一个导出函数进入其主消息循环，就可以了~
值得借鉴的经验，CreateWindow返回NULL且GetLastError正常的时候，应该就是这个问题了！

原文链接: http://blog.csdn.net/zdl1016/article/details/3952825

posted @ 2011-11-09 00:32 夜舞 阅读(602) | 评论 (0) | 编辑 收藏

(转)谈谈vc如何写dll(封装性，隐藏头文件，私有成员) .

最近项目进行到一定阶段，老板要求把已完成部分分离开并把各模块封装成dll。用vs开发dll当然很简单，是用vs的向导可以很快写一个dll.但是我遇到了一些问题：刚开始只需要把各个模块的头文件和cpp加入到一个新的dll工程，然后又把导出类的成员函数和成员变量用到的结构体类型、类类型定义的头文件加进来，编译后dll就写出来了。问题是当我要使用这个dll时我就得把所有的相关头文件包含到引用dll的工程中。这样显然违背的我写dll的初衷。我认为我写dll的目的主要有两个：一是封装性。我不希望将我算法细节暴露给使用dll的人。因此我想把导出类引用的一些特殊类型(指的是除了简单类型之外的结构体或者类类型)的私有成员隐藏起来，这样就需要把那些头文件还有引用头文件的define语句也隐藏。二是易用性。把我这些dll给别人用时要让他们用起来很方便。如果不加修改的把现在的东西给他们用时需要他们先来熟悉这些特殊类型的定义，比如这些类型数据的初始化等等。而且我的dll引用到的头文件有好几个，而这些头文件又引用了其他头文件。也就是说如果直接提供一个dll我同时还用提供10多个头文件。

在网上我查了很多地方，总结别人的经验，总算把自己的dll封装好了。

    废话一大堆，现在说说我是怎么做的吧。

    现在我有一个导出类BClass,他的成员函数的参数类型和私有成员变量类型都被很多其他头文件所定义，网上提供的一个解决办法是把头文件的define引用语句放到对应的cpp中，这当然是必须的，但是仅仅这样做我们在导出类中使用这些特殊类型的变量只能使用指针。这一点是和dll的特性有关的，原因在于dll只在运行时才被程序加载，在编译时我们无法知道cpp引用头文件里定义的类型。这样如果不使用指针类型变量，由于我们不知道那些类型的变量的大小，在编译时就会报错。所以我们必须把那些非指针型特殊变量改成指针类型。可是如果我们不想这样改的话呢？另外还有缺点就是这样仍然可以让别人知道我的导出类的完整结构，仍然可以略微知道dll开发者的一些细节，封装性仍然不够好。

这样在我的导出类里面还要把一些成员函数和成员变量也给隐藏。容易解决的办法仍然有，把这些函数和变量都从导出类里面拿出来，放到cpp里面作为普通的全局变量和普通函数。这样也可以解决问题但是不是一个好办法，因为这样破坏了类结构（呵呵，曾经有同事直接告诉我不用导出类了，全部改成到处函数得了）。

    问题的解决办法：现有的导出类结构什么都不用改，但是这个类不能作为导出类，在此类的基础上定义他的抽象基类，如IBClass。然后我们把IBClass作为导出类，并且只把我们希望导出的成员函数或者公有变量放在抽象基类里面，把这些函数都作为虚拟函数。那么新的dll我们怎么使用呢，现在只涉及到类的初始化问题以及析构问题。在这里我定义了一个工厂类用来初始化导出类。

现在把过程写出来：

最初的BClass头文件：

#include"CClass.h"
#include"DClass.h"

class __declspec(dllexport) BClass{

func1(); // 这个我希望对dll使用者可见

func2(CClass param1);//这个我不希望对使用者可见，包括CClass类型以及定义它的头文件CClass.h

DClass param2;//这个我不希望对使用者可见，包括DClass类型以及定义它的头文件DClass.h
}

因此我的做法是在此基础上添加头文件IBClass.h:

class __declspec(dllexport) IBClass{
virtual func1(); // 这个我希望对dll使用者可见
}

然后我添加了BFactory.h头文件和BFactory.cpp文件
BFactory.h:

#include "IBClass.h"

class BClass;

class __declspec(dllexport) TrackerFactory
{
public:
 static IBClass *GetB();
 static void Destroy();
private:
 static BClass *pB;
};

BFactory.cpp:

#include "BClass.h"
#include "BFactory.h"

BClass *BFactory::pB = 0;

IBClass *BFactory::GetB()
{
 if(!pB)
 {
  pB = new BClass(); 
 }
 return pB;
}

void BFactory::Destroy()
{
 if(pB)
  delete pB;
}


转自: http://blog.csdn.net/xiunai78/article/details/4510795#reply

posted @ 2011-10-31 21:43 夜舞 阅读(2134) | 评论 (0) | 编辑 收藏

(转) 关于lua table是否为空的判断

在项目的脚本lua中经常有这样的需求，

1、local a = {}

2、对a进行处理

3、对a是否为空表进行判断

关于对a是否为空表的判断，我发现有些代码如此做：

if a == {} then

这样的结果就是a == {}永远返回false，是一个逻辑错误。因为这里比较的是table a和一个匿名table的内存地址。

也有些代码如此做：

if table.maxn(a) == 0 then

这样做也不保险，除非table的key都是数字，而没有hash部分。

难道真的要遍历table发现有东西就return false跳出才能断定它是否为空吗？这样写至少代码太难看. 

网上小搜了一下，发现原来官方手册里早已经给了答案，那就是靠lua内置的next函数

即如此用：if next(a) == nil then

next其实就是pairs遍历table时用来取下一个内容的函数.

在项目的module中最好封装一下，免得module本地也有next函数

于是封装后判断的lua table是否为空的函数如下：

function table_is_empty(t)

        return _G.next( t ) == nil

end

原地址 http://yy1983228.blog.163.com/blog/static/54211491200881092239485/

posted @ 2011-10-26 16:08 夜舞 阅读(6154) | 评论 (0) | 编辑 收藏

设计模式学习随笔

刚看完第二章, 顺带看桥接模式.
桥接模式是将构造最终目标(客户代码)用的公共接口抽象出来, 用不同的方式来实现这些抽象出来的公共接口.

不同的设计模式, 就是根据需要抽象了不同的地方, 封装了某一部分的变化, 同时阻碍了另一部分的变化.

对Builder的理解感觉总不大透彻, 看了这篇http://www.cnblogs.com/happyhippy/archive/2010/09/01/1814287.html, 讲得还不错.
我认为通篇最重要的一句话就是  Builder模式的核心是“聚合”
感觉Builder类的体系基本就是AbstractFactory, 只是不需要重定义所有的创建部件的接口.
最终产品是由ConcreteBuilder返回, 而Builder的BuildPart的工作是将部件组装到产品上, 而不仅仅是创建. 这就是说Director类其实只提供了步骤.

FactoryMethod和AbstractFactory的区别看起来是很明显的, 区别就在于Method, 其实FactoryMethod最终只是一个抽象方法.

"变化可以说是复用的基本所在。所以我认为看待设计模式一切都应从变化的角度来看。
factory method看到了单个类别的变性和部分代码逻辑的不变性，为了解决这种不对称，构建出这样的一个中介（creator）让之对称。
abstract facotry则是看到了多个相关类别的变性和部分代码逻辑的不变性，为了解决这种不对称，也构建这样的一个中（creator）让之对称，同时它也看到了这些类别的相关性，根据这种相关性来减少creator的数量。
所以，factory method和abstract facotry的眼中的变化基点是不一样的，这也造成了他们之间的差别。"
摘自http://www.cnblogs.com/happyhippy/archive/2010/09/26/1836223.html这篇的讨论, 对于理解设计模式的方式很有启发.

Decorator模式倒是跟Composite模式有异曲同工之妙. 都是用相同的接口操作不同的对象, 而对客户代码完全透明. 不同之处在于Composite模式是为了使对象聚合, 而Decorator模式是为了给对象添加新的功能.

FACADE, 外观模式. 将繁杂的一系列接口封装为一个新的简易接口, 如果是完全封装, 则有 解耦, 封装, "使接口易用而不会被误用" 等疗效. GOF的书里的例子是不完全封装, 则最大的作用是"使接口易用而不会被误用", 保留用户调用子系统接口的权利. 外观模式更像是一种思想而非具体的模式. 个人感觉就像是一个类里面的private函数(子系统功能)和public函数的关系(外观接口).

突然想到, 如果写程序需要用到抽象的时候, 也就是需要考虑设计模式的时候, 否则的话, 最好的设计模式就是不用设计模式.

posted @ 2011-10-24 01:45 夜舞 阅读(218) | 评论 (0) | 编辑 收藏

工作中的问题

定义了一个类中的指针变量, 却没有初始化为NULL, 而在用的时候还依赖于NULL是初始值的逻辑

定义了一个类中的容器变量, 却没有在整个类clear的时候clear它, 导致重新进游戏该容器依然上上一次游戏的时候的内容

函数的输入参数和返回值是自定义类型时, 如果可以传const引用或者引用, 就要传引用. std::string特别是, 栽这好多次了, 虽然非常明白, 但老是忘记.

修改了一个模块中的某个地方, 要考虑对这个模块所有功能的影响, 添加, 删除, 显示, 总之就是所有的功能.

一个函数应该功能单一, 并且与它的函数名相符, 如果函数功能被认为应该和另一些处理一起使用, 也应该是在调用函数处写, 不应一同写在函数内部.

BOOST正则表达式如果为空字符串, 进行匹配时会导致无限循环. 只是检查如果过滤字符串为空就临时赋值.

工作态度问题, 认为某个工作比较简单, 或者是因为不太想做, 或者是因为测试麻烦, 总之最后只做了基本测试就提交代码了, 导致出了一大堆错. 提高代码质量, 一次运行成功是非常牛比的技能不错, 但除了熟练和自己注意之外暂时并没有找到训练这一技能的方法. 只能是写完以后多多测试, 虽然测试很麻烦, 虽然要耽误较长的时间, 但错的东西没有任何价值. 这是态度问题, 一定要改.

posted @ 2011-10-10 10:25 夜舞 阅读(159) | 评论 (0) | 编辑 收藏

仅列出标题
共2页: 1 2