C++中std::tr1::function和bind 组件的使用 和 以boost::function和boost:bind取代虚函数

2024-03-17 15:38

本文主要是介绍C++中std::tr1::function和bind 组件的使用 和 以boost::function和boost:bind取代虚函数,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

个人的总结:

为什么要使用?

它们可以实现类似函数指针的功能,却比函数指针更加灵活(体现在占位符上面),尤其是在很多成员调用同一个函数(仅仅是参数类型不同)的时候比较方便

这个是函数指针做不到的

要注意的地方:

使用的时候一定要注意指向的是没有this指针的函数(全局函数或静态成员函数),还是有this指针的函数。后面一种必须要用bind()函数。而且要多一个参数。
注意bind的参数顺序: bind(&要调用的函数,&对象, 要调用函数的参数1,要调用函数的参数2...,_1(bind函数的参数1),_2(bind函数的参数2)...)
占位符号的参数是由 function 调用的时候传入的。 参数可以由function传入,也可由bind实现绑定传入,这两个是可以调整的。
class Foo
{
public:
void methodA();
void methodInt(int a);
};
class Bar
{
public:
void methodB();
};

boost::function<void()> f1; // 无参数,无返回值

Foo foo;
f1 = boost::bind(&Foo::methodA, &foo);
f1(); // 调用 foo.methodA();
Bar bar;
f1 = boost::bind(&Bar::methodB, &bar);
f1(); // 调用 bar.methodB();

f1 = boost::bind(&Foo::methodInt, &foo, 42);
f1(); // 调用 foo.methodInt(42);

boost::function<void(int)> f2; // int 参数,无返回值
f2 = boost::bind(&Foo::methodInt, &foo, _1);
f2(53); // 调用 foo.methodInt(53);

如果没有boost::bind,那么boost::function就什么都不是,而有了bind(),“同一个类的不同对象可以delegate给不同的实现,从而实现不同的行为”(myan语),简直就无敌了。

-----------------------------------------------------------------------------我是无情的分割线-----------------------------------------------------------------------------------------

在C++的TR1中(Technology Report)中包含一个function模板类和bind模板函数,使用它们可以实现类似函数指针的功能,但却却比函数指针更加灵活,特别是函数指向类 的非静态成员函数时。可以参考Scott Meyers. <<Effective C++ (3rd Edition)>>. Item 35.下面具体说明其使用方法。

一、指向全局函数或静态成员函数时

因为在本质上讲全局函数和静态成员函数没有区 别,使用方法上除了静态成员函数在引用时要在前面加域作用符className::外,没有其它任何区别,事实上全局函数也有可能放入命名空间,或者使用 全局域作用符,例如 nameSpace::function() 或::function,这样不仅本质上相同,形势上也与静态成员函数一致了,所以它们是没有区别的,放到一起讨论。

这种情况比较简单,只需要定义一个类型

#include <iostream>

#include <iomanip>

#include <tr1/memory>

#include <tr1/functional>

typedef std::tr1::function<void (int)> HandlerEvent;

然后再定义一个成员变量

class Sharp{

public:

HandlerEvent handlerEvent;

};

然后在其它函数内就可以通过设置handlerEvent的值来动态装载事件响应函数了,如:

class Rectangle{

private:

std::string name;

Sharp sharp;

public:

void initial(void);

const Sharp getSharp() const;

static void onEvent(int param){ //---------------(1)

std::cout << "invode onEvent method,get parameter: " << param << std::endl;

}

};

//类的实现方法

void Rectangle::initial(){

sharp.handlerEvent = HandlerEvent(&Rectangle::onEvent); //---------------(2)

std::cout << "invode initial function!" << std::endl;

}

const Sharp Rectangle::getSharp() const{

return sharp;

}

//下面为测试函数:

int main(int argc,char *argv[]){

std::cout <<"hi: " << std::setw(50) << "hello world!" << std::endl;

Rectangle rectangle;

rectangle.initial(); //---------------(3)

rectangle.getSharp().handlerEvent(23); //---------------(4)

}

//输出结果如下:

hi: hello world!

invode initial function!

invode onEvent method,get parameter: 23 //---------------(5)

