我的评论 - 溪流漫话

@OwnWaterloo
呵呵

这种写法

template <typename S>
class C;

template <typename R>
class C<R (__stdcall)()>
{

};

发现通不过。。。

还有这个：

template <typename T>
class C;

template <typename U>
class C<SomeTraits<U>::Result>
{

};

偏特化的尖括号里不能进行摸板元运算？

re: C++ 下 Function 对象的实现（上）溪流 2011-01-19 00:59

@OwnWaterloo
呵呵，那玩意儿我本想改成一个博客客户端，一直没动。。。
可是，工作范围以外，就更要玩感兴趣的语言了呀~
我写转移文章的东西，不是为了转移文章，是为了写。
当然，碰到一些具有真实需求的并且有紧迫性的事情，那是要追求效率的。。。只不过这种状况跟工作无异了

re: C++ 下 Function 对象的实现（上）溪流 2011-01-19 00:56

@OwnWaterloo
但是只要不要把返回值拆出来，就是可以的

template<typename F>
void call(F f ) { return f(); }

void __cdecl f() { printf("cdecl\n"); }
void __stdcall g() { printf("stdcall\n"); }

re: C++ 下 Function 对象的实现（上）溪流 2011-01-19 00:50

@OwnWaterloo
多学点自然是应该的，但我觉得不应该追求日常编程脱离C/C++啊。。。那是件多么可怕的事，关系到饭碗。当然不是歧视脚本语言什么的，但是从现状看来，越来越多的人在用更加简单的语言，业界最稀有的的还是C/C++的人啊。（vczh说的生存斗争观点我很赞同。）越简单意味着入门越容易，竞争者多，于是想胜出就难了。所以我觉得往复杂方面靠的大方向还是要的。所以。。。用API不如造API，用轮子不如造轮子，不如用造轮子的轮子。。。临了的时候，也许可以居高临下的跟别人说：你，不就是会很多API么？这些API我都造过。你，不就是会用很多轮子吗？这些轮子我都造过。你，不就是会用很多语言吗？这些语言我也都造过。。。哈哈，扯淡了

re: C++ 下 Function 对象的实现（上）溪流 2011-01-19 00:33

@OwnWaterloo
bind的时候会遇到怎样的情形我目前不知道。但是就 function 的阶段来说，我刚刚自认为比较仔细地确认了代码能够跑的样子：

void __cdecl f1(int)
{

}

void __stdcall f2(int)
{

}

int main()
{
Function<void (int)> g1(&f1);
Function<void (int)> g2(&f2);
g1(0);
g2(0);

return 0;
}

观察汇编结果，f1的ret出来后有 add esp 4动作，f2的ret 4出来后没有

re: C++ 下 Function 对象的实现（上）溪流 2011-01-19 00:24

@OwnWaterloo
欢迎聊天~~~

warning神马的，感觉就是要见一次杀一次，不然绝对破窗效应。

“当需要这种灵活性时，直接把C++丢了，选其他动态类型语言来编程。”有一群纠结的人（当然不是我），他们的信仰就是用 C++ 做任何事，或者说他们的兴趣就是用C++ 来做任何事，那怎么办呢？呵呵。且不说个人兴趣导向。从很理性的结果主义的角度考虑，这种时候确实得换，应该要换，但也不是每个这样的场合都有条件换，比如团队里没有会python的且不想学python，但有一群蛋疼的Cpper，这种事情也会发生吧。

最后，你说你在教C？求教，求升华~！·^_^

re: C++ 下 Function 对象的实现（上）溪流 2011-01-19 00:17

@cexer
谢谢分享这么多想法。

给 handler 起名字确是删除 handler 的好办法，我可以不用纠结要不要用 typeid 啦。

另外关于你说的不同类型的handler的绑定，作为 Function，我觉得不该加入这样的特性；作为GUI专用的Event，是可以接受有的特性的。

但是另一点疑问是，框架告诉用户的规则——“返回 void 表示让框架决定是否继续处理，返回bool表示用户想让框架继续处理或者拒绝用户继续处理”，与WTL的bHandled告诉用户的——“设置bHandled用于指示框架是否继续处理”相比，优势大吗？都存在一种约定。而用返回void与bool的形式，可能仅仅是更加炫一点？

实现上，不管用户看到的参数是怎样的，框架最初获得的肯定是 WPARAM 和 LPARAM，这样，就算不修改 Function，似乎也可以在控件中给出不同的处理函数形式，例如给出一组重载的 OnClick：
OnClick(Function<void (int, int)>)
OnClick(Function<bool (int, int)>)
又例如给ClickEvent实现重载的operator+=？

前两天我在犹豫框架要不要帮用户解析 WPARAM、LPARAM，你的例子让我坚定了想法，解析之！。。让使用者不需要查 MSDN。。。或许做不到这种程度吧。

re: C++ 下 Function 对象的实现（上）溪流 2011-01-19 00:00

@OwnWaterloo
很多时候， C++ 程序员不是去考虑这种需求是否存在，实现这种需求的复杂度如何，维护代价如何。
仅仅是因为他们能，所以他们就要这样做……
其实有时候，这些需求仅仅是美学上的，而不是技术上的。

“仅仅是因为他们能，所以他们就要这样做……”有时候确实这样，但一般实现代价一般很小的情况下才会出现这种冲动，想要顺手做了。

re: C++ 下 Function 对象的实现（上）溪流 2011-01-18 23:49

@cexer
@OwnWaterloo
关于调用约定，貌似不用复制N份（VS2010下测试），函数会自动被识别为 R (__stdcall *)(...)

re: C++ 下 Function 对象的实现（上）溪流 2011-01-18 18:39

@zhaoyg
是的，T*自然没问题，就是为了同时也支持传入 T。

re: 2009-2010小结（二）溪流 2011-01-18 12:26

@潘孙友
牛逼！崇拜！

re: 2009-2010小结（二）溪流 2011-01-18 12:26

@zuhd
@right
不要瞎扯，哥很严肃的哦

re: 2009-2010小结（二）溪流 2011-01-18 00:47

@expter
没有艳遇。看到有人预测数字序列的要太监，坚决不能太监。

re: C++ 下 Function 对象的实现（上）溪流 2011-01-17 12:53

@cexer
很有启发性的提示，谢谢分享~！顶了再细读。