jxlczjp77的专栏

编写可适配的函数对象Effective STLEffective STL书中条款40提到，要使我们自己写的仿函数类可适配，仿函数类必须从类unary_function或者binary_function继承，因为这两个类提供了对象适配器需要的typedef。 listWidget> widgets;//...listWidget>::reverse_iterator 

  如果我有一个函数f和一个对象x，我希望在x上调用f，而且我在x的成员函数之外。C++给我三种不同的语法来实现这个调用： f(x);    // 语法#1：当f是一个非成员函数x.f();  // 语法#2：当f是一个成员函数，而且x是一个对象或一个对象的引用p->f(); // 语法#3：当f是一个成员函数，而且p是一个对象的指针  

上次分析了使用mem_fun和mem_fun_ref的原因，但并没有涉及到这两个函数的原理，所以这次打算把它们的源码拿出来看看。 这两个函数都是模板，用来转换某些类的成员函数，使得这些成员函数能够在象for_each这样的函数内部调用。先来看mem_fun这个模板函数吧，这个函数一共有四个重载版本：分别为转换带一个参数和不带参数的const和非const的函数共四个版本，并且按

 ptr_fun()函数比前面两个函数就要简单多了，这个函数只是将一个一般形式调用的函数(语法#1调用)包装成为一个可被适配的函数。还记得在条款40中，我们知道一个可适配的仿函数类必须从unary_function或binary_function继承。ptr_fun的功能就是包装一个一般意义的函数，生成一个可适配的仿函数对象。 // TEMPLATE FUNCTIO

 STL容器在被添加时(通过insert、push_front、push_back等)自动扩展它们自己来容纳新对象。这工作的很好，有些程序员因为这个信仰而被麻痹，认为他们不必担心要为容器中的对象腾出空间，因为容器自己可以照顾好这些。 vectorint> val;//...; 给val容器设置初值vectorint> res;transform(val.begin(),

   一般我们都会这样认为，用高级语言编程时抽象层次越高，产生的代码效率就越低。这在很多情况下都是事实，Alexander Stepano (STL的发明者) 有一次作了一组小测试，试图测量出相对于C而言，C++的“抽象惩罚”:     假设你需要以降序排序一个double的vector。最直接的STL方式是通过sort算法和greaterdouble>类型的函数对象： 

   在Modern C++ Design第二章第一节，有一个关于定制编译器错误提示的例子：templatebool> struct CompileTimeChecker {    CompileTimeChecker(...);    //一个接受任何参数的构造函数};template struct CompileTimeCheckerfalse> { };//特化false版本 /

网上很容易找到一个用boost::shared_mutex来作为读写锁的例子：typedef boost::shared_mutex rwmutex;typedef boost::shared_lock readLock;typedef boost::unique_lock writeLock;  一直没有怀疑过这个做法，直到最近项目中出现一个死锁问题，查了很久才发现是上面这种