注 意,这里使用了静态成员函数,如果把Rectangle前面的static去掉这段代码不能工作,编译都不能通过,因为静态成员函数与非静态成员函数的参 数表不一样,原型相同的非静态函数比静态成员函数多一个参数,即第一个参数this指针,指向所属的对象,任何非静态成员函数的第一个参数都是this指 针,所以如果把Rectangle前面的static去掉,其函数原型等效于下面的一个全局函数:

void onEvent(Rectangle* this, int);

所 以,这与HandlerEvent所声明的函数类型不匹配,编译将不能通过。而且,既然静态成员函数没有this指针,所以上面(3)处的调用使 sharp对象中的handlerEvent使向了Rectangle的静态方法onEvent(),这样当通过(4)处这样调用时就会自动执行(1)处 的静态函数onEvent()。

二、std::tr1::bind()模板函数的使用

通过上面的std::tr1::function 可以对静态成员函数进行绑定,但如果要对非静态成员函数的绑定,需用到下机将要介绍的bind()模板函数.

首先说bind的用法,其声明如下所示:

bind(Function fn, T1 t1, T2 t2, …, TN tN);

其中fn为将被调用的函数,t1…tN为函数的参数。如果不指明参数,则可以使用占位符表示形参,点位符格式为

std::tr1::placehoders::_1std::tr1::placehoders::_2, …, std::tr1::placehoders::_N

将上例中Rectangle::onEvent(int param)前的static去掉改为非静态成员函数,则进行动态绑定使得程序正常运行,将Rectangle::initial(void)的定义修改为:

void Rectangle::initial(){

sharp.handlerEvent = std::tr1::bind(&Rectangle::onEvent,this,std::tr1::placeholders::_1/*因onEvent函数需要一个参数,所以用一占位符*/);

std::cout << "invode initial function!" << std::endl;

}

这样,便动态装载函数成功。其它测试数据都不用进行修改。测试结果于上一样。

三、指向虚成员函数的使用

对 于虚成员函数的情况与上面第2节所说相同,仍然可以实现虑函数的效果。如果定义类Square继承自Rectangle,将 Rectangle::OnEvent重载,定义一个新的Square::OnEvent,Rectangle::initialize中的函数不变,仍 然使用Rectangle::OnEvent进进绑定,则调用成员object.onEvent()时,具体执行Rectangle::OnEvent还 是Square::OnEvent,看object所属对象的静态类型是Rectangle还是Square而定.

下面为简单示例:

我们首先修改一个上面Rectangle的initial()方法,改为虚函数。如:

virtual void onEvent(int param){

std::cout << "invode Rectangle's onEvent method,get parameter: " << param << std::endl;

}

然后我们再写一个Square类来继承Rectangle类。并重写onEvent方法。如:

class Square : public Rectangle{

public:

void onEvent(int param){

std::cout << "invode Square's onEvent method,get parameter: " << param << std::endl;

}

};

测试代码:

int main(int argc,char *argv[]){

Rectangle rectangle;

rectangle.initial();

rectangle.getSharp().handlerEvent(23);

Square square;

square.initial();

square.getSharp().handlerEvent(33);

}

运行后的结果如下:

hi: hello world!

invode initial function!

invode Rectangle's onEvent method,get parameter: 23

invode initial function!

invode Square's onEvent method,get parameter: 33

这样我们就可以看到sharp会针对具体对象来调用相应的onEvent()方法。 上面的程序示例读者可自行研习。

另一篇博文:

以boost::function和boost:bind取代虚函数


这是一篇比较情绪化的blog,中心思想是“继承就像一条贼船,上去就下不来了”,而借助boost::function和boost::bind,大多数情况下,你都不用上贼船。

boost::function和boost::bind已经纳入了std::tr1,这或许是C++0x最值得期待的功能,它将彻底改变C++库的设计方式,以及应用程序的编写方式。

Scott Meyers的Effective C++ 3rd ed.第35条款提到了以boost::function和boost:bind取代虚函数的做法,这里谈谈我自己使用的感受。


基本用途


boost::function就像C#里的delegate,可以指向任何函数,包括成员函数。当用bind把某个成员函数绑到某个对象上时,我们得到了一个closure(闭包)。例如:

class Foo
{
public:
void methodA();
void methodInt(int a);
};
class Bar
{
public:
void methodB();
};

boost::function<void()> f1; // 无参数,无返回值

Foo foo;
f1 = boost::bind(&Foo::methodA, &foo);
f1(); // 调用 foo.methodA();
Bar bar;
f1 = boost::bind(&Bar::methodB, &bar);
f1(); // 调用 bar.methodB();

f1 = boost::bind(&Foo::methodInt, &foo, 42);
f1(); // 调用 foo.methodInt(42);

boost::function<void(int)> f2; // int 参数,无返回值
f2 = boost::bind(&Foo::methodInt, &foo, _1);
f2(53); // 调用 foo.methodInt(53);

如果没有boost::bind,那么boost::function就什么都不是,而有了bind(),“同一个类的不同对象可以delegate给不同的实现,从而实现不同的行为”(myan语),简直就无敌了。


对程序库的影响


程序库的设计不应该给使用者带来不必要的限制(耦合),而继承是仅次于最强的一种耦合(最强耦合的是友元)。如果一个程序库限制其使用者必须从某个class派生,那么我觉得这是一个糟糕的设计。不巧的是,目前有些程序库就是这么做的。


例1:线程库


常规OO设计:


写一个Thread base class,含有(纯)虚函数 Thread#run(),然后应用程序派生一个继承class,覆写run()。程序里的每一种线程对应一个Thread的派生类。例如Java的Thread可以这么用。

缺点:如果一个class的三个method需要在三个不同的线程中执行,就得写helper class(es)并玩一些OO把戏。


基于closure的设计:


令Thread是一个具体类,其构造函数接受Callable对象。应用程序只需提供一个Callable对象,创建一份Thread实体,调用Thread#start()即可。Java的Thread也可以这么用,传入一个Runnable对象。C#的Thread只支持这一种用法,构造函数的参数是delegate ThreadStart。boost::thread也只支持这种用法。


// 一个基于 closure 的 Thread class 基本结构
class Thread 

public: 
typedef boost::function<void()> ThreadCallback; 
Thread(ThreadCallback cb) : cb_(cb) 
{ } 
void start() 

/* some magic to call run() in new created thread */ 

private: 
void run() 

cb_(); 

ThreadCallback cb_; 
// ... 
}; 

使用:
class Foo
{
public:
void runInThread();
};

Foo foo;
Thread thread(boost::bind(&Foo::runInThread, &foo));
thread.start();


例2:网络库


以boost::function作为桥梁,NetServer class对其使用者没有任何类型上的限制,只对成员函数的参数和返回类型有限制。使用者EchoService也完全不知道NetServer的存在,只要在main()里把两者装配到一起,程序就跑起来了。


// library
class Connection;
class NetServer : boost::noncopyable
{
public:
typedef boost::function<void (Connection*)> ConnectionCallback;
typedef boost::function<void (Connection*, const void*, int len)> MessageCallback;
NetServer(uint16_t port);
~NetServer();
void registerConnectionCallback(const ConnectionCallback&);
void registerMessageCallback(const MessageCallback&);
void sendMessage(Connection*, const void* buf, int len);
private:
// ...
};


// user
class EchoService
{
public:
typedef boost::function<void(Connection*, const void*, int)> SendMessageCallback; // 符合NetServer::sendMessage的原型

EchoService(const SendMessageCallback& sendMsgCb)
: sendMessageCb_(sendMsgCb)
{ }

void onMessage(Connection* conn, const void* buf, int size) // 符合NetServer::NetServer::MessageCallback的原型
{
printf("Received Msg from Connection %d: %.*s/n", conn->id(), size, (const char*)buf);
sendMessageCb_(conn, buf, size); // echo back
}

void onConnection(Connection* conn) // 符合NetServer::NetServer::ConnectionCallback的原型
{
printf("Connection from %s:%d is %s/n", conn->ipAddr(), conn->port(), conn->connected() ? "UP" : "DOWN");
}

private:
SendMessageCallback sendMessageCb_;
};

// 扮演上帝的角色,把各部件拼起来
int main()
{
NetServer server(7);
EchoService echo(bind(&NetServer::sendMessage, &server, _1, _2, _3));
server.registerMessageCallback(bind(&EchoService::onMessage, &echo, _1, _2, _3));
server.registerConnectionCallback(bind(&EchoService::onConnection, &echo, _1));
server.run();
}


对面向对象程序设计的影响


一直以来,我对面向对象有一种厌恶感,叠床架屋,绕来绕去的,一拳拳打在棉花上,不解决实际问题。面向对象三要素是封装、继承和多态。我认为封装是根本的,继承和多态则是可有可无。用class来表示concept,这是根本的;至于继承和多态,其耦合性太强,往往不划算。

继承和多态不仅规定了函数的名称、参数、返回类型,还规定了类的继承关系。在现代的OO编程语言里,借助反射和attribute/annotation,已经大大放宽了限制。举例来说,JUnit 3.x 是用反射,找出派生类里的名字符合 void test*() 的函数来执行,这里就没继承什么事,只是对函数的名称有部分限制(继承是全面限制,一字不差)。至于JUnit 4.x 和 NUnit 2.x 则更进一步,以annoatation/attribute来标明test case,更没继承什么事了。

我的猜测是,当初提出面向对象的时候,closure还没有一个通用的实现,所以它没能算作基本的抽象工具之一。现在既然closure已经这么方便了,或许我们应该重新审视面向对象设计,至少不要那么滥用继承。

自从找到了boost::function+boost::bind这对神兵利器,不用再考虑类直接的继承关系,只需要基于对象的设计(object-based),拳拳到肉,程序写起来顿时顺手了很多。


对面向对象设计模式的影响


既然虚函数能用closure代替,那么很多OO设计模式,尤其是行为模式,失去了存在的必要。另外,既然没有继承体系,那么创建型模式似乎也没啥用了。

最明显的是Strategy,不用累赘的Strategy基类和ConcreteStrategyA、ConcreteStrategyB等派生类,一个boost::function<>成员就解决问题。在《设计模式》这本书提到了23个模式,我认为iterator有用(或许再加个State),其他都在摆谱,拉虚架子,没啥用。或许它们解决了面向对象中的常见问题,不过要是我的程序里连面向对象(指继承和多态)都不用,那似乎也不用叨扰面向对象设计模式了。

或许closure-based programming将作为一种新的programming paradiam而流行起来。


依赖注入与单元测试


前面的EchoService可算是依赖注入的例子,EchoService需要一个什么东西来发送消息,它对这个“东西”的要求只是函数原型满足SendMessageCallback,而并不关系数据到底发到网络上还是发到控制台。在正常使用的时候,数据应该发给网络,而在做单元测试的时候,数据应该发给某个DataSink。

安照面向对象的思路,先写一个AbstractDataSink interface,包含sendMessage()这个虚函数,然后派生出两个classes:NetDataSink和MockDataSink,前面那个干活用,后面那个单元测试用。EchoService的构造函数应该以AbstractDataSink*为参数,这样就实现了所谓的接口与实现分离。

我认为这么做纯粹是脱了裤子放屁,直接传入一个SendMessageCallback对象就能解决问题。在单元测试的时候,可以boost::bind()到MockServer上,或某个全局函数上,完全不用继承和虚函数,也不会影响现有的设计。


什么时候使用继承?


如果是指OO中的public继承,即为了接口与实现分离,那么我只会在派生类的数目和功能完全确定的情况下使用。换句话说,不为将来的扩展考虑,这时候面向对象或许是一种不错的描述方法。一旦要考虑扩展,什么办法都没用,还不如把程序写简单点,将来好大改或重写。

如果是功能继承,那么我会考虑继承boost::noncopyable或boost::enable_shared_from_this,下一篇blog会讲到enable_shared_from_this在实现多线程安全的Signal/Slot时的妙用。

例如,IO-Multiplex在不同的操作系统下有不同的推荐实现,最通用的select(),POSIX的poll(),Linux的epoll(),FreeBSD的kqueue等等,数目固定,功能也完全确定,不用考虑扩展。那么设计一个NetLoop base class加若干具体classes就是不错的解决办法。


基于接口的设计


这个问题来自那个经典的讨论:不会飞的企鹅(Penguin)究竟应不应该继承自鸟(Bird),如果Bird定义了virtual function fly()的话。讨论的结果是,把具体的行为提出来,作为interface,比如Flyable(能飞的),Runnable(能跑的),然后让企鹅实现Runnable,麻雀实现Flyable和Runnable。(其实麻雀只能双脚跳,不能跑,这里不作深究。)

进一步的讨论表明,interface的粒度应足够小,或许包含一个method就够了,那么interface实际上退化成了给类型打的标签(tag)。在这种情况下,完全可以使用boost::function来代替,比如:


// 企鹅能游泳,也能跑
class Penguin
{
public:
void run();
void swim();
};


// 麻雀能飞,也能跑
class Sparrow
{
public:
void fly();
void run();
};


// 以 closure 作为接口
typedef boost::function<void()> FlyCallback;
typedef boost::function<void()> RunCallback;
typedef boost::function<void()> SwimCallback;


// 一个既用到run,也用到fly的客户class
class Foo
{
public:
Foo(FlyCallback flyCb, RunCallback runCb) : flyCb_(flyCb), runCb_(runCb)
{ }

private:
FlyCallback flyCb_;
RunCallback runCb_;
};

// 一个既用到run,也用到swim的客户class
class Bar
{
public:
Bar(SwimCallback swimCb, RunCallback runCb) : swimCb_(swimCb), runCb_(runCb)
{ }

private:
SwimCallback swimCb_;
RunCallback runCb_;
};


int main()
{
Sparrow s;
Penguin p;
// 装配起来,Foo要麻雀,Bar要企鹅。
Foo foo(bind(&Sparrow::fly, &s), bind(&Sparrow::run, &s));
Bar bar(bind(&Penguin::swim, &p), bind(&Penguin::run, &p));
}


实现Signal/Slot


boost::function + boost::bind 描述了一对一的回调,在项目中,我们借助boost::shared_ptr + boost::weak_ptr简洁地实现了多播(multi-cast),即一对多的回调,并且考虑了对象的生命期管理与多线程安全;并且,自然地,对使用者的类型不作任何限制,篇幅略长,留作下一篇blog吧。(boost::signals也实现了Signal/Slot,但可惜不是线程安全的。)


From : http://blog.csdn.net/kiang3/article/details/7571647


From: http://blog.csdn.net/solstice/article/details/3066268

以boost::function和boost:bind取代虚函数


这是一篇比较情绪化的blog,中心思想是“继承就像一条贼船,上去就下不来了”,而借助boost::function和boost::bind,大多数情况下,你都不用上贼船。

boost::function和boost::bind已经纳入了std::tr1,这或许是C++0x最值得期待的功能,它将彻底改变C++库的设计方式,以及应用程序的编写方式。

Scott Meyers的Effective C++ 3rd ed.第35条款提到了以boost::function和boost:bind取代虚函数的做法,这里谈谈我自己使用的感受。


基本用途


boost::function就像C#里的delegate,可以指向任何函数,包括成员函数。当用bind把某个成员函数绑到某个对象上时,我们得到了一个closure(闭包)。例如:
class Foo
{
 public:
  void methodA();
  void methodInt(int a);
};
class Bar
{
 public:
  void methodB();
};

boost::function<void()> f1; // 无参数,无返回值

Foo foo;
f1 = boost::bind(&Foo::methodA, &foo);
f1(); // 调用 foo.methodA();
Bar bar;
f1 = boost::bind(&Bar::methodB, &bar);
f1(); // 调用 bar.methodB();

f1 = boost::bind(&Foo::methodInt, &foo, 42);
f1(); // 调用 foo.methodInt(42);

boost::function<void(int)> f2; // int 参数,无返回值
f2 = boost::bind(&Foo::methodInt, &foo, _1);
f2(53); // 调用 foo.methodInt(53);

 

如果没有boost::bind,那么boost::function就什么都不是,而有了bind(),“同一个类的不同对象可以delegate给不同的实现,从而实现不同的行为”(myan语),简直就无敌了。


对程序库的影响


程序库的设计不应该给使用者带来不必要的限制(耦合),而继承是仅次于最强的一种耦合(最强耦合的是友元)。如果一个程序库限制其使用者必须从某个class派生,那么我觉得这是一个糟糕的设计。不巧的是,目前有些程序库就是这么做的。


例1:线程库


常规OO设计:


写一个Thread base class,含有(纯)虚函数 Thread#run(),然后应用程序派生一个继承class,覆写run()。程序里的每一种线程对应一个Thread的派生类。例如Java的Thread可以这么用。

 

缺点:如果一个class的三个method需要在三个不同的线程中执行,就得写helper class(es)并玩一些OO把戏。


基于closure的设计:


令Thread是一个具体类,其构造函数接受Callable对象。应用程序只需提供一个Callable对象,创建一份Thread实体,调用Thread#start()即可。Java的Thread也可以这么用,传入一个Runnable对象。C#的Thread只支持这一种用法,构造函数的参数是delegate ThreadStart。boost::thread也只支持这种用法。


// 一个基于 closure 的 Thread class 基本结构
class Thread 

 public: 
  typedef boost::function<void()> ThreadCallback; 
  Thread(ThreadCallback cb) : cb_(cb) 
  { } 
  void start() 
  { 
    /* some magic to call run() in new created thread */ 
  } 
 private: 
  void run() 
  { 
    cb_(); 
  } 
  ThreadCallback cb_; 
  // ... 
}; 

使用:
class Foo
{
 public:
  void runInThread();
};

Foo foo;
Thread thread(boost::bind(&Foo::runInThread, &foo));
thread.start();


例2:网络库


以boost::function作为桥梁,NetServer class对其使用者没有任何类型上的限制,只对成员函数的参数和返回类型有限制。使用者EchoService也完全不知道NetServer的存在,只要在main()里把两者装配到一起,程序就跑起来了。


// library
class Connection;
class NetServer : boost::noncopyable
{
 public:
  typedef boost::function<void (Connection*)> ConnectionCallback;
  typedef boost::function<void (Connection*, const void*, int len)> MessageCallback;
  NetServer(uint16_t port);
  ~NetServer();
  void registerConnectionCallback(const ConnectionCallback&);
  void registerMessageCallback(const MessageCallback&);
  void sendMessage(Connection*, const void* buf, int len);
 private:
  // ...
};


// user
class EchoService
{
 public:
  typedef boost::function<void(Connection*, const void*, int)> SendMessageCallback; // 符合NetServer::sendMessage的原型

  EchoService(const SendMessageCallback& sendMsgCb)
    : sendMessageCb_(sendMsgCb)
  { }

  void onMessage(Connection* conn, const void* buf, int size) // 符合NetServer::NetServer::MessageCallback的原型
  {
    printf("Received Msg from Connection %d: %.*s/n", conn->id(), size, (const char*)buf);
    sendMessageCb_(conn, buf, size); // echo back
  }

  void onConnection(Connection* conn) // 符合NetServer::NetServer::ConnectionCallback的原型
  {
    printf("Connection from %s:%d is %s/n", conn->ipAddr(), conn->port(), conn->connected() ? "UP" : "DOWN");
  }

 private:
  SendMessageCallback sendMessageCb_;
};

 

// 扮演上帝的角色,把各部件拼起来
int main()
{
  NetServer server(7);
  EchoService echo(bind(&NetServer::sendMessage, &server, _1, _2, _3));
  server.registerMessageCallback(bind(&EchoService::onMessage, &echo, _1, _2, _3));
  server.registerConnectionCallback(bind(&EchoService::onConnection, &echo, _1));
  server.run();
}


对面向对象程序设计的影响


一直以来,我对面向对象有一种厌恶感,叠床架屋,绕来绕去的,一拳拳打在棉花上,不解决实际问题。面向对象三要素是封装、继承和多态。我认为封装是根本的,继承和多态则是可有可无。用class来表示concept,这是根本的;至于继承和多态,其耦合性太强,往往不划算。

继承和多态不仅规定了函数的名称、参数、返回类型,还规定了类的继承关系。在现代的OO编程语言里,借助反射和attribute/annotation,已经大大放宽了限制。举例来说,JUnit 3.x 是用反射,找出派生类里的名字符合 void test*() 的函数来执行,这里就没继承什么事,只是对函数的名称有部分限制(继承是全面限制,一字不差)。至于JUnit 4.x 和 NUnit 2.x 则更进一步,以annoatation/attribute来标明test case,更没继承什么事了。

我的猜测是,当初提出面向对象的时候,closure还没有一个通用的实现,所以它没能算作基本的抽象工具之一。现在既然closure已经这么方便了,或许我们应该重新审视面向对象设计,至少不要那么滥用继承。

自从找到了boost::function+boost::bind这对神兵利器,不用再考虑类直接的继承关系,只需要基于对象的设计(object-based),拳拳到肉,程序写起来顿时顺手了很多。


对面向对象设计模式的影响


既然虚函数能用closure代替,那么很多OO设计模式,尤其是行为模式,失去了存在的必要。另外,既然没有继承体系,那么创建型模式似乎也没啥用了。

最明显的是Strategy,不用累赘的Strategy基类和ConcreteStrategyA、ConcreteStrategyB等派生类,一个boost::function<>成员就解决问题。在《设计模式》这本书提到了23个模式,我认为iterator有用(或许再加个State),其他都在摆谱,拉虚架子,没啥用。或许它们解决了面向对象中的常见问题,不过要是我的程序里连面向对象(指继承和多态)都不用,那似乎也不用叨扰面向对象设计模式了。

或许closure-based programming将作为一种新的programming paradiam而流行起来。


依赖注入与单元测试


前面的EchoService可算是依赖注入的例子,EchoService需要一个什么东西来发送消息,它对这个“东西”的要求只是函数原型满足SendMessageCallback,而并不关系数据到底发到网络上还是发到控制台。在正常使用的时候,数据应该发给网络,而在做单元测试的时候,数据应该发给某个DataSink。

安照面向对象的思路,先写一个AbstractDataSink interface,包含sendMessage()这个虚函数,然后派生出两个classes:NetDataSink和MockDataSink,前面那个干活用,后面那个单元测试用。EchoService的构造函数应该以AbstractDataSink*为参数,这样就实现了所谓的接口与实现分离。

我认为这么做纯粹是脱了裤子放屁,直接传入一个SendMessageCallback对象就能解决问题。在单元测试的时候,可以boost::bind()到MockServer上,或某个全局函数上,完全不用继承和虚函数,也不会影响现有的设计。


什么时候使用继承?


如果是指OO中的public继承,即为了接口与实现分离,那么我只会在派生类的数目和功能完全确定的情况下使用。换句话说,不为将来的扩展考虑,这时候面向对象或许是一种不错的描述方法。一旦要考虑扩展,什么办法都没用,还不如把程序写简单点,将来好大改或重写。

如果是功能继承,那么我会考虑继承boost::noncopyable或boost::enable_shared_from_this,下一篇blog会讲到enable_shared_from_this在实现多线程安全的Signal/Slot时的妙用。

例如,IO-Multiplex在不同的操作系统下有不同的推荐实现,最通用的select(),POSIX的poll(),Linux的epoll(),FreeBSD的kqueue等等,数目固定,功能也完全确定,不用考虑扩展。那么设计一个NetLoop base class加若干具体classes就是不错的解决办法。


基于接口的设计


这个问题来自那个经典的讨论:不会飞的企鹅(Penguin)究竟应不应该继承自鸟(Bird),如果Bird定义了virtual function fly()的话。讨论的结果是,把具体的行为提出来,作为interface,比如Flyable(能飞的),Runnable(能跑的),然后让企鹅实现Runnable,麻雀实现Flyable和Runnable。(其实麻雀只能双脚跳,不能跑,这里不作深究。)

进一步的讨论表明,interface的粒度应足够小,或许包含一个method就够了,那么interface实际上退化成了给类型打的标签(tag)。在这种情况下,完全可以使用boost::function来代替,比如:


// 企鹅能游泳,也能跑
class Penguin
{
 public:
  void run();
  void swim();
};


// 麻雀能飞,也能跑
class Sparrow
{
 public:
  void fly();
  void run();
};


// 以 closure 作为接口
typedef boost::function<void()> FlyCallback;
typedef boost::function<void()> RunCallback;
typedef boost::function<void()> SwimCallback;


// 一个既用到run,也用到fly的客户class
class Foo
{
 public:
  Foo(FlyCallback flyCb, RunCallback runCb) : flyCb_(flyCb), runCb_(runCb)
  { }

 private:
  FlyCallback flyCb_;
  RunCallback runCb_;
};

 

// 一个既用到run,也用到swim的客户class
class Bar
{
 public:
  Bar(SwimCallback swimCb, RunCallback runCb) : swimCb_(swimCb), runCb_(runCb)
  { }

 private:
  SwimCallback swimCb_;
  RunCallback runCb_;
};


int main()
{
  Sparrow s;
  Penguin p;
  // 装配起来,Foo要麻雀,Bar要企鹅。
  Foo foo(bind(&Sparrow::fly, &s), bind(&Sparrow::run, &s));
  Bar bar(bind(&Penguin::swim, &p), bind(&Penguin::run, &p));
}


实现Signal/Slot


boost::function + boost::bind 描述了一对一的回调,在项目中,我们借助boost::shared_ptr + boost::weak_ptr简洁地实现了多播(multi-cast),即一对多的回调,并且考虑了对象的生命期管理与多线程安全;并且,自然地,对使用者的类型不作任何限制,篇幅略长,留作下一篇blog吧。(boost::signals也实现了Signal/Slot,但可惜不是线程安全的。)




这篇关于C++中std::tr1::function和bind 组件的使用 和 以boost::function和boost:bind取代虚函数的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/819383

相关文章

JS常用组件收集

收集了一些平时遇到的前端比较优秀的组件,方便以后开发的时候查找!!! 函数工具: Lodash 页面固定: stickUp、jQuery.Pin 轮播: unslider、swiper 开关: switch 复选框: icheck 气泡: grumble 隐藏元素: Headroom

中文分词jieba库的使用与实景应用(一)

知识星球:https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义: 精确模式(默认模式): 全模式: 搜索引擎模式: paddle 模式(基于深度学习的分词模式): 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

Hadoop数据压缩使用介绍

一、压缩原则 (1)运算密集型的Job,少用压缩 (2)IO密集型的Job,多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1)为了支持多种压缩/解压缩算法,Hadoop引入了编码/解码器 2)要在Hadoop中启用压缩,可以配置如下参数

Makefile简明使用教程

文章目录 规则makefile文件的基本语法:加在命令前的特殊符号:.PHONY伪目标: Makefilev1 直观写法v2 加上中间过程v3 伪目标v4 变量 make 选项-f-n-C Make 是一种流行的构建工具,常用于将源代码转换成可执行文件或者其他形式的输出文件(如库文件、文档等)。Make 可以自动化地执行编译、链接等一系列操作。 规则 makefile文件

【C++ Primer Plus习题】13.4

大家好,这里是国中之林! ❥前些天发现了一个巨牛的人工智能学习网站,通俗易懂,风趣幽默,忍不住分享一下给大家。点击跳转到网站。有兴趣的可以点点进去看看← 问题: 解答: main.cpp #include <iostream>#include "port.h"int main() {Port p1;Port p2("Abc", "Bcc", 30);std::cout <<

使用opencv优化图片(画面变清晰)

文章目录 需求影响照片清晰度的因素 实现降噪测试代码 锐化空间锐化Unsharp Masking频率域锐化对比测试 对比度增强常用算法对比测试 需求 对图像进行优化,使其看起来更清晰,同时保持尺寸不变,通常涉及到图像处理技术如锐化、降噪、对比度增强等 影响照片清晰度的因素 影响照片清晰度的因素有很多,主要可以从以下几个方面来分析 1. 拍摄设备 相机传感器:相机传

C++包装器

包装器 在 C++ 中,“包装器”通常指的是一种设计模式或编程技巧,用于封装其他代码或对象,使其更易于使用、管理或扩展。包装器的概念在编程中非常普遍,可以用于函数、类、库等多个方面。下面是几个常见的 “包装器” 类型: 1. 函数包装器 函数包装器用于封装一个或多个函数,使其接口更统一或更便于调用。例如,std::function 是一个通用的函数包装器,它可以存储任意可调用对象(函数、函数

hdu1171(母函数或多重背包)

题意:把物品分成两份,使得价值最接近 可以用背包,或者是母函数来解,母函数(1 + x^v+x^2v+.....+x^num*v)(1 + x^v+x^2v+.....+x^num*v)(1 + x^v+x^2v+.....+x^num*v) 其中指数为价值,每一项的数目为(该物品数+1)个 代码如下: #include<iostream>#include<algorithm>

C++11第三弹:lambda表达式 | 新的类功能 | 模板的可变参数

🌈个人主页: 南桥几晴秋 🌈C++专栏: 南桥谈C++ 🌈C语言专栏: C语言学习系列 🌈Linux学习专栏: 南桥谈Linux 🌈数据结构学习专栏: 数据结构杂谈 🌈数据库学习专栏: 南桥谈MySQL 🌈Qt学习专栏: 南桥谈Qt 🌈菜鸡代码练习: 练习随想记录 🌈git学习: 南桥谈Git 🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈�