#include <stdio.h>

main()

{

   FILE *fp;

   char filename[80];

   long length;

   printf("输入文件名:");

   gets(filename);

   //以二进制读文件方式打开文件

   fp=fopen(filename,"rb");

   if(fp==NULL)

      printf("file not found!\n");

   else

      {

         //把文件的位置指针移到文件尾

          fseek(fp,OL,SEEK_END);

         //获取文件长度;

          length=ftell(fp);

          printf("该文件的长度为%1d字节\n",length);

          fclose(fp);

      }

}


from: http://my.opera.com/lau_jia/blog/show.dml/380421

一. Iterator认识
如果需要构造一组通用容器，提供一套统一的算法，构造底层数据结构类库，iterator的设计无疑是非常重要的。iterator可以方便容器元素的遍历，提供算法的统一参数接口。怎么说？首先，让我们考虑一个算法。
Template <class T> ptrdiff_t
distance(T p1, T p2)
{
  //计算p1和p2之间的距离
}
显然这个函数是想计算两个“位置”之间距离。这里表示“位置”的类型T，可以是指向数组中某个元素的（原生）指针，可以是指向链表节点的指针，也可以是用来记录位置的任何对象（例如我们要谈的iterator）。不管这两个位置是对应在数组，vector，链表或是其他任何容器，我们当然希望设计好的类库中最好只要一个这样的distance函数，而不需要每种容器都有不同的“位置”记录方式，从而导致需要很多个这样的distance算法。对，我们完全可以抽象出一种表示“位置”的概念，它像游标，像智能的指针，可以方便的遍历容器中的元素，记录位置，而不用管你作用的是什么类型的容器，这就是现在被容器设计者普遍接受的iterator概念。

二. STL iterator的设计：
为什么不用继承构造iterator？
容器抽象出5种iterator 类型，input<--forward<--bidrectional<--random access iterator加上output iterator，我们能不能通过refinement关系设计出具有继承关系的几个iterator类？然后各个容器的iterator类去继承这些基类。那么上面的disatance函数可以设计两个版本
ptrdiff_t distance(InputIterator p1, InputIterator p2)
{
 //InputIterator只能一个一个前进,例如链表
  ptrdiff_t n=0;
  while(p1 != p2)
  {
   ++p1; ++n;   
  }
  return n;
}

ptrdiff_t distance(RandomAccessIterator p1, RandomAccessIterator p2)
{
 //RandomAccessIterator可以直接计算差距，例如数组，vector等
 return p2-p1;
}

这样看来是可行的对吗？但为什么STL不采用这种方式呢？（各位帮我想想啊，我实在是菜，想不出很好的理由啊）我所能想到的有：iterator可以是原生指针的类型，而原生指针是不会继承InputIterator基类的。（是不是还有效率问题？)

不讨论STL为什么不这么作，还是看看它漂亮的处理方法吧：先提醒你，它用的是函数模板（function template）的参数推导机制来确定函数返回值和参数类型的。

(1)  通过不同的iterator概念，先作几个表明iterator类型的tag类。input_iterator_tag<--forward_iterator_tag<--bidrectonal_iterator_tag<--random_access_iterator_tag。还有output_iterator_tag，这几个类都是空的，前面4个有继承关系。

(2)  STL设计的iterator类都需要typedef一个重要的类型iterator_category用来表明这个iterator是什么类型的iterator，它必须是上面tag类中的一个。例如list<T>的iterator类有：
    typedef bidrectonal_iterator_tag iterator_category;
   
    另外需要有一个value_type类型表明iterator是指向什么类型的元素。例如list<T>的iterator类有：
    typedef T value_type;

(3)  设计iterator_traits<class Iterator>类，这个类的作用是可以提取出模板参数Iterator类的类型。也是通过typedef实现的。如下：
template <class Iterator>
struct iterator_traits {
  typedef typename Iterator::iterator_category iterator_category;
  typedef typename Iterator::value_type        value_type;
  //.....
};

本来第二步中，我们设计的iterator类已经可以通过typedef别名来标志类型了，为什么要这层中间转换？原因是通常我们可以写Iterator::iterator_category作为一个typename，但如果Iterator是一个原生指针T*，我们写T*::iterator_category就得不到啦。利用partial specialization（模板偏特化）技术，可以通过中间层iterator_traits自己指定并得到原生指针的iterator_category类型，代码如下。（这么复杂的编译技术，真不知他们咋整的...吾辈只能望洋兴叹55）

template <class T>
struct iterator_traits<T*> {
  typedef random_access_iterator_tag iterator_category;
  typedef T                          value_type;
  //........
};

(4)  设想要设计一个算法template <class Iterator> RET_TYPE gen_fun(Iterator p1, Iterator p2, ...)。
一般这么处理：
template <class Iterator> RET_TYPE gen_fun(Iterator p1, Iterator p2, ...)
{
    typedef iterator_traits<Iterator>::iterator_category category;   
    typedef iterator_traits<Iterator>::value_type type;  //这个type用于实际运算中得知iterator指向的对象(*运算符返回类型)
   __gen_fun(Iterator p1, Iterator p2, ..., category());
}

category()构造一个iterator_tag类型的临时变量，该临时变量只用于区分调用函数，不参与实际算法实现。具体实现方法如下：(注意最后的参数不用变量名)

template <class Iterator> RET_TYPE __gen_fun(Iterator p1, Iterator p2, ..., input_iterator_tag)
{
   //input_iterator类型的实际实现方法
   //并且由于tag类继承机制，forward_iterator类型也会调用本方法
}
 
template <class Iterator> RET_TYPE __gen_fun(Iterator p1, Iterator p2, ..., bidrectonal_iterator_tag)
{
   //bidrectonal_iterator类型的实际实现方法
}

template <class Iterator> RET_TYPE __gen_fun(Iterator p1, Iterator p2, ..., random_access_iterator_tag)
{
   //random_access_iterator类型的实际实现方法
}

这样通过定义iterator tag和函数模板的参数推导机制，就实现了参数类型识别，达到了构造继承关系的iterator类实现的功能。并且没有继承要求那么严格，而且typedef是在编译时候完成的工作，丝毫不影响程序运行速度。如果增加iterator中typedef的类型，如pointer等，可以增强参数类型识别的功能。

另外需要提醒的是，在STL代码中，如果是random_access_iterator类型的方法，它通常写
template <class RandomAccessIterator> RET_TYPE __gen_fun(RandomAccessIterator p1, RandomAccessIterator p2, ..., random_access_iterator_tag)
是input_iterator类型的方法，它通常写
template <class InputIterator> RET_TYPE __gen_fun(InputIterator p1, InputIterator p2, ..., input_iterator_tag)
但是，别被这里的RandomAccessIterator和InputIterator迷惑了，它们只是模板参数而已，并没有继承关系，也不存在这样的类！（我就被这个迷惑了好久:( ）也不是我开头提的构造一组继承关系的Iterator类。模板参数写成RandomAccessIterator并不能表示该RandomAccessIterator类型就是random_access_iterator的，它写成T，Type，Iter都没有关系。只有通过iterator_traits得到iterator_tag才能表明iterator的真正类型。我想它那样写，只是为了提醒你调用函数的iterator类型吧。

三. 最后看看开头提的distance()算法实际实现：

template <class Iterator> inline
 typename iterator_traits<Iterator>::iterator_category
  iterator_category(const Iterator&) 
  //提取Iterator的iterator_category类型
{
  typedef typename iterator_traits<Iterator>::iterator_category category;
  return category();
}

template <class InputIterator, class Distance>
inline void distance(InputIterator first, InputIterator last, Distance& n) 
{
  __distance(first, last, n, iterator_category(first));
  //根据提取的iterator_category类型选择实际执行函数
  //Distance是通过引用传递，相当于函数返回值
}

template <class InputIterator, class Distance>
inline void __distance(InputIterator first, InputIterator last, Distance& n,
                       input_iterator_tag)
{
  //input_iterator类型的实现，根据input_iterator_tag的继承关系，forward_iterator
  //和bidrectonal_iterator也会调用此实现函数。
  while (first != last) { ++first; ++n; }
}

template <class RandomAccessIterator, class Distance>
inline void __distance(RandomAccessIterator first, RandomAccessIterator last,
                       Distance& n, random_access_iterator_tag)
{
  //random_access_iterator类型的实现
  n += last - first;
}

                                                                              2004.11.10
from: http://www.zahui.com/html/9/35875.htm

Allocators are one of the most mysterious parts of the C++ Standard library. Allocators are rarely used explicitly; the Standard doesn't make it clear when they should ever be used. Today's allocators are substantially different from those in the original STL proposal, and there were two other designs in between — all of which relied on language features that, until recently, were available on few compilers. The Standard appears to make promises about allocator functionality with one hand and then take those promises away with the other.

This column will discuss what you can use allocators for and how you can define your own. I'm only going to discuss allocators as defined by the C++ Standard: bringing in pre-Standard designs, or workarounds for deficient compilers, would just add to the confusion.

When Not to Use Allocators

Allocators in the C++ Standard come in two pieces: a set of generic requirements, specified in 20.1.5 (Table 32), and the class std::allocator, specified in 20.4.1. We call a class an allocator if it conforms to the requirements of Table 32. The std::allocator class conforms to those requirements, so it is an allocator. It is the only predefined allocator class in the standard library.

Every C++ programmer already knows about dynamic memory allocation: you write new X to allocate memory and create a new object of type X, and you write delete p to destroy the object that p points to and return its memory. You might reasonably think that allocators have something to do with new and delete — but they don't. (The Standard describes ::operator new as an "allocation function," but, confusingly, that's not the same as an allocator.)

The most important fact about allocators is that they were intended for one purpose only: encapsulating the low-level details of STL containers' memory management. You shouldn't invoke allocator member functions in your own code, unless you're writing an STL container yourself. You shouldn't try to use allocators to implement operator new[]; that's not what they're for. If you aren't sure whether you need to use allocators, then you don't.

An allocator is a class with member functions allocate and deallocate, the rough equivalents of malloc and free. It also has helper functions for manipulating the memory that it allocated and typedefs that describe how to refer to the memory — names for pointer and reference types. If an STL container allocates all of its memory through a user-provided allocator (which the predefined STL containers all do; each of them has a template parameter that defaults to std::allocator), you can control its memory management by providing your own allocator.

This flexibility is limited: a container still decides for itself how much memory it's going to ask for and how the memory will be used. You get to control which low-level functions a container calls when it asks for more memory, but you can't use allocators to make a vector act like a deque. Sometimes, though, even this limited flexibility is useful. If you have a special fast_allocator that allocates and deallocates memory quickly, for example (perhaps by giving up thread safety, or by using a small local heap), you can make the standard list class use it by writing std::list<T, fast_allocator<T> > instead of plain std::list<T>.

If this seems esoteric to you, you're right. There is no reason to use allocators in normal code.

Defining an Allocator

This already shows you something about allocators: they're templates. Allocators, like containers, have value types, and an allocator's value type must match the value type of the container it's used with. This can sometimes get ugly: map's value type is fairly complicated, so a map with an explicit allocator involves expressions like std::map<K, V, fast_allocator<std::pair<const K, V> > >. (As usual, typedefs help.)

Let's start with a simple example. According to the C++ Standard, std::allocator is built on top of ::operator new. If you're using an automatic tool to trace memory usage, it's often more convenient to have something a bit simpler than std::allocator. We can use malloc instead of ::operator new, and we can leave out the complicated performance optimizations that you'll find in a good implementation of std::allocator. We'll call this simple allocator malloc_allocator.

Since the memory management in malloc_allocator is simple, we can focus on the boilerplate that's common to all STL allocators. First, some types: an allocator is a class template, and an instance of that template allocates memory specifically for objects of some type T. We provide a series of typedefs that describe how to refer to objects of that type: value_type for T itself, and others for the various flavors of pointers and references.

template <class T> class malloc_allocator
{
public:
  typedef T                 value_type;
  typedef value_type*       pointer;
  typedef const value_type* const_pointer;
  typedef value_type&       reference;
  typedef const value_type& const_reference;
  typedef std::size_t       size_type;
  typedef std::ptrdiff_t    difference_type;
  ...
};

template <class T> class malloc_allocator
{
public:
  pointer address(reference x) const { return &x; }
  const_pointer address(const_reference x) const { 
    return &x; 
  }
  ...
};

template <class T> class malloc_allocator 
{
public:
  pointer allocate(size_type n, const_pointer = 0) {
    void* p = std::malloc(n * sizeof(T));
    if (!p)
      throw std::bad_alloc();
    return static_cast<pointer>(p);
  }

  void deallocate(pointer p, size_type) {
    std::free(p);
  }

  size_type max_size() const { 
    return static_cast<size_type>(-1) / sizeof(value_type);
  }
  ...
};

template <class T> class malloc_allocator
{
public:
  void construct(pointer p, const value_type& x) { 
    new(p) value_type(x); 
  }
  void destroy(pointer p) { p->~value_type(); }
  ...
};

template <class T> class malloc_allocator
{
public:
  malloc_allocator() {}
  malloc_allocator(const malloc_allocator&) {}
  ~malloc_allocator() {}
private:
  void operator=(const malloc_allocator&);
  ...
};

template <class T>
inline bool operator==(const malloc_allocator<T>&, 
                       const malloc_allocator<T>&) {
  return true;
}

template <class T>
inline bool operator!=(const malloc_allocator<T>&, 
                       const malloc_allocator<T>&) {
  return false;
}

template <class T> class malloc_allocator
{
public:
  template <class U> 
  malloc_allocator(const malloc_allocator<U>&) {}

  template <class U> 
  struct rebind { typedef malloc_allocator<U> other; };
  ...
};

template <class T, int flags> class my_allocator
{
public:
  template <class U>
  struct rebind { typedef my_allocator<U, flags> other; };
  ...
};

template<> class malloc_allocator<void>
{
  typedef void        value_type;
  typedef void*       pointer;
  typedef const void* const_pointer;

  template <class U> 
  struct rebind { typedef malloc_allocator<U> other; };

Using Allocators

std::vector<char, malloc_allocator<char> > V;

  typedef std::list<int, mempool_allocator<int> > List;
  List L(mempool_allocator<int>(p));

template <class T, class Allocator = std::allocator<T> >
class Array : private Allocator
{
public:
  typedef T value_type;
 
  typedef typename Allocator::reference reference;
  typedef typename Allocator::const_reference 
          const_reference;

  typedef typename Allocator::size_type size_type;
  typedef typename Allocator::difference_type 
          difference_type;

  typedef typename Allocator::pointer       iterator;
  typedef typename Allocator::const_pointer const_iterator;

  typedef Allocator allocator_type;
  allocator_type get_allocator() const {
    return static_cast<const Allocator&>(*this);
  }

  iterator begin()             { return first; }
  iterator end()               { return last; }
  const_iterator begin() const { return first; }
  const_iterator end() const   { return last; }

  Array(size_type n = 0, 
        const T& x = T(), 
        const Allocator& a = Allocator());
  Array(const Array&);
  ~Array();

  Array& operator=(const Array&);

private:
  typename Allocator::pointer first;
  typename Allocator::pointer last;
};

template <class T, class Allocator>
Array<T, Allocator>::Array(size_type n, 
                           const T& x, 
                           const Allocator& a)
  : Allocator(a), first(0), last(0)
{
  if (n != 0) {
    first = Allocator::allocate(n);
    size_type i;
    try {
      for (i = 0; i < n; ++i) {
        Allocator::construct(first + i, x);
      }
    }
    catch(...) {
      for(size_type j = 0; j < i; ++j) {
        Allocator::destroy(first + j);
      }
      Allocator::deallocate(first, n);
      throw;
    }
  }
}

template <class T, class Allocator>
Array<T, Allocator>::~Array() 
{
  if (first != last) {
    for (iterator i = first; i < last; ++i)
      Allocator::destroy(i);
    Allocator::deallocate(first, last - first);
  }
}

template <class T> 
struct List_node
{
  T val;
  List_node* next;
};

• Using an allocator whose value type is List_node<T>, allocate memory for a new list node.
• Using an allocator whose value type is T, construct the new list element in the node's val slot.
• Link the node into place appropriately.

template <class T, class Pointer>
struct List_node
{
  T val;
  Pointer next;
};

template <class T, class Alloc>
class List : private Alloc
{
private:
  typedef typename Alloc::template rebind<void>::other  
          Void_alloc;
  typedef typename Void_alloc::pointer Voidptr;
  typedef typename List_node<T, Voidptr> Node;
  typedef typename Alloc::template rebind<Node>::other 
          Node_alloc;
  typedef typename Node_alloc::pointer Nodeptr;
  typedef typename Alloc::template rebind<Voidptr>::other
          Voidptr_alloc;

  Nodeptr new_node(const T& x, Nodeptr next) {
    Alloc a = get_allocator();
    Nodeptr p = Node_alloc(a).allocate(1);
    try {
      a.construct(p->val, x);
    }
    catch(...) {
      Node_alloc(a).deallocate(p, 1);
      throw;
    }
    Voidptr_alloc(a).construct(p->next, Voidptr(next));
    return p;
  }

  ...
};

And finally, in case you think that this is far too much effort for far too small a benefit, a reminder: just because you can write a container class that uses allocators doesn't mean that you have to, or that you should. Sometimes you might want to write a container class that relies on a specific allocation strategy, whether it's something as ambitious as a disk-based B-tree container or as simple as the block class that I describe in my book. Even if you do want to write a container class that uses allocators, you don't have to support alternate pointer types. You can write a container where you require that any user-supplied allocator uses ordinary pointers, and document that restriction. Not everything has to be fully general.

Future Directions

If you want to write a simple allocator like malloc_allocator, you should have no difficulty. (Provided that you're using a reasonably modern compiler, that is.) If you have more ambitious plans, however — a memory pool allocator or an allocator with nonstandard pointer types for distributed computing — the situation is less satisfactory.

If you want to use some alternative pointer-like type, what operations does it have to support? Must it have a special null value, and, if so, how is that value written? Can you use casts? How can you convert between pointer-like objects and ordinary pointers? Do you have to worry about pointer operations throwing exceptions? I made some assumptions in the last section; the C++ Standard doesn't say whether those assumptions are right or wrong. These details are left to individual standard library implementations, and it's even legal for an implementation to ignore alternative pointer types altogether. The C++ Standard also leaves a few unanswered questions about what happens when different instances of an allocator aren't interchangeable.

Fortunately, the situation isn't quite as dire as the words in the Standard (20.1.5, paragraphs 4-5) might make it seem. The Standard left some questions unanswered because, at the time it was written, the C++ standardization committee wasn't able to agree on the answers; the necessary experience with allocators did not exist. Everyone involved in writing this section of the Standard considered it to be a temporary patch, and the vagueness will definitely be removed in a future revision.

For the moment, it's best to stay away from alternative pointer types if you're concerned about portability, but, if you're willing to accept a few limitations, you can safely use allocators like mempool_allocator where the differences between individual objects is important. All major standard library implementations now support such allocators in some way, and the differences between implementations are minor.

Just as the containers take allocator types as template parameters, so the containers' constructors take allocator objects as arguments. A container makes a copy of that argument and uses the copy for all of its memory management; once it is initialized in the constructor, the container's allocator is never changed.

The only question is what happens when you perform an operation that requires two containers to cooperate on memory management. There are exactly two such operations in the standard library: swap (all containers) and std::list::splice. In principle, an implementation could handle them in several different ways:

• Forbid swap or splice between two containers whose allocators aren't equal.
• Put a test for allocator equality in swap and splice. If the allocators aren't equal, then fall back to some other operation like copying and assignment.
• For swap only: swap the containers' allocators as well as their data. (It's hard to see how we could generalize this to splice. It also presents a problem: how do you swap things that don't have assignment operators?)

If you just stay away from swap and splice whenever two containers might be using different allocators, you'll be safe. In practice, I haven't found this to be a serious restriction: you need tight discipline to use a feature like memory pools safely, and you probably won't want indiscriminate mixing between containers with different allocators.

Partly because of unfamiliarity and partly because of the unsatisfactory state of the C++ Standard's requirements, most uses of allocators today are simple. As the C++ community becomes more familiar with allocators, and as the Standard is clarified, we can expect more sophisticated uses to emerge.

Listing 1: A sample allocator based on malloc

template <class T> class malloc_allocator
{
public:
  typedef T                 value_type;
  typedef value_type*       pointer;
  typedef const value_type* const_pointer;
  typedef value_type&       reference;
  typedef const value_type& const_reference;
  typedef std::size_t       size_type;
  typedef std::ptrdiff_t    difference_type;
  
  template <class U> 
  struct rebind { typedef malloc_allocator<U> other; };

  malloc_allocator() {}
  malloc_allocator(const malloc_allocator&) {}
  template <class U> 
  malloc_allocator(const malloc_allocator<U>&) {}
  ~malloc_allocator() {}

  pointer address(reference x) const { return &x; }
  const_pointer address(const_reference x) const { 
    return x;
  }

  pointer allocate(size_type n, const_pointer = 0) {
    void* p = std::malloc(n * sizeof(T));
    if (!p)
      throw std::bad_alloc();
    return static_cast<pointer>(p);
  }

  void deallocate(pointer p, size_type) { std::free(p); }

  size_type max_size() const { 
    return static_cast<size_type>(-1) / sizeof(T);
  }

  void construct(pointer p, const value_type& x) { 
    new(p) value_type(x); 
  }
  void destroy(pointer p) { p->~value_type(); }

private:
  void operator=(const malloc_allocator&);
};

template<> class malloc_allocator<void>
{
  typedef void        value_type;
  typedef void*       pointer;
  typedef const void* const_pointer;

  template <class U> 
  struct rebind { typedef malloc_allocator<U> other; };
};


template <class T>
inline bool operator==(const malloc_allocator<T>&, 
                       const malloc_allocator<T>&) {
  return true;
}

template <class T>
inline bool operator!=(const malloc_allocator<T>&, 
                       const malloc_allocator<T>&) {
  return false;
}

Notes

[1] You can see an example of a pool allocator in the open source SGI Pro64^TM compiler, http://oss.sgi.com/projects/Pro64/.

[2] Why the funny template keyword in that expression? It's an annoying little technicality; like typename, it helps the compiler resolve a parsing ambiguity. The problem is that when A is a template parameter, and the compiler sees an expression like A::B<T>, the compiler doesn't know anything about A's members. Should it assume that B<T> is a member template, or should it assume that B is an ordinary member variable and that < is just a less than sign? A human reader knows which way to interpret it, but the compiler doesn't. You need to put in template to force the first interpretation. Formally, the rule (in 14.2 of the C++ Standard) is: "When the name of a member template specialization appears after . or -> in a postfix-expression, or after nested-name-specifier in a qualified-id, and the postfix-expression or qualified-id explicitly depends on a template-parameter (14.6.2), the member template name must be prefixed by the keyword template. Otherwise the name is assumed to name a non-template."

Matt Austern is the author of Generic Programming and the STL and the chair of the C++ standardization committee's library working group. He works at AT&T Labs — Research and can be contacted at austern@research.att.com.

std::auto_ptr<int> int_memory_manager(new int);
// Alternately, you could include "using namespace std;" or 
// "using namespace std::auto_ptr" at the top of your code to avoid having to
// prefix all declarations with std::auto_ptr

*int_memory_manager = 5;

std::auto_ptr<myClass> myClassManager(new myClass);
myClass->variable = 50;

std::auto_ptr<int> int_memory_manager(new int[10]);

int* example()
{
std::auto_ptr<int> int_memory_manager(new int);
return int_memory_manager.release(); // we'll see release in more depth below 

std::auto_ptr<int> int_memory_manager(new int);
std::auto_ptr<int> int_memory_manager2;
cout<<"Contents of first is "<<int_memory_manager.get()<<endl;
int_memory_manager2 = int_memory_manager;
cout<<"Contents of first is "<<int_memory_manager.get()<<endl;
cout<<"Contents of second is "<<int_memory_manager2.get()<<endl;

using namespace std;
void aFunction(std::auto_ptr<int> x)
{
}

int main()
{
    std::auto_ptr<int> int_manager(new int);
    aFunction(int_manager);
    cout<<"Content of int_manager is "int_manager.get()<<endl;
    // Expected output: 0
}

std::auto_ptr<int> int_memory_manager(new int);
// Calling release sets the pointer managed by int_memory_manager to point 
// to NULL
int *need_to_delete_ptr = int_memory_manager.release();
delete need_to_delete_ptr;

std::auto_ptr<int> int_memory_manager(new int);
int_memory_manager.reset(new int);

• auto_ptr objects store pointers and handle deleting the pointer when the auto_ptr object goes out of scope
• Using auto_ptr helps avoid memory leaks associated with exceptions and minimizes the amount of cleanup code required

• Copying an auto_ptr changes the object being copied by setting the contests to NULL
• auto_ptr objects are not guaranteed to work correctly with the standard template library containers

using [typename][::] nested-name-specifier unqualified-id
using :: unqualified-id

The using declaration introduces a name into the declarative region in which the using declaration appears. The name becomes a synonym for an entity declared elsewhere. It allows an individual name from a specific namespace to be used without explicit qualification. This is in contrast to the using directive, which allows all the names in a namespace to be used without qualification. See using Directive for more information.

A using-declaration can be used in a class definition. For example:

class B
{
    void f(char);
    void g(char);
};

class D : B
{
    using B::f;
    void f(int) { f('c'); }        // calls B::f(char)
    void g(int) { g('c'); }        // recursively calls D::g(int)
                                   // only B::f is being used
};

When used to declare a member, a using-declaration must refer to a member of a base class. For example:

class C
{
    int g();
};

class D2 : public B
{
    using B::f;          // ok: B is a base of D2
    using C::g;          // error: C isn't a base of D2
};

Members declared with a using-declaration can be referenced using explicit qualification. The :: prefix refers to the global namespace. For example:

void f();

namespace A
{
    void g();
}

namespace X
{
    using ::f;        // global f
    using A::g;       // A's g
}

void h()
{
    X::f();           // calls ::f
    X::g();           // calls A::g
}

Just as with any declaration, a using-declaration can be used repeatedly only where multiple declarations are allowed. For example:

namespace A
{
    int i;
}

void f()
{
    using A::i;
    using A::i;        // ok: double declaration
}

class B
{
protected:
    int i;
};

class X : public B
{
public:
    using B::i;
    using B::i;        // error: class members cannot be multiply declared
};

When a using-declaration is made, the synonym created by the declaration refers only to definitions that are valid at the point of the using-declaration. Definitions added to a namespace after the using-declaration are not valid synonyms. For example:

namespace A
{
    void f(int);
}

using A::f;        // f is a synonym for A::f(int) only

namespace A
{
    void f(char);
}

void f()
{
    f('a');            // refers to A::f(int), even though A::f(char) exists
}

void b()
{
    using A::f;        // refers to A::f(int) AND A::f(char)
    f('a');            // calls A::f(char);
}

A name defined by a using-declaration is an alias for its original name. It does not affect the type, linkage or other attributes of the original declaration.

If a set of local declarations and using-declarations for a single name are given in a declarative region, they must all refer to the same entity, or they must all refer to functions. For example:

namespace B
{
    int i;
    void f(int);
    void f(double);
}

void g()
{
    int i;
    using B::i;          // error: i declared twice
    void f(char);
    using B::f;          // ok: each f is a function
}

In the example above, the using B::i statement causes a second int i to be declared in the g() function. The using B::f statement does not conflict with the f(char) function because the function names introduced by B::f have different parameter types.

A local function declaration cannot have the same name and type as a function introduced by a using-declaration. For example:

namespace B
{
    void f(int);
    void f(double);
}

namespace C
{
    void f(int);
    void f(double);
    void f(char);
}

void h()
{
    using B::f;          // introduces B::f(int) and B::f(double)
    using C::f;          // C::f(int), C::f(double), and C::f(char)
    f('h');              // calls C::f(char)
    f(1);                // error: ambiguous: B::f(int) or C::f(int)?
    void f(int);         // error: conflicts with B::f(int) and C::f(int)
}

When a using-declaration introduces a name from a base class into a derived class scope, member functions in the derived class override virtual member functions with the same name and argument types in the base class. For example:

struct B
{
    virtual void f(int);
    virtual void f(char);
    void g(int);
    void h(int);
};

struct D : B
{
    using B::f;
    void f(int);         // ok: D::f(int) overrides B::f(int)

    using B::g;
    void g(char);        // ok: there is no B::g(char)

    using B::h;
    void h(int);         // error: D::h(int) conflicts with B::h(int)
                         // B::h(int) is not virtual
};

void f(D* pd)
{
    pd->f(1);            // calls D::f(int)
    pd->f('a');          // calls B::f(char)
    pd->g(1);            // calls B::g(int)
    pd->g('a');          // calls D::g(char)
}

All instances of a name mentioned in a using-declaration must be accessible. In particular, if a derived class uses a using-declaration to access a member of a base class, the member name must be accessible. If the name is that of an overloaded member function, then all functions named must be accessible. For example:

class A
{
private:
    void f(char);
public:
    void f(int);
protected:
    void g();
};

class B : public A
{
    using A::f;          // error: A::f(char) is inaccessible
public:
    using A::g;          // B::g is a public synonym for A::g
};


from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/tions_43.asp

By Yarin
TopCoder Member

Introduction
This course tries to quickly teach how to use the Standard Template Library for the most common tasks without having to rely on other sources. It tells very little how things work, but instead gives several code snippets from which it should be possible to figure out how to use some parts of the STL. Since it's a crash course, a lot of things are left out and some things are simplified so much they're almost lies...

The STL is a collection of containers and simple algorithms. A container is something that holds several elements of the same type. The containers described in this course are vector, set and map, but the STL have several more containers. The STL header files required in this course are vector, set, map and algorithm. I also use iostream and string (the latter is not part of the STL, even though it in many ways have the same functionality). All classes are declared in the namespace std, so having the following lines at the beginning of your code is a good idea:

#include <iostream>
#include <string>
#include <vector>
#include <set>
#include <map>
#include <algorithm>

using namespace std;

vector

A vector corresponds to a 1-dimensional array in C. A vector is declared like this:

vector<int> a;       // Declare a vector of integers
vector<MyStruct> b;  // Declare a vector of MyStruct

The vectors declared above both initially contain zero elements. This is no problem, since vectors (like all the STL containers) can grow dynamically by inserting elements.

It's also possible to initialize a vector with elements and also give those a specific value:

vector<int> c(50,1); // Declare a vector of integers with 50 elements, all set to 1

For structs and classes, the initial value should be a constructor. If the initial value is omitted, the default constructor will be used (in case of simple types like int, double etc, the initial value is 0).

Elements in a vector are accessed the same way as elements in an array, using the [] operator. Elements can also be accessed using at:

cout << c[5] << endl;
cout << c.at(5) << endl;

The difference between the two is that at will raise an exception if you try to access an element outside the vector while the [] operator won't.

Extending the size of a vector by appending an element to the end is done with the push_back method:

vector<int> a(10,1);
a.push_back(2);      // Element 0 to 9 in a is now 1, and element 10 is 2.

It's not possible to insert elements anywhere else in a vector. Other ways to resize a vector includes the resize method:

vector<int> a(10,1);
a.resize(15);        // Element 0 to 9 in a is now 1, and element 10 to 14 is 0.

If resize increases the number of elements, the default constructor is assigned to the new elements. Decreasing the size of a vector removes elements from the end of the vector.

Other useful methods in the vector class are: (T is the type of each element)

size_t size();       // Returns the number of elements in the vector
void pop_back();     // Removes the last element
T back();            // Returns the value of the last element
void clear();        // Essentially the same thing as resize(0)

Sorting

A vector can of course be sorted: (also works on arrays)

sort(&a[0],&a[N]);   // N = no elements in the vector (i.e. a.size())

This will sort all elements in a in the default order. For built-in types, the default order is ascending. For structs and classes, you can define the default order by defining how the less-than operator should work:

bool operator<(const MyStruct &a, const MyStruct &b)
{
  // Return true if A<B, false if A>=B
}

The two parameters to sort specify the range in the vector to be sorted, by pointing to the first element and the element after the last one. So sort(&a[0],&a[N]) sorts elements 0,1,...,N-1. This way of specifying a range is used throughout all the STL, and is very practical.

Since it's most common you want to perform an operation on the whole vector, the start and endpoint have special names: begin() and end(). So instead of sort(&a[0],&a[N]) one can do sort(a.begin(),a.end()). Actually, &a[0] and a.begin() are not in general interchangeable as the former is a pointer and the latter an iterator (more about this later).

pair

A tiny class that is part of the STL is pair, which basically just contains (as the name implies) two data members - first and second. However, it's practical to use, especially when sorting a vector of pairs. The members are, respectively, used as the first and second sort key, which means that both data types used must have a less-than operator defined. For instance, if you want to sort coordinates first according to their x value and then their y value, then we can use the pair class like this:

int N,x,y;
vector< pair<int,int> > a; // It's essential that there is a space between > and >!
cin >> N;
for(int i=0;i<N;++i) {
  cin >> x >> y;
  a.push_back(make_pair(x,y)); // make_pair creates a pair<int,int> object
}
sort(a.begin(),a.end()); // Sorts first according to the x-coordinate, then the y-coordinate

Note the use of make_pair (also part of the STL). Without it, we would have to type something like a.push_back(pair<int,int>(x,y))

set

One of the most fundamental ways to store information is to have a set of objects. Defining a set of integers is done with

set<int> a;

To add, remove and check for single elements in a set:

a.insert(7);         // Insert integer 7 in the set
a.erase(5);          // Remove integer 5 (if it exist) from the set
if (a.find(7)!=a.end())
  ; // Integer 7 exists in the set
else
  ; // Integer 7 does not exist
cout << a.size() << endl; // Print the number of elements in the set a

Other common set operations includes finding the union, intersection and difference between two sets.

set<int> a,b,un,in,di;
..
..
set_union(a.begin(),a.end(),b.begin(),b.end(),insert_iterator<set<int> >(un,un.begin()));
set_intersection(a.begin(),a.end(),b.begin(),b.end(),insert_iterator<set<int> >(in,in.begin()));
set_difference(a.begin(),a.end(),b.begin(),b.end(),insert_iterator<set<int> >(di,di.begin()));

It's necessary to use the insert_iterator thingy which insert all elements in the union (or intersection or difference) of the two sets a and b into set c. If c is not empty, you might want to clear the set first using the clear() method.

To allow for fast operations, the internal representation of a set is a balanced binary tree. This means that the type of the values must be sortable, i.e. having a less-than operator defined (see above). Thus all elements in a set are always sorted, which can be quite practical.

Conversions

One can initialize a set from a vector:

set<int> b(a.begin(),a.end()); // a is a vector<int>

Going the other way is also possible:

vector<int> c(b.begin(),b.end()); // b is a set<int>

Doing these two operations after each other effectively sorts a vector of integers and removes all duplicate elements!

map

It's often desirable to have a 1-1 relation between two data types. One member in the relation is the key element, the lookup value. The other is the data value, retrieved by doing a lookup. For example, we might want to map names of cities (stored as strings) to serial number (integers):

map<string,int> a;

Now, map can in some ways be used exactly as a vector:

a["New York"]=7;
a["Los Angeles"]=8;
a["Boston"]=10;
a["Los Angeles"]=3;
cout << a["Los Angeles"] << endl;     // Prints 3
cout << a["San Francisco"] << endl;   // Prints 0

If no value is given to a key, it receives the default constructor (0 for simple types).

The map class can be thought of as a set of pairs (where first is the key value and second the data value) with the [] operator declared in a handy way, except that only the key value needs a less-than operator defined.

It might be worth noting that by defining a map<int,int> one basically has an infinite large array of integers!

Looping over elements

Looping over all elements in a vector can be done by looping over all indexes, but that's not possible in a set or a map. Instead one can use one of the following two methods:

Using iterators

This basically means that instead of looping an index from 0 to N-1, we loop an iterator (think of it as a "smart pointer") from the first to the last element. For instance, to print out all elements in a set or a map:

set<int> a;
map<string,string> b;
..
..
for(set<int>::iterator i=a.begin();i!=a.end();++i)
  cout << *i << endl;
for(map<string,string>::iterator i=b.begin();i!=b.end();++i)
  cout << i->first << " => " << i->second << endl;

Note that it's necessary to use i!=a.end() and not i<a.end() as the elements don't necessary have to be stored in order in the memory.

We can here see that i is not a pointer but an iterator: if i was a pointer, ++i would cause i to point to the next element in the memory, while with an iterator it will point to the next element in the container (which does not necessarily lie immediately after the previous element in the memory).

Using for_each

Instead of explicitly creating the for-loop, one can use a function from the algorithm library:

void doit(const int &t) { cout << t << endl; }
..
..
set<int> a; // Can be a vector or map as well
for_each(a.begin(),a.end(),doit); 

That is, for all elements in the range [a.begin(),a.end()), call the function doit. The parameter in doit must be a const reference of the data type in the container.

More about the STL

A complete reference to the STL as well as a more technical introduction to it can be found at http://www.sgi.com/tech/stl/.

Would you like to write a feature?

from: http://www.topcoder.com/index?t=features&c=feat_082803

曾经碰到过让你迷惑不解、类似于int * (* (*fp1) (int) ) [10];这样的变量声明吗？本文将由易到难，一步一步教会你如何理解这种复杂的C/C++声明：我们将从每天都能碰到的较简单的声明入手，然后逐步加入const修饰符和typedef，还有函数指针，最后介绍一个能够让你准确地理解任何C/C++声明的“右左法则”。需要强调一下的是，复杂的C/C++声明并不是好的编程风格；我这里仅仅是教你如何去理解这些声明。注意：为了保证能够在同一行上显示代码和相关注释，本文最好在至少1024x768分辨率的显示器上阅读。 

基础 

让我们从一个非常简单的例子开始，如下： 

int n; 

这个应该被理解为“declare n as an int”（n是一个int型的变量）。 

接下去来看一下指针变量，如下： 

int *p; 

这个应该被理解为“declare p as an int *”（p是一个int *型的变量），或者说p是一个指向一个int型变量的指针。我想在这里展开讨论一下：我觉得在声明一个指针（或引用）类型的变量时，最好将*（或&）写在紧靠变量之前，而不是紧跟基本类型之后。这样可以避免一些理解上的误区，比如： 

int*  p,q; 

第一眼看去，好像是p和q都是int*类型的，但事实上，只有p是一个指针，而q是一个最简单的int型变量。 

我们还是继续我们前面的话题，再来看一个指针的指针的例子： 

char **argv; 

理论上，对于指针的级数没有限制，你可以定义一个浮点类型变量的指针的指针的指针的指针... 

再来看如下的声明： 

int RollNum[30][4]; 
int (*p)[4]=RollNum; 
int *q[5]; 

这里，p被声明为一个指向一个4元素（int类型）数组的指针，而q被声明为一个包含5个元素（int类型的指针）的数组。 

另外，我们还可以在同一个声明中混合实用*和&，如下： 

int **p1; // p1 is a pointer  to a pointer  to an int. 
int *&p2; // p2 is a reference to a pointer  to an int. 
int &*p3; // ERROR: Pointer  to a reference is illegal. 
int &&p4; // ERROR: Reference to a reference is illegal. 

注：p1是一个int类型的指针的指针；p2是一个int类型的指针的引用；p3是一个int类型引用的指针（不合法！）；p4是一个int类型引用的引用（不合法！）。 

const修饰符 

当你想阻止一个变量被改变，可能会用到const关键字。在你给一个变量加上const修饰符的同时，通常需要对它进行初始化，因为以后的任何时候你将没有机会再去改变它。例如： 

const int n=5; 
int const m=10; 

上述两个变量n和m其实是同一种类型的--都是const int（整形恒量）。因为C++标准规定，const关键字放在类型或变量名之前等价的。我个人更喜欢第一种声明方式，因为它更突出了const修饰符的作用。 

当const与指针一起使用时，容易让人感到迷惑。例如，我们来看一下下面的p和q的声明： 

const int *p; 
int const *q; 

他们当中哪一个代表const int类型的指针（const直接修饰int），哪一个代表int类型的const指针（const直接修饰指针）？实际上，p和q都被声明为const int类型的指针。而int类型的const指针应该这样声明： 

int * const r= &n; // n has been declared as an int 

这里，p和q都是指向const int类型的指针，也就是说，你在以后的程序里不能改变*p的值。而r是一个const指针，它在声明的时候被初始化指向变量n（即r=&n;）之后，r的值将不再允许被改变（但*r的值可以改变）。 

组合上述两种const修饰的情况，我们来声明一个指向const int类型的const指针，如下： 

const int * const p=&n // n has been declared as const int 

下面给出的一些关于const的声明，将帮助你彻底理清const的用法。不过请注意，下面的一些声明是不能被编译通过的，因为他们需要在声明的同时进行初始化。为了简洁起见，我忽略了初始化部分；因为加入初始化代码的话，下面每个声明都将增加两行代码。 

char ** p1;          //    pointer to    pointer to    char 
const char **p2;        //    pointer to    pointer to const char 
char * const * p3;       //    pointer to const pointer to    char 
const char * const * p4;    //    pointer to const pointer to const char 
char ** const p5;       // const pointer to    pointer to    char 
const char ** const p6;    // const pointer to    pointer to const char 
char * const * const p7;    // const pointer to const pointer to    char 
const char * const * const p8; // const pointer to const pointer to const char 

注：p1是指向char类型的指针的指针；p2是指向const char类型的指针的指针；p3是指向char类型的const指针；p4是指向const char类型的const指针；p5是指向char类型的指针的const指针；p6是指向const char类型的指针的const指针；p7是指向char类型const指针的const指针；p8是指向const char类型的const指针的const指针。 

typedef的妙用 

typedef给你一种方式来克服“*只适合于变量而不适合于类型”的弊端。你可以如下使用typedef： 

typedef char * PCHAR; 
PCHAR p,q; 

这里的p和q都被声明为指针。（如果不使用typedef，q将被声明为一个char变量，这跟我们的第一眼感觉不太一致！）下面有一些使用typedef的声明，并且给出了解释： 

typedef char * a; // a is a pointer to a char 

typedef a b();   // b is a function that returns 
          // a pointer to a char 

typedef b *c;   // c is a pointer to a function 
          // that returns a pointer to a char 

typedef c d();   // d is a function returning 
          // a pointer to a function 
          // that returns a pointer to a char 

typedef d *e;   // e is a pointer to a function 
          // returning a pointer to a 
          // function that returns a 
          // pointer to a char 

e var[10];     // var is an array of 10 pointers to 
          // functions returning pointers to 
          // functions returning pointers to chars. 

typedef经常用在一个结构声明之前，如下。这样，当创建结构变量的时候，允许你不使用关键字struct（在C中，创建结构变量时要求使用struct关键字，如struct tagPOINT a；而在C++中，struct可以忽略，如tagPOINT b）。 

typedef struct tagPOINT 
{ 
  int x; 
  int y; 
}POINT; 

POINT p; /* Valid C code */ 

函数指针 

函数指针可能是最容易引起理解上的困惑的声明。函数指针在DOS时代写TSR程序时用得最多；在Win32和X-Windows时代，他们被用在需要回调函数的场合。当然，还有其它很多地方需要用到函数指针：虚函数表，STL中的一些模板，Win NT/2K/XP系统服务等。让我们来看一个函数指针的简单例子： 

int (*p)(char); 

这里p被声明为一个函数指针，这个函数带一个char类型的参数，并且有一个int类型的返回值。另外，带有两个float类型参数、返回值是char类型的指针的指针的函数指针可以声明如下： 

char ** (*p)(float, float); 

那么，带两个char类型的const指针参数、无返回值的函数指针又该如何声明呢？参考如下： 

void * (*a[5])(char * const, char * const); 

“右左法则”[重要！！！] 

The right-left rule: Start reading the declaration from the innermost parentheses, go right, and then go left. When you encounter parentheses, the direction should be reversed. Once everything in the parentheses has been parsed, jump out of it. Continue till the whole declaration has been parsed. 

这是一个简单的法则，但能让你准确理解所有的声明。这个法则运用如下：从最内部的括号开始阅读声明，向右看，然后向左看。当你碰到一个括号时就调转阅读的方向。括号内的所有内容都分析完毕就跳出括号的范围。这样继续，直到整个声明都被分析完毕。 

对上述“右左法则”做一个小小的修正：当你第一次开始阅读声明的时候，你必须从变量名开始，而不是从最内部的括号。 

下面结合例子来演示一下“右左法则”的使用。 

int * (* (*fp1) (int) ) [10]; 

阅读步骤： 
1. 从变量名开始 -------------------------------------------- fp1 
2. 往右看，什么也没有，碰到了)，因此往左看，碰到一个* ------ 一个指针 
3. 跳出括号，碰到了(int) ----------------------------------- 一个带一个int参数的函数 
4. 向左看，发现一个* --------------------------------------- （函数）返回一个指针 
5. 跳出括号，向右看，碰到[10] ------------------------------ 一个10元素的数组 
6. 向左看，发现一个* --------------------------------------- 指针 
7. 向左看，发现int ----------------------------------------- int类型 

总结：fp1被声明成为一个函数的指针,该函数返回指向指针数组的指针. 

再来看一个例子： 

int *( *( *arr[5])())(); 

阅读步骤： 
1. 从变量名开始 -------------------------------------------- arr 
2. 往右看，发现是一个数组 ---------------------------------- 一个5元素的数组 
3. 向左看，发现一个* --------------------------------------- 指针 
4. 跳出括号，向右看，发现() -------------------------------- 不带参数的函数 
5. 向左看，碰到* ------------------------------------------- （函数）返回一个指针 
6. 跳出括号，向右发现() ------------------------------------ 不带参数的函数 
7. 向左，发现* --------------------------------------------- （函数）返回一个指针 
8. 继续向左，发现int --------------------------------------- int类型 

总结：？？ 

还有更多的例子： 

float ( * ( *b()) [] )();       // b is a function that returns a 
                    // pointer to an array of pointers 
                    // to functions returning floats. 

void * ( *c) ( char, int (*)());    // c is a pointer to a function that takes 
                    // two parameters: 
                    //   a char and a pointer to a 
                    //   function that takes no 
                    //   parameters and returns 
                    //   an int 
                    // and returns a pointer to void. 

void ** (*d) (int &, 
char **(*)(char *, char **));    // d is a pointer to a function that takes 
                    // two parameters: 
                    //   a reference to an int and a pointer 
                    //   to a function that takes two parameters: 
                    //    a pointer to a char and a pointer 
                    //    to a pointer to a char 
                    //   and returns a pointer to a pointer 
                    //   to a char 
                    // and returns a pointer to a pointer to void 

float ( * ( * e[10]) 
  (int &) ) [5];          // e is an array of 10 pointers to 
                    // functions that take a single 
                    // reference to an int as an argument 
                    // and return pointers to 
                    // an array of 5 floats.  


from: http://www.ieee.org.cn/dispbbs.asp?boardID=61&ID=21651

Pointers to Member Functions are one of C++'s more rarely used features, and are often not well understood even by experienced developers. This is understandable, as their syntax is necessarily rather clumsy and obscure.

While they do not have wide applicability, sometimes member function pointers are useful to solve certain problems, and when they do apply they are often the perfect choice, both for improved performance and to make the code sensible. They work very well to cache the result of a frequently made decision, and to implement a different sort of polymorphism.

I discuss what member function pointers are, how to declare and use them, and give some examples of problems that they solve very well.

Contents

• Abstract
• Introduction
• Member Function Pointers Are Not Just Simple Addresses
• Caching the Outcome of a Decision
• The Performance of Member Function Pointers
• Details About Using Member Function Pointers
• A Different Sort of Polymorphism

Introduction

I don't have any hard numbers on how frequently member function pointers are used. While Ido see others mention them sometimes in Usenet and mailing list posts, I have yet to find someoneelse use one in code I have worked with, so my impression is that they are not commonly applied.

Member function pointers are important because they provide an efficient way to cache the outcome of a decision over which member function to call. They can save time, and in some cases, provide a design alternative that avoids the need to implement such decision caching through memory allocation. I will return to this further on.

Member function pointers allow one to call one of several of an object's member functions indirectly. Each of the functions whose "address" is stored must share the same signature.

I put "address" in quotes because the information stored in a member function pointer is not simply the memory address of the start of the member function's code; conceptually it is an offset into the list of functions declared by the class, and in the case of virtual functions will include a real offset into the vtbl, or table of virtual function pointers.

Member function pointers cannot be dereferenced (have their function called) directly by themselves. They must be called on behalf of some object, that then provides the "this" pointer for use by the member functions.

To illustrate how to declare and call a member function pointer, I will start by giving an example ofdeclaring and dereferencing an ordinary pointer to a non-member function. You declare a functionpointer by giving the prototype of a function it can point to, with the name of the function replacedby (*pointerName). Regular function pointers share the same syntax between C and C++:

void Foo( int anInt, double aDouble );void Bar(){        void (*funcPtr)( int, double ) = &Foo;        (*funcPtr)( 1, 2.0 );}

For regular function pointers, it is optional to use the address-of operator & when taking the address of a function, but it is required for taking the address of member functions. g++ will compile source that leaves it out, but emits a warning.

To declare a pointer to member function, you give the prototype of a function it can point to, as before, but the name of this function is replaced by a construction that scopes the pointer - you give it the name of the class whose member functions it can point to, as (ClassName::*pointerName). Note that a given member function pointer can only point to functions that are members of the class it was declared with. It cannot be applied to an object of a different class even if it has member functions with the same signature.

You dereference a member function pointer by using .* or ->*, supplying a reference or pointer to an object on the left, as appropriate, and the function pointer on the right.

Here is a simple example:

class Foo{        public:                double One( long inVal );                double Two( long inVal );};void main( int argc, char **argv ){	double (Foo::*funcPtr)( long ) = &Foo::One; 	Foo aFoo; 	double result =(aFoo.*funcPtr)( 2 );  	return 0;}

Declaring a member function pointer is clumsy at best and is hard to get right until you have used them for a while. Rather than declaring them using the full prototype each time, it is helpful to use a typedef as I show in the example below.

Member Function Pointers Are Not Just Simple Addresses

Most C and C++ programmers know that it is bad style to assume that a pointer is the same size as an int, although this may often be the case. What is less well known is that pointers of different types may not be the same size as each other. For example, in 16-bit x86 programming near pointers and far pointers may have different sizes, where the far pointers consist of the segment and offset together, while near pointers just have the offset. Member function pointers are generally small structures, that encode information about a function's virtualness, multiple inheritance and so on.

In the case of the example shown below, compiled with g++ 2.95.2 on a PowerPC G3 Mac OS X iBook, I found that the size of the member function pointer I created was eight bytes.

This can result in surprises to the user. For example, Microsoft Visual C++ 6 allows the programmer to make an optimization (which is apparently enabled by default) which can cause member function pointers that are intended to be the same type but are declared in different circumstances to have different sizes. Using the wrong setting for your project may result in an apparently gross code generation bug, because a member function pointer returned by a function that supplies them may have a different size than the recipient function expects, causing bogus data to be overwritten on the stack.

There is an item in VC++'s settings labeled "representation" that has a choice between "best case always" and "most general always". If you work with member function pointers in Visual C++, check the documentation for what these settings do and select the right one; if in doubt, select "most general always".

Caching the Outcome of a Decision

One of the best uses for member function pointers is caching the outcome of a decision over which ofseveral member functions should be called in a particular circumstance. If a decision is always going to yield the same result, then it may be faster and even cleaner to make the decision just once ahead of time, then store the outcome in the form of a member function pointer. This is especially advantageous when the decision will be made repeatedly in a loop.

Here is an admittedly silly (but hopefully clear) example, that shows a member function pointer being used to store the outcome of a decision. It also illustrates the use of typedef:

#include <stdlib.h>#include <iostream>class Test{	public:		Test( long inVal )			: mVal( inVal ){}		long TimesOne() const;		long TimesTwo() const;		long TimesThree() const;	private:		long mVal;};typedef long (Test::*Multiplier)() const;int main( int argc, char **argv ){	using std::cerr;	using std::endl;	using std::cout;	if ( argc != 3 ){		cerr  << "Usage: PtrTest value factor"  << endl;		return 1;	}	Multiplier funcPtr;	switch( atol( argv[ 2 ] ) ){		case 1:			funcPtr = &Test::TimesOne;			break;		case 2:			funcPtr = &Test::TimesTwo;			break;		case 3:			funcPtr = &Test::TimesThree;			break;		default:			cerr << "PtrTest: factor must range from 1 to 3"  << endl;			return 1;	}	cout  << "sizeof( funcPtr )="  << sizeof( funcPtr )  << endl;	Test myTest( atol( argv[ 1 ] ) );	cout << "result="  << (myTest.*funcPtr)()  <<endl;	return 0;}long Test::TimesOne() const{	return mVal;}long Test::TimesTwo() const{	return 2 * mVal;}long Test::TimesThree() const{	return 3 * mVal;}

Now I present an example that does not perform as well as it could because performs a switch decision many times inside a loop, always reaching the same decision. It is a good candidate to refactor by using a pointer to member function. Again it is a silly example but I wanted to be very clear:

#include <exception>class Test{	public:		Test( long inFactor )			: mFactor( inFactor ){}		long TimesOne( long inToMultiply ) const;		long TimesTwo( long inToMultiply ) const;		long TimesThree( long inToMultiply ) const;		long MultiplyIt( long inToMultiply ) const;	private:		long mFactor;};long Test::MultiplyIt( long inToMultiply ) const{	switch( mFactor ){	// decision made repeatedly that always yields the same result		case 1:			return TimesOne( inToMultiply );			break;		case 2:			return TimesTwo( inToMultiply );			break;		case 3:			return TimesThree( inToMultiply );			break;		default:			throw std::exception();	}}void MultiplyThem( long inFactor ){	Test myTest( 2 );		long product;	// Call a function that makes the same decision many times	for ( long i = 0; i < 1000000; ++i )		product = myTest.MultiplyIt( i );}

In most cases where an identical decision is made inside a loop, it is better to refactor the code so that thedecision is outside the loop, and the loop is repeated in each branch of the loop (or packaged inside a subroutine):

void Foo( long value ){	for ( long i = 0; i < 1000000; ++i ){		switch( value ){		// BAD CODE: always reaches the same decision				case 1:				//...				break;			case 2:				//...				break;			case 3:				//...				break;		}	}}

Instead we place the switch outside the loop:

void Foo( long value ){	switch( value ){		// BETTER CODE: decision made only once		case 1:			for ( long i = 0; i < 1000000; ++i ){				//...			}			break;		case 2:			for ( long i = 0; i < 1000000; ++i ){				//...			}			break;		//...	}}

If you want to avoid repeating the loop implementations and each branch of the decision has similar code, you can place them inside subroutines.

Member function pointers are the best solution when it is not practical to refactor this way. Onereason might be that the loop and the decision are in code that belongs to different classes, and you do not want to expose the implementation of the class that makes the decision. Here is the MultiplyIt code above, refactored to use a pointer to member function:

#include <exception>class Test{	public:		Test( long inFactor );		long TimesOne( long inToMultiply ) const;		long TimesTwo( long inToMultiply ) const;		long TimesThree( long inToMultiply ) const;		long MultiplyIt( long inToMultiply ) const;	private:		typedef long (Test::*Multiplier)( long inToMultiply ) const;		long       mFactor;		Multiplier mMultFuncPtr;		static Multiplier GetFunctionPointer( long inFactor );};Test::Test( long inFactor )	: mFactor( inFactor ),	  mMultFuncPtr( GetFunctionPointer( mFactor ) ){	return;}Test::Multiplier Test::GetFunctionPointer( long inFactor ){	switch ( inFactor ){	// Decision only made once!		case 1:			return &Test::TimesOne;			break;		case 2:			 return &Test::TimesTwo;			break;		case 3:			 return &Test::TimesThree;			break;			default:			throw std::exception();	}}			long Test::MultiplyIt( long inToMultiply ) const{	// Using cached decision result	return (this->*mMultFuncPtr)( inToMultiply );	}void MultiplyThem( long inFactor ){	Test myTest( 2 );		long product;	for ( long i = 0; i < 1000000; ++i )		product = myTest.MultiplyIt( i );}

The Performance of Member Function Pointers

Unfortunately, calling a member function by dereferencing a member function is more complicated than simply doing a subroutine jump off a register. The pointers are actually small structures and a little bit of work is required to find the actual address of the subroutine to jump to.

I'm afraid I do not have the g++ source code at hand or I could show you the implementation. I know that in tracing through calls via member function pointers in Metrowerks CodeWarrior for Windows, I found that a call would run a small piece of assembly code provided by CodeWarrior's library. This is pretty fast code, and will run very fast in a tight loop if it stays in the CPU's L1 cache, but it is not as fast as a simple compare and conditional branch.

If the decision your code is making repeatedly is very quick to run, it may not be to your advantage to use a member function pointer. A simple if statement that compares two numeric values, or checks the value of a bool, or possibly a switch statement whose alternatives are all contained in a small range (so it is easy for the compiler to build a jump table) may be quicker than dereferencing a member function pointer.

However, if the decision is complicated or lengthy to arrive at, like string comparison or searching some data structure, then using a pointer to member function may be a big win.

Details About Using Member Function Pointers

You may understand the reasons for implementing pointers to member functions as structures if you see that they can be assigned to the addresses of routines with different kinds of implementations, as long as they have the same calling convention:

class Different{	public:		inline void InlineMember();		virtual void VirtualMember();		void OrdinaryMember();		static void StaticMember();		typedef void (Different::*FuncPtr)();};void Test(){	Different::FuncPtr ptr = &Different::InlineMember;	ptr = &Different::VirtualMember;	ptr = &Different::OrdinaryMember;}

(You may be surprised to see me creating a pointer to an inline function, but this is perfectly normal. If you do this, the compiler will place a normal subroutine version of the inline's implementation in an object file and give you the address of that, so the function pointer does not really point to an inline function at all.)

However, although a static member function may appear to have the same calling convention, it really does not because it is not passed the this pointer - this is passed to your member functions just like any other parameter, but it is not given explicitly in the member function's prototype. You cannot use pointers to member functions to store the address of a static function (use an ordinary, non-member function pointer for that):

void Fails(){        Different::FuncPtr ptr = &Different::StaticMember;}mike% c++ different.cppdifferent.cpp: In function `void Fails()':different.cpp:24: initialization to `void (Different::*)()' from `void (*)()'

Pointers to virtual member functions work just like calling a virtual member function directly - the type whose member function gets called is the dynamic type of the object it is called on behalf of, not the static type of the member function pointer:

#include <iostream>class Base{	public:		virtual void WhoAmI() const;		typedef void (Base::*WhoPtr)() const;};class Derived: public Base{	public:		virtual void WhoAmI() const;};void Base::WhoAmI() const{	std::cout << "I am the Base" << std::endl;}void Derived::WhoAmI() const{	std::cout << "I am the Derived" << std::endl;}int main( int argc, char **argv ){	Base::WhoPtr func = &Base::WhoAmI;	Base theBase;	(theBase.*func)();	Derived theDerived;	(theDerived.*func)();	return 0;}

Running the above program yields the following output:

mike% ./virtualI am the BaseI am the Derived

A Different Sort of Polymorphism

Polymorphism in C++ is usually regarded as always implemented in the form of class heirarchies containing virtual member functions.

An object of a derived class can be supplied to create a pointer or reference to what is apparently the base class; a function pointer lookup in the vtbl is done when calling a virtual member function off a pointer or reference, so that the function called will be based on the dynamic type that the pointer or reference denotes - that is, it will be from the actual type of the object that was allocated, rather than the static type that the base class pointer or reference is declared as.

However, the concept of polymorphism can take a more general meaning than that, and I have seen mailing list postings advocating that it should also include the use of templates that allow source code with identical syntax to be applied to objects of unrelated types. This std::vector can be regarded as a polymorphic container that is parameterized by the type supplied as a parameter when a vector object is declared.

Pointers to member functions can be used to implement a different kind of polymorphism. In the regular type, we determine which member function ultimately gets called by allocating objects of different types, that are related members in an inheritance tree. This is implemented by having the vptr that is a hidden member of the object point at the appropriate vtbl.

In this other form you create objects that are always of the same type, but determine which member function gets called by choosing which member function's address gets assigned to a member function pointer. One interesting advantage is that you can change the behaviour of an object during its lifetime without having to allocate a new one of a different type as you would with the regular sort of inheritance-based polymorphism.

from: http://linuxquality.dotsrc.org/articles/memberpointers/

语法

　　1、还是给一个例子吧！如下：

int main()
{
cout << "In main." << endl;

//定义一个try block，它是用一对花括号{}所括起来的块作用域的代码块
try
{
cout << "在 try block 中, 准备抛出一个异常." << endl;

//这里抛出一个异常（其中异常对象的数据类型是int，值为1）
//由于在try block中的代码是受到监控保护的，所以抛出异常后，程序的
//控制流便转到随后的catch block中
throw 1;

cout << "在 try block 中, 由于前面抛出了一个异常，因此这里的代码是不会得以执行到的" << endl;
}
//这里必须相对应地，至少定义一个catch block，同样它也是用花括号括起来的
catch( int& value )
{
cout << "在 catch block 中, 处理异常错误。异常对象value的值为："<< value << endl;
}

cout << "Back in main. Execution resumes here." << endl;
return 0;

}

　　2、语法很简单吧！的确如此。另外一个try block可以有多个对应的catch block，可为什么要多个catch block呢？这是因为每个catch block匹配一种类型的异常错误对象的处理，多个catch block呢就可以针对不同的异常错误类型分别处理。毕竟异常错误也是分级别的呀！有致命的、有一般的、有警告的，甚至还有的只是事件通知。例子如下：

int main()
{
try
{
cout << "在 try block 中, 准备抛出一个int数据类型的异常." << endl;
throw 1;

cout << "在 try block 中, 准备抛出一个double数据类型的异常." << endl;
throw 0.5;
}
catch( int& value )
{
cout << "在 catch block 中, int数据类型处理异常错误。”<< endl;
}
catch( double& d_value )
{
cout << "在 catch block 中, double数据类型处理异常错误。”<< endl;
}

return 0;
}

　　3、一个函数中可以有多个trycatch结构块，例子如下：

int main()
{
try
{
cout << "在 try block 中, 准备抛出一个int数据类型的异常." << endl;
throw 1;
}
catch( int& value )
{
cout << "在 catch block 中, int数据类型处理异常错误。”<< endl;
}

//这里是二个trycatch结构块，当然也可以有第三、第四个，甚至更多
try
{
cout << "在 try block 中, 准备抛出一个double数据类型的异常." << endl;
throw 0.5;
}
catch( double& d_value )
{
cout << "在 catch block 中, double数据类型处理异常错误。”<< endl;
}

return 0;
}

　　4、上面提到一个try block可以有多个对应的catch block，这样便于不同的异常错误分类处理，其实这只是异常错误分类处理的方法之一（暂且把它叫做横向展开的吧！）。另外还有一种就是纵向的，也即是分层的、trycatch块是可以嵌套的，当在低层的trycatch结构块中不能匹配到相同类型的catch block时，它就会到上层的trycatch块中去寻找匹配到正确的catch block异常处理模块。例程如下：

int main()
{
try
{
//这里是嵌套的trycatch结构块
try
{
cout << "在 try block 中, 准备抛出一个int数据类型的异常." << endl;
throw 1;
}
catch( int& value )
{
cout << "在 catch block 中, int数据类型处理异常错误。”<< endl;
}

cout << "在 try block 中, 准备抛出一个double数据类型的异常." << endl;
throw 0.5;
}
catch( double& d_value )
{
cout << "在 catch block 中, double数据类型处理异常错误。”<< endl;
}

return 0;
}

　　5、讲到是trycatch块是可以嵌套分层的，并且通过异常对象的数据类型来进行匹配，以找到正确的catch block异常错误处理代码。这里就不得不详细叙述一下通过异常对象的数据类型来进行匹配找到正确的catch block的过程。

　　（1） 首先在抛出异常的trycatch块中查找catch block，按顺序先是与第一个catch block块匹配，如果抛出的异常对象的数据类型与catch block中传入的异常对象的临时变量（就是catch语句后面参数）的数据类型完全相同，或是它的子类型对象，则匹配成功，进入到catch block中执行；否则到二步；

　　 （2） 如果有二个或更多的catch block，则继续查找匹配第二个、第三个，乃至最后一个catch block，如匹配成功，则进入到对应的catch block中执行；否则到三步；

　　 （3） 返回到上一级的trycatch块中，按规则继续查找对应的catch block。如果找到，进入到对应的catch block中执行；否则到四步；

　　 （4） 再到上上级的trycatch块中，如此不断递归，直到匹配到顶级的trycatch块中的最后一个catch block，如果找到，进入到对应的catch block中执行；否则程序将会执行terminate()退出。

　　另外分层嵌套的trycatch块是可以跨越函数作用域的，例程如下：

void Func() throw()
{
//这里实际上也是嵌套在里层的trycatch结构块
try
{
cout << "在 try block 中, 准备抛出一个int数据类型的异常." << endl;
//由于这个trycatch块中不能找到匹配的catch block，所以
//它会继续查找到调用这个函数的上层函数的trycatch块。
throw 1;
}
catch( float& value )
{
cout << "在 catch block 中, int数据类型处理异常错误。”<< endl;
}
}

int main()
{
try
{
Func();

cout << "在 try block 中, 准备抛出一个double数据类型的异常." << endl;
throw 0.5;
}
catch( double& d_value )
{
cout << "在 catch block 中, double数据类型处理异常错误。”<< endl;
}
catch( int& value )
{
//这个例子中，Func()函数中抛出的异常会在此被处理
cout << "在 catch block 中, int数据类型处理异常错误。”<< endl;
}

return 0;
}

　　6、刚才提到，嵌套的trycatch块是可以跨越函数作用域的，其实这里面还有另外一层涵义，就是抛出异常对象的函数中并不一定必须存在trycatch块，它可以是调用这个函数的上层函数中存在trycatch块，这样这个函数的代码也同样是受保护、受监控的代码；当然即便是上层调用函数不存在trycatch块，也只是不能找到处理这类异常对象错误处理的catch block而已，例程如下：

void Func() throw()
{
//这里实际上也是嵌套在里层的trycatch结构块
//由于这个函数中是没有trycatch块的，所以它会查找到调用这个函数的上
//层函数的trycatch块中。
throw 1;
}

int main()
{
try
{
//调用函数，注意这个函数里面抛出一个异常对象
Func();

cout << "在 try block 中, 准备抛出一个double数据类型的异常." << endl;
throw 0.5;
}
catch( double& d_value )
{
cout << "在 catch block 中, double数据类型处理异常错误。”<< endl;
}
catch( int& value )
{
//这个例子中，Func()函数中抛出的异常会在此被处理
cout << "在 catch block 中, int数据类型处理异常错误。”<< endl;
}

//如果这里调用这个函数，那么由于main()已经是调用栈的顶层函数，因此不能找
//到对应的catch block，所以程序会执行terminate()退出。
Func();
// [特别提示]：在C++标准中规定，可以在程序任何地方throw一个异常对象，
// 并不要求一定只能是在受到try block监控保护的作用域中才能抛出异常，但
// 如果在程序中出现了抛出的找不到对应catch block的异常对象时，C++标
// 准中规定要求系统必须执行terminate()来终止程序。
// 因此这个例程是可以编译通过的，但运行时却会异常终止。这往往给软件
// 系统带来了不安全性。与此形成对比的是java中提供的异常处理模型却是不
// 永许出现这样的找不到对应catch block的异常对象，它在编译时就给出错误
// 提示，所以java中提供的异常处理模型往往比C++要更完善，后面的章节
// 会进一步对这两种异常处理模型进行一个详细的分析比较。
return 0;
}

　　朋友们！C++中的异常处理模型的语法很简单吧！就是那么（one、two、three、…哈哈！数数呢！）简单的几条规则。怪不得主人公阿愚这么快就喜欢上她了，而且还居然像一个思想家一样总结出一条感想：好的东西往往都是简单的，简单就是美吗！哈哈！还挺臭美的。

　　下一集主人公阿愚愿和大家一起讨论一下C++中的异常处理中的一种特殊的catch用法，那就是关于catch(…)大探秘。

from: http://51cmm.csai.cn/ExpertEyes/No137.htm

    关键字mutable是C++中一个不常用的关键字,他只能用于类的非静态和非常量数据成员。我们知道一个对象的状态由该对象的非静态数据成员决定,所以随着数据成员的改变,对像的状态也会随之发生变化!

　　如果一个类的成员函数被声明为const类型,表示该函数不会改变对象的状态,也就是该函数不会修改类的非静态数据成员.但是有些时候需要在该类函数中对类的数据成员进行赋值.这个时候就需要用到mutable关键字了

　　例如:

 　　class Demo
　　{
　　public:
　　Demo(){}
　　~Demo(){}
　　public:
　　bool getFlag() const
　　{
　　m_nAccess++;
　　return m_bFlag;
　　}
　　private:
　　int  m_nAccess;
　　bool m_bFlag;
　　};
　　int main()
　　{
　　return 0;
　　}
 

　　编译上面的代码会出现 error C2166: l-value specifies const object的错误
　　说明在const类型的函数中改变了类的非静态数据成员.

　　这个时候需要使用mutable来修饰一下要在const成员函数中改变的非静态数据成员
　　m_nAccess,代码如下:

 　　class Demo
　　{
　　public:
　　Demo(){}
　　~Demo(){}
　　public:
　　bool getFlag() const
　　{
　　m_nAccess++;
　　return m_bFlag;
　　}
　　private:
　　mutable int  m_nAccess;
　　bool m_bFlag;
　　};
　　int main()
　　{
　　return 0;
　　}
 

　　这样再重新编译的时候就不会出现错误了!

volatile关键字

　　volatile是c/c++中一个鲜为人知的关键字,该关键字告诉编译器不要持有变量的临时拷贝,它可以适用于基础类型

　　如：int,char,long......也适用于C的结构和C++的类。当对结构或者类对象使用volatile修饰的时候，结构或者类的所有成员都会被视为volatile.

　　使用volatile并不会否定对CRITICAL_SECTION,Mutex,Event等同步对象的需要

　　例如：

　　int i;
　　i = i + 3;

　　无论如何，总是会有一小段时间，i会被放在一个寄存器中，因为算术运算只能在寄存器中进行。一般来说，volatitle关键字适用于行与行之间，而不是放在行内。

　　我们先来实现一个简单的函数，来观察一下由编译器产生出来的汇编代码中的不足之处，并观察volatile关键字如何修正这个不足之处。在这个函数体内存在一个busy loop(所谓busy loop也叫做busy waits,是一种高度浪费CPU时间的循环方法)

 　　void getKey(char* pch)
　　{
　　while (*pch == 0)
　　;
　　}

　　当你在VC开发环境中将最优化选项都关闭之后，编译这个程序，将获得以下结果(汇编代码);      

    while (*pch == 0)
　　$L27
　　; Load the address stored in pch
　　mov eax, DWORD PTR _pch$[ebp]
　　; Load the character into the EAX register
　　movsx eax, BYTE PTR [eax]
　　; Compare the value to zero
　　test eax, eax
　　; If not zero, exit loop
　　jne $L28
　　;
　　jmp $L27
　　$L28
　　;}

　　这段没有优化的代码不断的载入适当的地址，载入地址中的内容，测试结果。效率相当的低，但是结果非常准确

　　现在我们再来看看将编译器的所有最优化选项开关都打开以后，重新编译程序，生成的汇编代码，和上面的代码

　　比较一下有什么不同

 　　;{
　　; Load the address stored in pch
　　mov eax, DWORD PTR _pch$[esp-4]
　　; Load the character into the AL register
　　movsx al, BYTE PTR [eax]
　　; while (*pch == 0)
　　; Compare the value in the AL register to zero
　　test al, al
　　; If still zero, try again
　　je SHORT $L84
　　;
　　;}

    从代码的长度就可以看出来，比没有优化的情况要短的多。需要注意的是编译器把MOV指令放到了循环之外。这在单线程中是一个非常好的优化，但是，在多线程应用程序中，如果另一个线程改变了变量的值，则循环永远不会结束。被测试的值永远被放在寄存器中，所以该段代码在多线程的情况下，存在一个巨大的BUG。解决方法是重新

　　写一次getKey函数，并把参数pch声明为volatile,代码如下：

 　　void getKey(volatile char* pch)
　　{
　　while (*pch == 0)
　　;
　　}

　　这次的修改对于非最优化的版本没有任何影响，下面请看最优化后的结果：

 　　;{
　　; Load the address stored in pch
　　mov eax, DWORD PTR _pch$[esp-4]
　　;       while (*pch == 0)
　　$L84:
　　; Directly compare the value to zero
　　cmp BYTE PTR [eax], 0
　　; If still zero, try again
　　je SHORT $L84
　　;
　　;}

　　这次的修改结果比较完美，地址不会改变，所以地址声明被移动到循环之外。地址内容是volatile,所以每次循环之中它不断的被重新检查。

　　把一个const volatile变量作为参数传递给函数是合法的。如此的声明意味着函数不能改变变量的值，但是变量的值却可以被另一个线程在任何时间改变掉。

　　explicit关键字

　　我们在编写应用程序的时候explicit关键字基本上是很少使用,它的作用是"禁止单参数构造函数"被用于自动型别转换,其中比较典型的例子就是容器类型,在这种类型的构造函数中你可以将初始长度作为参数传递给构造函数.

　　例如:
　　你可以声明这样一个构造函数

 　　class Array
　　{
　　public:
　　explicit Array(int size);
　　......
　　};

　　在这里explicit关键字起着至关重要的作用,如果没有这个关键字的话,这个构造函数有能力将int转换成Array.一旦这种情况发生,你可以给Array支派一个整数值而不会引起任何的问题,比如:

 　　Array arr;
　　...
　　arr = 40;

　　此时,C++的自动型别转换会把40转换成拥有40个元素的Array,并且指派给arr变量,这个结果根本就不是我们想要的结果.如果我们将构造函数声明为explicit,上面的赋值操作就会导致编译器报错,使我们可以及时发现错误.需要注意的是:explicit同样也能阻止"以赋值语法进行带有转型操作的初始化";

例如:
　　Array arr(40);//正确
　　Array arr = 40;//错误

　　看一下以下两种操作:
　　X x;
　　Y y(x);//显式类型转换
　　另一种
　　X x;
　　Y y = x;//隐式类型转换

　　这两种操作存在一个小小的差别,第一种方式式通过显式类型转换,根据型别x产生了型别Y的新对象;第二种方式通过隐式转换产生了一个型别Y的新对象.
　　explicit关键字的应用主要就是上面所说的构造函数定义种,参考该关键字的应用可以看看STL源代码,其中大量使用了该关键字

　　__based关键字

　　该关键字主要用来解决一些和共享内存有关的问题,它允许指针被定义为从某一点开始算的32位偏移值,而不是内存种的绝对位置

　　举个例子:

 　　typedef struct tagDEMOSTRUCT {
　　int a;
　　char sz[10];
　　} DEMOSTRUCT, * PDEMOSTRUCT;
　　HANDLE hFileMapping = CreateFileMapping(...);
　　LPVOID lpShare = (LPDWORD)MapViewOfFile(...);

　　DEMOSTRUCT __based(lpShare)* lpDemo;
 

      上面的例子声明了一个指针lpDemo,内部储存的是从lpShare开始的偏移值,也就是lpHead是以lpShare为基准的偏移值.上面的例子种的DEMOSTRUCT只是随便定义的一个结构,用来代表任意的结构.

　　虽然__based指针使用起来非常容易,但是,你必须在效率上付出一定的代价.每当你用__based指针处理数据,CPU都必须为它加上基地址,才能指向真正的位置.

　　在这里我只是介绍了几个并不时很常见的关键字的意义即用法,其他那些常见的关键字介绍他们的文章已经不少了在这里就不再一一介绍了.希望这些内容能对大家有一定的帮助。


from: http://www.softhouse.com.cn/html/200507/2005070811001700009110.html

Our reference counting implementation looks kind of like this:

 1/**
 2 * Reference-counted object.  When its reference count goes to
 3 * zero, it destroys itself.
 4 */
 5class CRefCountedObject
 6{
 7public:
 8    CRefCountedObject()
 9    {
10        m_nRefCount = 0;
11    }
12
13    virtual ~CRefCountedObject()
14    {
15        // CRefCountedObject's can be created on the stack,
16        // where they will be destroyed by falling out of scope.
17        // This assert checks the implicit assumption that no one
18        // is still interested in the object when it is destroyed.
19        ASSERT(m_nRefCount == 0);
20    }
21
22    /** Declare your interest in this object: ups the refcount.
23     */
24    void Retain()
25    {
26        m_nRefCount++;
27    }
28
29    /** Declare your lack of interest in this object: if you were
30     *  the last interested party, the object is destroyed.
31     */
32    void Release()
33    {
34        m_nRefCount--;
35        if (m_nRefCount== 0) {
36            delete this;
37        }
38    }
39
40private:
41    int m_nRefCount;
42};
43
44/**
45 * Smart pointer, templated to a particular object class.
46 */
47template <class TObject>
48class CPtr
49{
50public:
51    // .. lots of stuff omitted ..
52
53    /** Assignment operator.  Manage the refcounts on the old and
54     *  new objects.
55     */
56    TObject *operator=(TObject *p)
57    {
58        if (m_p != p) {
59            if (p != NULL) {
60                p->Retain();
61            }
62            if (m_p != NULL) {
63                m_p->Release();
64            }
65            m_p = p;
66        }
67        return m_p;
68    }
69
70    //.. lots of stuff omitted ..
71};

(Note: this is a simplified version of our actual code, and some of the simplifications mean that it will not work properly, but not in ways that affect the narrative here. For example, don't try this code with multiple threads, or with multiple inheritance. I'm taking some expository license. Don't bug me about it!)

The assert that fired is on line 19: it's designed to protect against allocating reference counted objects on the stack. The problem with a stack-allocated refcounted object is that the object will be destroyed when it falls out of scope, regardless of the reference count. For our reference counting to work right, the only thing that should destroy an object is the delete on line 36. With a stack allocated object, the compiler destroys the object for us, so smart pointers can exist which point to freed memory:

100{
101    CPtr<CRefCountedObject> pObj;
102
103    //.. blah blah ..
104
105    if (blah blah) {
106        CRefCountedObject stackobj;
107        pObj = stackobj;
108    }
109
110    // pObj is invalid at this point.
111}

The object stackobj is created at line 106, and then destroyed at line 108 (when it falls out of scope), but pObj still has a pointer to it. When stackobj is destroyed, its reference count is 1, so the assert in the CRefCountedObject destructor will fire. All is well.

So when that assertion fired the other day, we thought we understood the problem. Just look up the stack, find the stack allocated refcounted object, and change it to a heap allocated object. But when we looked into it, there was no stack allocated object. So who was destroying the refcounted object before its time? How does a heap allocated object get destroyed other than using delete on it?

Digging deeper, we rediscovered a C++ detail that we had forgotten. Turns out we had some code that boiled down to this:

200class CBadObject: public CRefCountedObject
201{
202    //.. blah blah ..
203};
204
205CPtr<CBadObject> pGlobalBad;
206
207CBadObject::CBadObject()
208{
209    pGlobalBad = this;
210
211    DoSomethingWhichThrowsAnException();
212}

This object's constructor assigned itself to a smart pointer outside itself, then threw an exception. C++ semantics state that if a constructor of a heap allocated object throws an exception, that the object's destructor is called. Since CBadObject derives from CRefCountedObject, the CRefCountedObject destructor is called. It checks the reference count, sees that it is not zero (it's one, because pGlobalBad has called Retain, but hasn't called Release), and fires the assertion.

Updated May 2005: Actually, the correct statement of C++ semantics is that if a constructor throws an exception, a destructor is called for all the base classes that had been successfully constructed. In this case, the CBadObject destructor is not called (because the CBadObject constructor didn't finish), but the CRefCountedObject destructor is called, because its constructor completed. It's the CRefCountedObject destructor which causes the trouble here. More about this at More C++ constructor trivia.

So the lesson is: try not to throw exceptions from constructors, or at least understand that they will destroy the object for you.

Updated May 2005: Again, this is not correct. The real lesson is that throwing exceptions from constructors is perfectly legal, and C++ is precisely engineered to specify exactly what will happen. But you may be surprised by what happens. In particular, you may have objects in "impossible" states.

It just goes to show you:

You learn something new every day, no matter how hard you try.

By the way: there were two things we did to fix the problem. Do you know what they were? The first was to move most of the code out of the constructor, so that hard stuff happens in regular methods. The second was to add to the comment in CRefCountedObject's destructor:

13    virtual ~CRefCountedObject()
14    {
15        // CRefCountedObject's can be created on the stack,
16        // where they will be destroyed by falling out of scope.
17        // This assert checks the implicit assumption that no one
18        // is still interested in the object when it is destroyed.
19        // The other way this can happen is if a constructor
20        // fails, but it has already assigned itself to a CPtr
21        // someplace.  When a C++ constructor fails, the compiler
22        // automatically destroys the object.
23        ASSERT(m_nRefCount == 0);
24    }

That way, future generations might be spared the head-scratching.

from: http://www.nedbatchelder.com/blog/20041202T070735.html

• What are they?
• Why would I use them?
  • Less bugs
  • Exception Safety
  • Garbage collection
  • Efficiency
  • STL containers
• Which one should I use?
  • Local variables
  • Class members
  • STL containers
  • Explicit ownership transfer
  • Big objects
  • Summary
• Conclusion

What are they?

To look and feel like pointers, smart pointers need to have the same interface that pointers do: they need to support pointer operations like dereferencing (operator *) and indirection (operator ->). An object that looks and feels like something else is called a proxy object, or just proxy. The proxy pattern and its many uses are described in the books Design Patterns and Pattern Oriented Software Architecture.

To be smarter than regular pointers, smart pointers need to do things that regular pointers don't. What could these things be? Probably the most common bugs in C++ (and C) are related to pointers and memory management: dangling pointers, memory leaks, allocation failures and other joys. Having a smart pointer take care of these things can save a lot of aspirin...

The simplest example of a smart pointer is auto_ptr, which is included in the standard C++ library. You can find it in the header <memory>, or take a look at Scott Meyers' auto_ptr implementation. Here is part of auto_ptr's implementation, to illustrate what it does:

template <class T> class auto_ptr
{
    T* ptr;
public:
    explicit auto_ptr(T* p = 0) : ptr(p) {}
    ~auto_ptr()                 {delete ptr;}
    T& operator*()              {return *ptr;}
    T* operator->()             {return ptr;}
    // ...
};

For the user of auto_ptr, this means that instead of writing:

void foo()
{
    MyClass* p(new MyClass);
    p->DoSomething();
    delete p;
}

void foo()
{
    auto_ptr<MyClass> p(new MyClass);
    p->DoSomething();
}

What does this buy you? See the next section.

Why would I use them?

Why: Less bugs

Automatic initialization. Another nice thing is that you don't need to initialize the auto_ptr to NULL, since the default constructor does that for you. This is one less thing for the programmer to forget.

Dangling pointers. A common pitfall of regular pointers is the dangling pointer: a pointer that points to an object that is already deleted. The following code illustrates this situation:

MyClass* p(new MyClass);
MyClass* q = p;
delete p;
p->DoSomething();   // Watch out! p is now dangling!
p = NULL;           // p is no longer dangling
q->DoSomething();   // Ouch! q is still dangling!

template <class T>
auto_ptr<T>& auto_ptr<T>::operator=(auto_ptr<T>& rhs)
{
    if (this != &rhs) {
        delete ptr;
        ptr = rhs.ptr;
        rhs.ptr = NULL;
    }
    return *this;
}

• Create a new copy of the object pointed by p, and have q point to this copy. This strategy is implemented in copied_ptr.h.
• Ownership transfer: Let both p and q point to the same object, but transfer the responsibility for cleaning up ("ownership") from p to q. This strategy is implemented in owned_ptr.h.
• Reference counting: Maintain a count of the smart pointers that point to the same object, and delete the object when this count becomes zero. So the statement q = p causes the count of the object pointed by p to increase by one. This strategy is implemented in counted_ptr.h. Scott Meyers offers another reference counting implementation in his book More Effective C++.
• Reference linking: The same as reference counting, only instead of a count, maintain a circular doubly linked list of all smart pointers that point to the same object. This strategy is implemented in linked_ptr.h.
• Copy on write: Use reference counting or linking as long as the pointed object is not modified. When it is about to be modified, copy it and modify the copy. This strategy is implemented in cow_ptr.h.

Why: Exception Safety

void foo()
{
    MyClass* p(new MyClass);
    p->DoSomething();
    delete p;
}

If we use a smart pointer, however, p will be cleaned up whenever it gets out of scope, whether it was during the normal path of execution or during the stack unwinding caused by throwing an exception.

But isn't it possible to write exception safe code with regular pointers? Sure, but it is so painful that I doubt anyone actually does this when there is an alternative. Here is what you would do in this simple case:

void foo()
{
    MyClass* p;
    try {
        p = new MyClass;
        p->DoSomething();
        delete p;
    }
    catch (...) {
        delete p;
        throw;
    }
}

Why: Garbage collection

Why: Efficiency

A common strategy for using memory more efficiently is copy on write (COW). This means that the same object is shared by many COW pointers as long as it is only read and not modified. When some part of the program tries to modify the object ("write"), the COW pointer creates a new copy of the object and modifies this copy instead of the original object. The standard string class is commonly implemented using COW semantics (see the <string> header).

string s("Hello");

string t = s;       // t and s point to the same buffer of characters

t += " there!";     // a new buffer is allocated for t before
                    // appending " there!", so s is unchanged.

Optimized allocation schemes are possible when you can make some assumptions about the objects to be allocated or the operating environment. For example, you may know that all the objects will have the same size, or that they will all live in a single thread. Although it is possible to implement optimized allocation schemes using class-specific new and delete operators, smart pointers give you the freedom to choose whether to use the optimized scheme for each object, instead of having the scheme set for all objects of a class. It is therefore possible to match the allocation scheme to different operating environments and applications, without modifying the code for the entire class.

Why: STL containers

class Base { /*...*/ };
class Derived : public Base { /*...*/ };

Base b;
Derived d;
vector<Base> v;

v.push_back(b); // OK
v.push_back(d); // error

vector<Base*> v;

v.push_back(new Base);      // OK
v.push_back(new Derived);   // OK too

// cleanup:
for (vector<Base*>::iterator i = v.begin(); i != v.end(); ++i)
    delete *i;

Smart pointers are a possible solution, as illustrated below. (An alternative solution is a smart container, like the one implemented in pointainer.h.)

vector< linked_ptr<Base> > v;
v.push_back(new Base);      // OK
v.push_back(new Derived);   // OK too

// cleanup is automatic

Note: STL containers may copy and delete their elements behind the scenes (for example, when they resize themselves). Therefore, all copies of an element must be equivalent, or the wrong copy may be the one to survive all this copying and deleting. This means that some smart pointers cannot be used within STL containers, specifically the standard auto_ptr and any ownership-transferring pointer. For more info about this issue, see C++ Guru of the Week #25.

Which one should I use?

Which: Local variables

Which: Class members

class MyClass
{
    auto_ptr<int> p;
    // ...
};

MyClass x;
// do some meaningful things with x
MyClass y = x; // x.p now has a NULL pointer

Note that using a reference counted or reference linked pointer means that if y changes the member, this change will also affect x! Therefore, if you want to save memory, you should use a COW pointer and not a simple reference counted/linked pointer.

Which: STL containers

It is important to consider the characteristics of the specific garbage collection scheme used. Specifically, reference counting/linking can leak in the case of circular references (i.e., when the pointed object itself contains a counted pointer, which points to an object that contains the original counted pointer). Its advantage over other schemes is that it is both simple to implement and deterministic. The deterministic behavior may be important in some real time systems, where you cannot allow the system to suddenly wait while the garbage collector performs its housekeeping duties.

Generally speaking, there are two ways to implement reference counting: intrusive and non-intrusive. Intrusive means that the pointed object itself contains the count. Therefore, you cannot use intrusive reference counting with 3-rd party classes that do not already have this feature. You can, however, derive a new class from the 3-rd party class and add the count to it. Non-intrusive reference counting requires an allocation of a count for each counted object. The counted_ptr.h is an example of non-intrusive reference counting.

Reference linking does not require any changes to be made to the pointed objects, nor does it require any additional allocations. A reference linked pointer takes a little more space than a reference counted pointer - just enough to store one or two more pointers.

Both reference counting and reference linking require using locks if the pointers are used by more than one thread of execution.

Which: Explicit ownership transfer

Using an owned pointer as the function argument is an explicit statement that the function is taking ownership of the pointer.

Which: Big objects

Which: Summary

Conclusion

Feel free to use my own smart pointers in your code, and do tell me if you are having any problems with them.
The Boost C++ libraries include some smart pointers, which are more rigorously tested and actively maintained. Do try them first, if they are appropriate for your needs.

from: http://ootips.org/yonat/4dev/smart-pointers.html

• Introduction
• The basics
• The const modifier
• The subtleties of typedef
• Function pointers
• The right-left rule [Important]
• Further examples
• Suggested reading
• Credits

Introduction

Ever came across a declaration like int * (* (*fp1) (int) ) [10]; or something similar that you couldn't fathom? This article will teach you to interpret C/C++ declarations, starting from mundane ones (please bear with me here) and moving on to very complex ones. We shall see examples of declarations that we come across in everyday life, then move on to the troublesome const modifier and typedef, conquer function pointers, and finally see the right-left rule, which will allow you to interpret any C/C++ declaration accurately. I would like to emphasize that it is not considered good practice to write messy code like this; I'm merely teaching you how to understand such declarations. Note: This article is best viewed with a minimum resolution of 1024x768, in order to ensure the comments don't run off into the next line. Code blocks look weird if viewed in a non-maximized window in Mozilla and Opera- sorry, I can't help it.

[Back to contents]

The basics

Let me start with a very simple example. Consider the declaration:

int n;

This should be interpreted as "declare n as an int".

Coming to the declaration of a pointer variable, it would be declared as something like:

int *p;

This is to be interpreted as "declare p as an int * i.e., as a pointer to an int". I'll need to make a small note here - it is always better to write a pointer (or reference) declaration with the * (or &) preceding the variable rather than following the base type. This is to ensure there are no slip-ups when making declarations like:

int* p,q;

At first sight, it looks like p and q have been declared to be of type int *, but actually, it is only p that is a pointer, q is a simple int.

We can have a pointer to a pointer, which can be declared as:

char **argv;

In principle, there is no limit to this, which means you can have a pointer to a pointer to a pointer to a pointer to a float, and so on.

Consider the declarations:

int RollNum[30][4];
int (*p)[4]=RollNum;
int *q[5];

Here, p is declared as a pointer to an array of 4 ints, while q is declared as an array of 5 pointers to integers.

We can have a mixed bag of *s and &s in a single declaration, as explained below:

int **p1;  //  p1 is a pointer   to a pointer   to an int.
int *&p2;  //  p2 is a reference to a pointer   to an int.
int &*p3;  //  ERROR: Pointer    to a reference is illegal.
int &&p4;  //  ERROR: Reference  to a reference is illegal.

[Back to contents]

The const modifier

The const keyword is used when you want to prevent a variable (oops, that's an oxymoron) from being modified. When you declare a const variable, you need to initialize it, because you can't give it a value at any other time.

const int n=5;
int const m=10;

The two variables n and m above are both of the same type - constant integers. This is because the C++ standard states that the const keyword can be placed before the type or the variable name. Personally, I prefer using the former style, since it makes the const modifier stand out more clearly.

const is a bit more confusing when it comes to dealing with pointers. For instance, consider the two variables p and q in the declaration below:

const int *p;
int const *q;

Which of them is a pointer to a const int, and which is a const pointer to an int? Actually, they're both pointers to const ints. A const pointer to an int would be declared as:

int * const r= &n; // n has been declared as an int

Here, p and q are pointers to a const int, which means that you can't change the value of *p. r is a const pointer, which means that once declared as above, an assignment like r=&m; would be illegal (where m is another int) but the value of *r can be changed.

To combine these two declarations to declare a const pointer to a const int, you would have to declare it as:

const int * const p=&n // n has been declared as const int

The following declarations should clear up any doubts over how const is to be interpreted. Please note that some of the declarations will NOT compile as such unless they are assigned values during declaration itself. I have omitted them for clarity, and besides, adding that will require another two lines of code for each example.

char ** p1;                    //        pointer to       pointer to       char
const char **p2;               //        pointer to       pointer to const char
char * const * p3;             //        pointer to const pointer to       char
const char * const * p4;       //        pointer to const pointer to const char
char ** const p5;              //  const pointer to       pointer to       char
const char ** const p6;        //  const pointer to       pointer to const char
char * const * const p7;       //  const pointer to const pointer to       char
const char * const * const p8; //  const pointer to const pointer to const char

[Back to contents]

The subtleties of typedef

typedef allows you a way to overcome the *-applies-to-variable-not-type rule. If you use a typedef like:

typedef char * PCHAR;
PCHAR p,q;

both p and q become pointers. If the typedef had not been used, q would be a char, which is counter-intuitive.

Here are a few declarations made using typedef, along with the explanation:

typedef char * a;  // a is a pointer to a char

typedef a b();     // b is a function that returns
                   // a pointer to a char

typedef b *c;      // c is a pointer to a function
                   // that returns a pointer to a char

typedef c d();     // d is a function returning
                   // a pointer to a function
                   // that returns a pointer to a char

typedef d *e;      // e is a pointer to a function 
                   // returning  a pointer to a 
                   // function that returns a 
                   // pointer to a char

e var[10];         // var is an array of 10 pointers to 
                   // functions returning pointers to 
                   // functions returning pointers to chars.

typedefs are usually used with structure declarations as shown below. The following structure declaration allows you to omit the struct keyword when you create structure variables even in C, as is normally done in C++.

typedef struct tagPOINT
{
    int x;
    int y;
}POINT;

POINT p; /* Valid C code */

[Back to contents]

Function pointers

Function pointers are probably the greatest source of confusion when it comes to interpreting declarations. Function pointers were used in the old DOS days for writing TSRs; in the Win32 world and X-Windows, they are used in callback functions. There are lots of other places where function pointers are used: virtual function tables, some templates in STL, and Win NT/2K/XP system services. Let's see a simple example of a function pointer:

int (*p)(char);

This declares p as a pointer to a function that takes a char argument and returns an int.

A pointer to a function that takes two floats and returns a pointer to a pointer to a char would be declared as:

char ** (*p)(float, float);

How about an array of 5 pointers to functions that receive two const pointers to chars and return a void pointer?

void * (*a[5])(char * const, char * const);

[Back to contents]

The right-left rule [Important]

This is a simple rule that allows you to interpret any declaration. It runs as follows:

Start reading the declaration from the innermost parentheses, go right, and then go left. When you encounter parentheses, the direction should be reversed. Once everything in the parentheses has been parsed, jump out of it. Continue till the whole declaration has been parsed.

One small change to the right-left rule: When you start reading the declaration for the first time, you have to start from the identifier, and not the innermost parentheses.

Take the example given in the introduction:

int * (* (*fp1) (int) ) [10];

This can be interpreted as follows:

1. Start from the variable name -------------------------- fp1
2. Nothing to right but ) so go left to find * -------------- is a pointer
3. Jump out of parentheses and encounter (int) --------- to a function that takes an int as argument
4. Go left, find * ---------------------------------------- and returns a pointer
5. Jump put of parentheses, go right and hit [10] -------- to an array of 10
6. Go left find * ----------------------------------------- pointers to
7. Go left again, find int -------------------------------- ints.

Here's another example:

int *( *( *arr[5])())();

1. Start from the variable name --------------------- arr
2. Go right, find array subscript --------------------- is an array of 5
3. Go left, find * ----------------------------------- pointers
4. Jump out of parentheses, go right to find () ------ to functions
5. Go left, encounter * ----------------------------- that return pointers
6. Jump out, go right, find () ----------------------- to functions
7. Go left, find * ----------------------------------- that return pointers
8. Continue left, find * ----------------------------- to ints.

[Back to contents]

Further examples

The following examples should make it clear:

float ( * ( *b()) [] )();              // b is a function that returns a 
                                       // pointer to an array of pointers
                                       // to functions returning floats.

void * ( *c) ( char, int (*)());       // c is a pointer to a function that takes
                                       // two parameters:
                                       //     a char and a pointer to a
                                       //     function that takes no
                                       //     parameters and returns
                                       //     an int
                                       // and returns a pointer to void.

void ** (*d) (int &, 
  char **(*)(char *, char **));        // d is a pointer to a function that takes
                                       // two parameters:
                                       //     a reference to an int and a pointer
                                       //     to a function that takes two parameters:
                                       //        a pointer to a char and a pointer
                                       //        to a pointer to a char
                                       //     and returns a pointer to a pointer 
                                       //     to a char
                                       // and returns a pointer to a pointer to void

float ( * ( * e[10]) 
    (int &) ) [5];                    // e is an array of 10 pointers to 
                                       // functions that take a single
                                       // reference to an int as an argument 
                                       // and return pointers to
                                       // an array of 5 floats.

[Back to contents]

Suggested reading

• A Prelude to pointers by Nitron.
• cdecl is an excellent utility that explains variable declarations and does much more. You can download the Windows port of cdecl from here.

[Back to contents]

Credits

I got the idea for this article after reading a thread posted by Jörgen Sigvardsson about a pointer declaration that he got in a mail, which has been reproduced in the introduction. Some of the examples were taken from the book "Test your C skills" by Yashvant Kanetkar. Some examples of function pointers were given by my cousin Madhukar M Rao. The idea of adding examples with mixed *s and &s and typedef with structs was given by my cousin Rajesh Ramachandran. Chris Hills came up with modifications to the right-left rule and the way in which some examples were interpreted.

from: http://www.codeproject.com/cpp/complex_declarations.asp

Sequentially truncate string if delimiter is found.
  If string is not NULL, the function scans string for the first occurrence of any character included in delimiters. If it is found, the function overwrites the delimiter in string by a null-character and returns a pointer to the token, i.e. the part of the scanned string previous to the delimiter.
  After a first call to strtok, the function may be called with NULL as string parameter, and it will follow by where the last call to strtok found a delimiter.
  delimiters may vary from a call to another.

Parameters.

string

Null-terminated string to scan.

separator

Null-terminated string containing the separators.

Return Value.
  A pointer to the last token found in string.   NULL is returned when there are no more tokens to be found.

Portability.
  Defined in ANSI-C.

Example.

/* strtok example */
#include <stdio.h>
#include <string.h>

int main ()
{
  char str[] ="This is a sample string,just testing.";
  char * pch;
  printf ("Splitting string \"%s\" in tokens:\n",str);
  pch = strtok (str," ");
  while (pch != NULL)
  {
    printf ("%s\n",pch);
    pch = strtok (NULL, " ,.");
  }
  return 0;
}

Output:
Splitting string "This is a sample string,just testing." in tokens:
This
is
a
sample
string
just
testing

下面是linux下的strtok manual:
---------------------------------------------------------------
STRTOK(3)     Linux Programmer's Manual       STRTOK(3)

NAME
       strtok, strtok_r - extract tokens from strings

SYNOPSIS
       #include <string.h>

       char *strtok(char *s, const char *delim);

       char *strtok_r(char *s, const char *delim, char **ptrptr);

DESCRIPTION
       A  `token'  is  a  nonempty  string  of characters not occurring in the
       string delim, followed by \0 or by a character occurring in delim.

       The strtok() function can be used to parse the string  s  into  tokens.
       The  first call to strtok() should have s as its first argument. Subse-
       quent calls should have the first  argument  set  to  NULL.  Each  call
       returns a  pointer  to the next token, or NULL when no more tokens are
       found.

       If a token ends with a delimiter, this delimiting  character  is  over-
       written with a \0 and a pointer to the next character is saved for the
       next call to strtok().  The delimiter string delim may be different for
       each call.

       The  strtok_r() function  is a reentrant version of the strtok() func-
       tion, which instead of using its own static buffer, requires a  pointer
       to  a user allocated char*. This pointer, the ptrptr parameter, must be
       the same while parsing the same string.

BUGS
       Never use these functions. If you do, note that:

       These functions modify their first argument.

       These functions cannot be used on constant strings.

       The identity of the delimiting character is lost.

       The strtok() function uses a static  buffer  while  parsing,  so
       it's not thread safe. Use strtok_r() if this matters to you.

RETURN VALUE
       The  strtok()  function returns a pointer to the next token, or NULL if
       there are no more tokens.

CONFORMING TO
       strtok()
       SVID 3, POSIX, BSD 4.3, ISO 9899

       strtok_r()
       POSIX.1c

SEE ALSO
       index(3), memchr(3), rindex(3), strchr(3), strpbrk(3), strsep(3),  str-
       spn(3), strstr(3)

GNU      2000-02-13        STRTOK(3)

Single classes first

To understand how the this pointer works in class heirachies that use multiple inheritance, we start by examining how the compiler uses the instance pointer to access the class's members by dissecting a simpler example.

Say we've defined the following:

class Foo
{
public:
    int a;
    int b;    
};

void modifyFoo(Foo* foo)
{
    foo->a = 1;
    foo->b = 2;
}

int main(int argc, char* argv[])
{
    Foo* foo = new Foo();
    modifyFoo(foo);
    delete foo;
}

You can easily check this; sizeof(Foo) in the above example will return sizeof(foo->a)+sizeof(foo->b), which is 2*sizeof(int) - 8 bytes on a 32-bit platform and 16 on a 64-bit platform (we try this out below).

So for this example, our foo pointer in main() is really a pointer to an 8-byte or 16-byte chunk of memory containing the data members of Foo; at compile time, the compiler tracks the fact that this is a Foo* pointer, but that won't show up in the compiled code. If you have a look at the disassembly for modifyFoo(), what you'll find is that the expressions like foo->a get translated to '*(foo + the offset of Foo::a vs. the instance pointer, in bytes)' - so for our example, &foo->a will be the same pointer as foo, and &foo->b will be foo+sizeof(foo->a), ie. foo+4 on 32-bit platforms, foo+8 on 64-bit platforms.

It's worth pausing to check that this actually works. Adding and running the following method:

void Foo::dump()
{
    cout 
        << "Foo::dump():" << endl
        << "sizeof(Foo) = " << sizeof(Foo) << endl
        << "sizeof(*this) = " << sizeof(*this) << endl
        << "sizeof(a) + sizeof(b) = "
        <<  sizeof(a) + sizeof(b) << endl
        << "offsetof(Foo, a) = " << offsetof(Foo, a) << endl
        << "offsetof(Foo, b) = " << offsetof(Foo, b) << endl
        << "this = 0x" << hex << (intptr_t) this << endl
        << "&this->a = 0x" << hex << (intptr_t) &this->a << endl
        << "&this->b = 0x" << hex << (intptr_t) &this->b << endl
        << dec << endl;
}

Foo::dump():
sizeof(Foo) = 8
sizeof(*this) = 8
sizeof(a) + sizeof(b) = 8
offsetof(Foo, a) = 0
offsetof(Foo, b) = 4
this = 0x80518a8
&this->a = 0x80518a8
&this->b = 0x80518ac

We'll see later that data members are not the only thing that contribute to the size of an object; polymorphic classes also need a vtable pointer, which is discussed in the section on polymorphic types and the dynamic_cast operator.

Then simple inheritance

Next, we look at what happens to the this pointer if we descend from our base class, Foo, like this:

class Desc:
    public Foo
{
public:
    void dump();

public:
    int z;
};

void Desc::dump()
{
    Foo::dump();

    cout 
        << "Desc::dump():" << endl
        << "sizeof(Desc) = " << sizeof(Desc) << endl
        << "sizeof(*this) = " << sizeof(*this) << endl
        << "sizeof(a) + sizeof(b) + sizeof(z) = "
        <<  sizeof(a) + sizeof(b) + sizeof(z) << endl
        << "offsetof(Desc, a) = " << offsetof(Desc, a) << endl
        << "offsetof(Desc, b) = " << offsetof(Desc, b) << endl
        << "offsetof(Desc, z) = " << offsetof(Desc, z) << endl
        << "this = 0x" << hex << (intptr_t) this << endl
        << "&this->a = 0x" << hex << (intptr_t) &this->a << endl
        << "&this->b = 0x" << hex << (intptr_t) &this->b << endl
        << "&this->z = 0x" << hex << (intptr_t) &this->z << endl
        << dec << endl;
}

Foo::dump():
sizeof(Foo) = 8
sizeof(*this) = 8
sizeof(a) + sizeof(b) = 8
offsetof(Foo, a) = 0
offsetof(Foo, b) = 4
this = 0x80518a8
&this->a = 0x80518a8
&this->b = 0x80518ac

Desc::dump():
sizeof(Desc) = 12
sizeof(*this) = 12
sizeof(a) + sizeof(b) + sizeof(z) = 12
offsetof(Desc, z) = 8
this = 0x80518a8
&this->z = 0x80518b0

One interesting thing to note is that even though the instance is a Desc, Foo::dump() still only saw sizeof(*this) == 8 (sizeof is evaluated at compile time, purely in the context of the class itself, so does not include the subclass data).

Multiple inheritance

But we're about to get a nasty surprise. Let's define another simple class, Bar, and then make a class, Multi, that descends from both Foo and Bar:

class Bar
{
public:
    void dump();

public:
    int c;
};

void Bar::dump()
{
    cout 
        << "Bar::dump():" << endl
        << "sizeof(Bar) = " << sizeof(Bar) << endl
        << "sizeof(*this) = " << sizeof(*this) << endl
        << "sizeof(c) = " <<  sizeof(c) << endl
        << "offsetof(Bar, c) = " << offsetof(Bar, c) << endl
        << "this = 0x" << hex << (intptr_t) this << endl
        << "&this->c = 0x" << hex << (intptr_t) &this->c << endl
        << dec << endl;
}


class Multi:
	public Foo,
	public Bar
{
public:
	void dump();

public:
	int y;
};

void Multi::dump()
{
    Foo::dump();
    Bar::dump();

    cout 
        << "Multi::dump():" << endl
        << "sizeof(Multi) = " << sizeof(Multi) << endl
        << "sizeof(*this) = " << sizeof(*this) << endl
        << "sizeof(a) + sizeof(b) + sizeof(c) + sizeof(y) = "
        <<  sizeof(a) + sizeof(b) + sizeof(c) + sizeof(y) << endl
        << "offsetof(Multi, y) = " << offsetof(Multi, y) << endl
        << "this = 0x" << hex << (intptr_t) this << endl
        << "&this->a = 0x" << hex << (intptr_t) &this->a << endl
        << "&this->b = 0x" << hex << (intptr_t) &this->b << endl
        << "&this->c = 0x" << hex << (intptr_t) &this->c << endl
        << "&this->y = 0x" << hex << (intptr_t) &this->y << endl
        << dec << endl;
}

Foo::dump():
sizeof(Foo) = 8
sizeof(*this) = 8
sizeof(a) + sizeof(b) = 8
offsetof(Foo, a) = 0
offsetof(Foo, b) = 4
this = 0x80518e8
&this->a = 0x80518e8
&this->b = 0x80518ec

Bar::dump():
sizeof(Bar) = 4
sizeof(*this) = 4
sizeof(c) = 4
offsetof(Bar, c) = 0
this = 0x80518f0
&this->c = 0x80518f0

Multi::dump():
sizeof(Multi) = 16
sizeof(*this) = 16
sizeof(a) + sizeof(b) + sizeof(c) + sizeof(y) = 16
offsetof(Multi, y) = 12
this = 0x80518e8
&this->a = 0x80518e8
&this->b = 0x80518ec
&this->c = 0x80518f0
&this->y = 0x80518f4

Examine this output carefully, and note:

• The this pointer was the same for Foo::dump() and Multi::dump(), but different for Bar::dump(). See below for discussion.
• Despite that (in fact, because of it), all the dump() methods agreed on the actual memory locations of the fields (a, b, c, and y).
• All the sizeof values agreed with what we'd expect - the size of any base classes plus the size of the fields.

The clue to what's going on here is that in Bar::dump(), the offset of c is 0. The Bar class doesn't know that you're going to multiple-inherit from it (remember that you could use Bar on its own as well, so it has to be compiled independently this way, just the same way that Foo was), so it expects this to point to the start of its memory.

When you use multiple inheritance and make a call to Bar::dump(), the compiler passes a this that's been adjusted to point to the start of the Bar instance inside our Multi. It does this automatically, and normally you don't need to worry about it.

A note regarding offsetof and multiple inheritance

Before we move on to the implications of that, you may be wondering why I didn't output the following in Multi::dump():

        << "offsetof(Multi, a) = " << offsetof(Multi, a) << endl
        << "offsetof(Multi, b) = " << offsetof(Multi, b) << endl
        << "offsetof(Multi, c) = " << offsetof(Multi, c) << endl

invalid reference to NULL ptr, use ptr-to-member instead

#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

gcc recognises that the only useful way to work out what the offsets are when you have multiple inheritance is to do the special casts discussed below, and since these can't possibly be done on the NULL pointer - you can never have an object instance at address 0 - it gives an error.

Some compilers, Borland's for example, are quite happy with the operation and will compile it and Borland's does indeed return the desired result in this case. But you really, really don't want to be addressing members using offsets with multiple inheritance, because you would have to see a different offsetof in the different classes - Multi::dump would have to see an offsetof(Multi, c) of 12, even though offsetof(Bar, c) is 0... Which would be an accident waiting to happen; IMHO it's not a bad thing if the compiler prevents this inconsistency from surfacing.

Obviously, you shouldn't normally be using offsetof to access members anyway, but it's definitely an even worse idea with MI. Regardless, doing so is not compatible with some common compilers, and should be avoided.

Which class is at zero?

One final note before we move on: why was it Foo that shared the same this pointer value as Multi, and Bar that had an offset this? The answer is simply that Foo was the first class that we listed as a superclass.

In C++ when you use multiple inheritance, the order in which you list the superclasses does matter: the superclasses will be constructed in that order (and therefore destroyed in the reverse order), and the members will be laid out in that order too, meaning that the first superclass will normally have 0 offset from the instance pointer (I say 'normally' because there is an exception if the subclass is polymorphic but the first superclass wasn't - we'll see why later).

The danger of unsafe casts

From the above discussion, one thing that's not clear is why you should care. The compiler correctly adjusts everything so that the base classes find their own members correctly, and the subclass has no problem accessing them; you don't need to do anything special when accessing the class from outside either. So why did I feel the need to write up a page explaining all this?

The answer is: unsafe casts will not work correctly with multiple inheritance.

C++ introduced a number of new casting operators: static_cast, dynamic_cast, reinterpret_cast, and const_cast (they look more like templates than operators, but that's what they're called). Each of these is different to C-style casts, and so we actually have 5 different cast operators.

A full discussion of what each of these casts does is beyond the scope of this document (if I get enough requests, I'll write up a seperate article), so we will confine ourselves to considering what happens when we apply these cast operators to instances of objects with multiple inheritance. const_cast is therefore irrelevant to our discussion (it just adds or removes const and/or volatile qualification), leaving us four.

Let's start by trying them. Given our multi instance in the program above, we get these pointers out of our casts:

Original multi pointer: 0x80518e8	Cast to Multi*	Cast to Foo*	Cast to Bar*
C-style cast	0x80518e8	0x80518e8	0x80518f0
C-style cast to void*, then C-style cast to type	0x80518e8	0x80518e8	0x80518e8
reinterpret_cast	0x80518e8	0x80518e8	0x80518e8
static_cast	0x80518e8	0x80518e8	0x80518f0
dynamic_cast	0x80518e8	0x80518e8	0x80518f0

(As usual, actual values are irrelevant - just look at which values are different. To try these out yourself, download the example code at the end of the article.)

The first surprise in the above results is that if you use the old, C-style casts (for example, '(Bar*) multi', the compiler will adjust the pointer value, as it does for static_cast and dynamic_cast. In other words, in C++, C-style casts do not just do a plain copy-the-appropriate-number-of-bits as they did in C; it may actually involve adjustment of the pointer value (I certainly didn't expect that!).

But the other bit of important news here is that if we do a C-style cast to void* and then cast the result of that to our second type, the compiler cannot perform its address-adjustment magic, because it has no way of knowing that the void* is actually a Multi*; and worse, the same problem occurs if you static_cast to void* and then static_cast to our desired type (eg 'static_cast<Bar*>(static_cast<void*>(multi))') - that cast to Bar* returns the wrong result!.

reinterpret_cast, we can see, doesn't do any adjustment, it just reinterprets the literal bits of our multi pointer as another type of pointer completely. That will return the wrong value when casting classes with multiple inheritance, as we'd expect from the description of reinterpret_cast

These results give us the most important conclusions of this article: Never use C-style casts to convert pointers or references between object types, and secondly, Avoid using static_cast to downcast, and never use it with multiple inheritance. Instead:

• If you want to convert the pointer value literally, without adjustment and without real type checks, use reinterpret_cast. This will not come up very often.
• If you want to cast an instance pointer to a superclass, use static_cast; dynamic_cast will also work, but is unnecessary. static_cast checks the type relationships at compile-time, and has no unnecessary runtime overhead; dynamic_cast has runtime overhead and also imposes the extra requirement discussed below - but you might still prefer to use it for consistency sometimes.
• If you want to convert a superclass pointer down to a descendant type, always use dynamic_cast; it will check at runtime that the pointer is in fact an instance of the descendant type, and will adjust it if necessary, making this the only option that works with downcasting objects with multiple inheritance. See the section on downcasting below, which explains one change you may have to make to make this compile.

(Note that this summary discusses only casting object instance pointers between related types - there are many other things you might do with them, outside the scope of this document.)

Downcasting

'Downcasting' is the term used to describe casting a pointer or reference to a class 'down' the class heirachy - to one of its subclasses.

Why reinterpret_casts can't downcast

When you reinterpret_cast an instance pointer, the operator simply makes a pointer of the requested type with exactly the same address as the original. Therefore while reinterpet_cast will work fine if you are downcasting from a superclass to a subclass with no multiple inheritance anywhere in it's ancestry, it won't work in the general case - it'll compile and run, but will produce the wrong pointer.

For the example above, that pointer will be right for casting a void* down to a Foo*, or a Foo* down to a Multi*, but that's only because it happens that both Foo and Multi start at offset 0 (and even that can't be relied upon - if Multi is later made polymorphic, it will no longer be true); it won't work if you try to downcast a void* that actually points to a Multi* to a Bar*, because while Bar starts at offset 0 on its own, when it's a part of a Multi, it starts at offset 8 (or whatever).

(Note that this document makes no attempt to provide a general explanation of the utility or otherwise of reinterpret_cast, discussing only what's relevant to the matter of multiple inheritance.)

Why static_casts can't safely downcast

One might at first hope that static_cast could do the job. Sadly however, when starting with a pointer to a Foo or a Bar, there's no way to know, at compile time, from that type alone (which is all static_cast inspects) that it's actually a pointer to an object that's not only a Foo or a Bar but is in fact a Multi.

So the compiler will essentially do the same as it did for reinterpret_cast; if you cast our multi instance to a void* and then try to static_cast it back down to a Bar, it'll compile, but return the wrong result, because it doesn't know that this is not really a Bar - it's a Multi, which puts the Bar superclass instance at a nonzero offset. The compiler can't even check that the pointer you're casting is composed of a Bar instance at all, let alone know where the Bar is placed inside; so it just unsafely does the cast (I wish it gave an error - after all you can get that behaviour with other operators, if you really want it).

Again, note that this document makes no attempt to provide a general explanation of the use and limitations of static_cast; there's a lot more to know about this operator not directly relevant here.

Polymorphic types: Why dynamic_casts can downcast

The only operator that can successfully downcast is dynamic_cast. However, there is one catch: in order for downcasts to be possible, the base type you are casting from must be polymorphic.

Polymorphic is a general OOP term with which I assume readers are familiar. However, in the context of the C++ language, it has a specific and tangible meaning: polymorphic classes are those that have at least one virtual method (including destructors, and also including pure virtual methods - so you can just define a dummy private pure virtual method if you want to force a base class to be polymorphic but have no other virtuals).

The implication of a C++ class being polymorphic is that it has a vtable. A vtable ('virtual(s) table') is simply a static data structure (one per class, not per instance - all Foo instances share the same vtable, all Bar instances share another) that lists a number of things, including the table of all the virtual methods, and some metadata regarding the class itself and its ancestors, the latter being the part that is of use to us here.

vtables are created by the compiler and generally remain hidden to the application; you shouldn't ever need to access them directly. A fully detailed discussion of the contents of vtables falls outside the scope of this document, but thankfully, you don't need to know exactly what's in them for the problem at hand; we'll just look at how they're placed and how they help with downcasts.

If we make, say, our Foo class polymorphic, which we could do by (for example) adding a virtual tag to our definition of dump(), we notice that the sizeof(Foo) increases by the size of a pointer (4 bytes on my 32-bit PC), and that offsetof(Foo, a) and offsetof(Foo, b) will both increase by the size of a pointer too.

This is not a coincidence: when the compiler compiles the polymorphic class, it creates a vtable for it, and it now stores a pointer to this vtable at the very start of every instance (storing that pointer is one of the many jobs that is performed automatically by the constructor).

When the compiler compiles a normal subclass of a polymorphic class, it will make a new vtable for that subclass, but the instances of this subclass don't have to have pointers to both the superclass vtables and the subclass vtables separately, because the vtable for the subclass includes everything that the vtable for the superclass contained. So the size overhead of being polymorphic for a normal class is just one pointer per instance, regardless of how deep in the ancestry it is (again, the vtable itself is just one per class).

But this isn't quite enough if we're using multiple inheritance. Making any of the superclasses polymorphic is enough to make Multi polymorphic. But, if we made Bar polymorphic too, then it too would always have a vtable pointer at the start of its instance data. And since all Multi instances have what is effectively a standalone Bar instance embedded somewhere inside them (remember that you can cast the subclass instance to that superclass, so it must be able to work just like a real standalone Bar would), Multi will now have to have two vtable pointers - at the very start of our Multi instance will be the pointer to the combined Foo+Multi vtable, and at the offset of the Bar inside the Multi will be the pointer to the combined Bar+Multi vtable.

You don't need to know that, but if you're interested in how vtables work, convince yourself that this is so. You can test this theory out by noting that adding virtual methods to Multi adds no more instance size overhead once the Foo superclass is polymorphic, but that making Bar polymorphic as well does increase the size of Multi instances by one pointer.

Let's get back on track. We've said that all instances of polymorphic classes have a vtable pointer at the start of the instance. This is great because now, if we have a pointer to any polymorphic class, we can inspect the vtable and determine what the 'actual' type of that object is. So, even if we were given a Foo* or a Bar*, if we inspected the vtable, we'd be able to see if this is actually a Multi instance, not just a plain Foo or Bar instance.

And this is just what the dynamic_cast operator does for us: dynamic_cast inspects the vtable of the polymorphic class instance you pass it to check that is actually an instance of whatever type you are trying to convert to - and if so, then it calculates if an offset is required to do the conversion and does it.

The offset for converting a Foo* to a Multi* would in the simplest case be 0 (and likewise for going back the other way). But to convert a Bar* to a Multi*, dynamic_cast would find from the vtable that the Bar instance is embedded some distance into the Multi (12 bytes when I run my test code), and it therefore subtracts that many bytes to find the correct address of the enclosing Multi from the Bar* pointer it started with.

So there you have it: dynamic_cast is the solution to the downcasting problem; the unavoidable cost is that your classes must be polymorphic. That constraint may annoy you sometimes because it means that you can't directly downcast from types like void*, but in practice you should find that even if you're stuffing your instance pointers into void*s for a callback or whatever from a C library you're using, you will at least know what the base class is, so you can statically cast to that, and then dynamic_cast to perform the downcast; if not, you'll just have to declare one. That one issue aside, the overhead is generally small enough to not be an issue.

Conclusion

Whether you are using multiple inheritance or not, remember:

• Don't rely on the this pointer having the same value everywhere if you're using multiple inheritance - cast it properly if necessary to get a 'canonical' pointer.
• Never hardcode the offset of members relative to the instance pointer, and avoid using offsetof unless strictly necessary (rare).
• Don't use C-style casts to convert pointers or references between object types - use reinterpret_cast if you want an unsafe, unadjusted conversion, or static_cast or dynamic_cast as below.
• If you want to cast an instance pointer to a superclass, use static_cast or dynamic_cast; the former is more efficient.
• If you want to convert a superclass pointer down to a descendant type, always use dynamic_cast.

Example code

I encourage readers to download the example code for this article and try out the variations and effects for themselves.

from: http://carcino.gen.nz/tech/cpp/multiple_inheritance_this.php

----------------------------------------------------------

人物介绍：

我 --- 一个追求上进的C++程序员，尚在试用期，聪明但是经验不足。

Wendy --- 公司里的技术大拿，就坐在我旁边的隔间里，C++大虾，最了不起的是，她是个女的 她什麽都好，就是有点刻薄，

          我对她真是又崇拜又嫉妒。

----------------------------------------------------------

I. Virtually Yours?-- Template Method模式

我在研究Wendy写的一个类。那是她为这个项目写的一个抽象基类，而我的工作就是从中派生出一个具象类(concrete class)。这个类的public部份是这样的：

class Mountie {
public:
    void read( std::istream & );
    void write( std::ostream & ) const;
    virtual ~Mountie();

很正常，virtual destructor表明这个类打算被继承。那麽再看看其protected部份：

protected:
    virtual void do_read( std::istream & );
    virtual void do_write( std::ostream & ) const;

也不过就是一会儿的功夫，我识破了Wendy的把戏：她在使用template method模式。public成员函数read和write是非虚拟的，它们肯定是调用protected部份do_read/do_write虚拟成员函数来完成实际的工作。啊，我简直为自己的进步而飘飘然了 哈，Wendy，这回你可难不住我，还有什麽招数？尽管放马过来... 突然，笑容在我脸上凝固，因为我看到了其private部份：

private:
    virtual std::string classID() const = 0;

这是什麽？一个private纯序函数，能工作麽？我站了起来，

“Wendy，你的Mountie类好像不能工作耶，它有一个private virtual function。”

“你试过了？”她连头都不抬。

“嗯，那倒是没有啦，可是想想也不行啊？我的派生类怎麽能override你的private函数呢？” 我嘟囔 。

“ ，你倒是很确定啊 ”Wendy的声音很轻柔，“你怎麽老是这也不行，那也不行的，这几个月跟 我你就没学到什麽东西吗？小菜鸟。”

真是可恶啊...

“小菜鸟，你全都忘了，访问控制级别跟一个函数是不是虚拟的根本没关系。判断一个函数是动态绑定还是静态绑定是函数调用解析的最後一个步骤。好好读读标准的3.4和5.2.2节吧。”

我完全处於下风，只好采取干扰战术。“好吧，就算你说的不错，我也还是不明白，何必把它设为private？”

“我且问你，倘若你不想让一个类中的成员函数被其他的类调用，应当如何处理？”

“当然是把它设置为private的，” 我回答道。

“那麽你去看看我的Mountie类实现，特别是write()函数的实现。”

我正巴不得逃开Wendy那刺人的目光，便转过头去在我的屏幕上搜索，很快，我找到了：

void Mountie::write(std::ostream &Dudley) const
{
    Dudley << classID() << std::endl;
    do_write(Dudley);
}

嗨，最近卡通片真是看得太多了，居然犯这样的低级失误。还是老是承认吧：“好了，我明白了。classID()是一个实现细节，用来在保存对象时指示具象类的类型，派生类必须覆盖它，所以必须是纯虚的。但是既然是实现细节，就应该设为private的。”

“这还差不多，小菜鸟。”大虾点了点头，“现在给我解释一下为什麽do_read()和do_write()是protected的？”

这个问题并不难，我组织了一下就回答：“因为派生类对象需要调用这两个函数的实现来读写其中的基类对象。”

“很好很好，”大虾差不多满意了，“不过，你再解释解释为什麽我不把它们设为public的？”

现在我感觉好多了：“因为调用它们的时候必须以一种特定的方式进行。比如do_write()函数，必须先把类型信息写入，再把对象信息写入，这样读取的时候，负责生成对象的模块首先能够知道要读出来的对象是什麽类型的，然後才能正确地从流中读取对象信息。”

“聪明啊，我的小菜鸟 ”Wendy停顿了一下，“就跟学习外国口语一样，学习C++也不光是掌握语法而已，还必须要掌握大量的惯用法。”

“是啊是啊，我正打算读Coplien的书...”

[译者注：就是James Coplien 1992年的经典着作Advanced C++ Programming Style and Idioms]

大虾挥了挥她的手，“冷静，小菜鸟，我不是指先知Coplien的那本书，我是指某种结构背後隐含的惯用法。比如一个类有virtual destructor，相当于告诉你说：‘嗨，我是一个多态基类，来继承我吧 ＇ 而如果一个类的destructor不是虚拟的，则相当於是在说：‘我不能作为多态基类，看在老天的份上，别继承我。＇”

“同样的，virtual函数的访问控制级别也具有隐含的意义。一个protected virtual function告诉你：‘你写的派生类应该，哦，可是说是必须调用我的实现。＇而一个private virtual function是在说：‘派生类可以覆盖，也可以不覆盖我，随你的便。但是你不可以调用我的实现。＇”

我点点头，告诉她我懂了，然後追问道：“那麽public virtual function呢？”

“尽可能不要使用public virtual function。”她拿起一支笔写下了以下代码：

class HardToExtend 

{

public:

	 virtual void f();

};

 void HardToExtend::f() 

{ 

	// Perform a specific action 

}

“假设你发布了这个类。在写第二版时，需求有所变化，你必须改用Template Method。可是这根本不可能，你知道为什麽？”

“呃，这个...，不知道。”

“由两种可能的办法。其一，将f()的实现代码转移到一个新的函数中，然後将f()本身设为non-virtual的：

class HardToExtend
{
// possibly protected
    virtual void do_f();
public:
    void f();
};
void HardToExtend::f()
{
    // pre-processing
    do_f();
    // post-processing
}
void HardToExtend::do_f()
{
    // Perform a specific action
}

然而你原来写的派生类都是企图override函数f()而不是do_f()的，你必须改变所有的派生类实现，只要你错过了一个类，你的类层次就会染上先知Meyers所说的‘精神分裂的行径＇。”[译者注：叁见Scott Meyers，Effective C++, Item 37，绝对不要重新定义继承而来的非虚拟函数]

“另一种办法是将f()移到private区域，引入一个新的non-virtual函数：”

class HardToExtend
{
// possibly protected
    virtual void f();
public:
    void call_f();
};

“这会导致无数令人头痛的问题。首先，所有的客户都企图调用f()而不是call_f()，现在它们的代码都不能编译了。更有甚者，大部份派生类都回把f()放在public区域中，这样直接使用派生类的用户可以访问到你本来想保护的细节。”

“对待虚函数要象对待数据成员一样，把它们设为private的，直到设计上要求使用更宽松的访问控制再来调整。要知道由private入public易，由public入private难啊 ”

[译者注：这篇文章所表达的思想具有一定的颠覆性，因为我们太容易在基类中设置public virtual function了，Java中甚至专门为这种做法建立了interface机制，现在竟然说这不好 一时间真是接受不了。但是仔细体会作者的意思，他并不是一般地反对public virtual function，只是在template method大背景下给出上述原则。虽然这个原则在一般的设计中也是值得考虑的，但是主要的应用领域还是在template method模式中。当然，template method是一种非常有用和常用的模式，因此也决定了本文提出的原则具有广泛的意义。]

----------------------------------------------------------------

II. Visitor模式

我正在为一个设计问题苦恼。试用期快结束了，我希望自己解决这个问题，来证明自己的进步。每个人都记得自己的第一份工作吧，也都应该知道在这个时候把活儿做好是多麽的重要 我亲眼看到其他的新雇员没有过完试用期就被炒了鱿鱼，就是因为他们不懂得如何对付那个大虾...，别误会，我不是说她不好，她是我见过最棒的程序员，可就是有点刻薄古怪...。现在我拜她为师，不为别的，就是因为我十分希望能达到她那个高度。

我想在一个类层次(class hierarchy)中增加一个新的虚函数，但是这个类层次是由另外一帮人维护的，其他人碰都不能碰：

class Personnel
{
public:
  virtual void Pay ( /*...*/ ) = 0;
  virtual void Promote( /*...*/ ) = 0;
  virtual void Accept ( PersonnelV& ) = 0;
  // ... other functions ...
};

class Officer : public Personnel { /* override virtuals */ };
class Captain : public Officer { /* override virtuals */ };
class First : public Officer { /* override virtuals */ };

我想要一个函数，如果对象是船长(Captain)就这麽做，如果是大副(First Officer)就那麽做。Virtual function正是解决之道，在Personnel或者Officer中声明它，而在Captain和First覆盖(override)它。

糟糕的是，我不能增加这麽一个虚函数。我知道可以用RTTI给出一个解决方案：

void f( Officer &o )
{
  if( dynamic_cast<Captain*>(&o) )
    /* do one thing */
  else if( dynamic_cast<First*>(&o) )
    /* do another thing */
}

int main()
{
  Captain k;
  First s;
  f( k );
  f( s );
}

但是我知道使用RTTI是公司编码标准所排斥的行为，我对自己说：“是的，虽然我以前不喜欢RTTI，但是这回我得改变对它的看法了。很显然，除了使用RTTI，别无它法。”

“任何问题都可以通过增加间接层次的方法解决。”

我噌地一下跳起来，那是大虾的声音，她不知道什麽时候跑到我背後，“啊哟，您吓了我一跳...您刚才说什麽？”

“任何问...”

“是的，我听清楚了，”我也不知道哪来的勇气，居然敢打断她，“我只是不知道您从哪冒出来的。”其实这话只不过是掩饰我内心的慌张。

“哈，算了吧，小菜鸟，”大虾斜 眼看 我，“你以为我不知道你心里想什麽 ”她把声音提高了八度，直盯 我，“那些可怜的C语言门徒才会使用switch语句处理不同的对象类型。你看：”

/* A not-atypical C program */
void f(struct someStruct *s)
{
  switch(s->type) {
  case APPLE:
    /* do one thing */
    break;
  case ORANGE:
    /* do another thing */
    break;
  /* ... etc. ... */
  }
}

“这些人学习Stroustrup教主的C++语言时，最重要的事情就是学习如何设计好的类层次。”

“没错，”我又一次打断她，迫不及待地想让Wendy明白，我还是有两下子的，“他们应该设计一个Fruit基类，派生出Apple和Orange，用virtual function来作具体的事情。

“很好，小菜鸟。C语言门徒通常老习惯改不掉。但是，你应该知道，通过使用virtual function，你增加了一个间接层次。”她放下笔，“你所需要的不就是一个新的虚函数吗？”

“是的。可是我没有权力这麽干。”

“因为你无权修改类层次，对吧 ”

“您终於了解了情况，我们没法动它。也不知道这个该死的类层次是哪个家伙设计的...” 我嘀嘀咕咕 。

“是我设计的。”

“啊...，真的？ 这个，嘿嘿...”，我极为尴尬。

“这个类层次必须非常稳定，因为有跨平台的问题。但是它的设计允许你增加新的virtual function，而不必烦劳RTTI。你可以通过增加一个间接层次的办法解决这个问题。请问，Personnel::Accept是什麽?”

”嗯，这个...”

“这个类实现了一个模式，可惜这个模式的名字起得不太好，是个PNP，叫Visitor模式。”

[译者注：PNP，Poor-Named Pattern, 没起好名字的模式]

“啊，我刚刚读过Visitor模式。但是那只不过是允许若干对象之间相互迭代访问的模式，不是吗？”

她叹了一口气，“这是流行的错误理解。那个V，我觉得毋宁说是Visitor，还不如说是Virtual更好。这个PNP最重要的用途是允许在不改变类层次的前提下，向已经存在的类层次中增加新的虚函数。首先来看看Personnel及其派生类的Accept实现细节。”她拿起笔写下：

void Personnel::Accept( PersonnelV& v )
  { v.Visit( *this ); }

void Officer::Accept ( PersonnelV& v )
  { v.Visit( *this ); }

void Captain::Accept ( PersonnelV& v )
  { v.Visit( *this ); }

void First::Accept ( PersonnelV& v )
  { v.Visit( *this ); }

“Visitor的基类如下：”

class PersonnelV/*isitor*/
{
public:
  virtual void Visit( Personnel& ) = 0;
  virtual void Visit( Officer& ) = 0;
  virtual void Visit( Captain& ) = 0;
  virtual void Visit( First& ) = 0;
};

“啊，我记起来了。当我要利用Personnel类层次的多态性时，我只要调用Personnel::Accept(myVisitorObject)。由於Accept是虚函数，我的myVisitorObject.Visit()会针对正确的对象类型调用，根据重载法则，编译器会挑选最贴切的那个Visit来调用。这不相当于增加了一个新的虚拟函数了吗？”

“没错，小菜鸟。只要类层次支持Accept，我们就可以在不改动类层次的情况下增加新的虚函数了。”

“好了，我现在知道该怎麽办了”，我写道：

class DoSomething : public PersonnelV
{
public:
  virtual void Visit( Personnel& );
  virtual void Visit( Officer& );
  virtual void Visit( Captain& );
  virtual void Visit( First& );
};

void DoSomething::Visit( Captain& c )
{
  if( femaleGuestStarIsPresent )
    c.TurnOnCharm();
  else
    c.StartFight();
}

void DoSomething::Visit( First& f )
{
  f.RaiseEyebrowAtCaptainsBehavior();
}

void f( Personnel& p )
{
  p.Accept( DoSomething() ); // 相当于 p.DoSomething()
}

int main()
{
  Captain k;
  First s;

  f( k );
  f( s );
}

大虾满意地笑了，“也许这个模式换一个名字会更好理解，可惜世事往往不遂人意...”。

[译者注：这篇文章我作了一定的删节，原文中有稍微多一些的论述，而且提供了两篇技术文章的link。]

from: http://jjhou.csdn.net/myan-design-patterns-big5.htm

级别: 中级

陈家朋
系统架构师和技术顾问, 杭州迈可行通信技术有限公司
2003 年 3 月

软件模块之间总是存在着一定的接口，从调用方式上，可以把他们分为三类：同步调用、回调和异步调用。同步调用是一种阻塞式调用，调用方要等待对方执行完毕才返回，它是一种单向调用；回调是一种双向调用模式，也就是说，被调用方在接口被调用时也会调用对方的接口；异步调用是一种类似消息或事件的机制，不过它的调用方向刚好相反，接口的服务在收到某种讯息或发生某种事件时，会主动通知客户方（即调用客户方的接口）。回调和异步调用的关系非常紧密，通常我们使用回调来实现异步消息的注册，通过异步调用来实现消息的通知。同步调用是三者当中最简单的，而回调又常常是异步调用的基础，因此，下面我们着重讨论回调机制在不同软件架构中的实现。

1 什么是回调
软件模块之间总是存在着一定的接口，从调用方式上，可以把他们分为三类：同步调用、回调和异步调用。同步调用是一种阻塞式调用，调用方要等待对方执行完毕才返回，它是一种单向调用；回调是一种双向调用模式，也就是说，被调用方在接口被调用时也会调用对方的接口；异步调用是一种类似消息或事件的机制，不过它的调用方向刚好相反，接口的服务在收到某种讯息或发生某种事件时，会主动通知客户方（即调用客户方的接口）。回调和异步调用的关系非常紧密，通常我们使用回调来实现异步消息的注册，通过异步调用来实现消息的通知。同步调用是三者当中最简单的，而回调又常常是异步调用的基础，因此，下面我们着重讨论回调机制在不同软件架构中的实现。

对于不同类型的语言（如结构化语言和对象语言）、平台（Win32、JDK）或构架（CORBA、DCOM、WebService），客户和服务的交互除了同步方式以外，都需要具备一定的异步通知机制，让服务方（或接口提供方）在某些情况下能够主动通知客户，而回调是实现异步的一个最简捷的途径。

对于一般的结构化语言，可以通过回调函数来实现回调。回调函数也是一个函数或过程，不过它是一个由调用方自己实现，供被调用方使用的特殊函数。

在面向对象的语言中，回调则是通过接口或抽象类来实现的，我们把实现这种接口的类成为回调类，回调类的对象成为回调对象。对于象C++或Object Pascal这些兼容了过程特性的对象语言，不仅提供了回调对象、回调方法等特性，也能兼容过程语言的回调函数机制。

Windows平台的消息机制也可以看作是回调的一种应用，我们通过系统提供的接口注册消息处理函数（即回调函数），从而实现接收、处理消息的目的。由于Windows平台的API是用C语言来构建的，我们可以认为它也是回调函数的一个特例。

对于分布式组件代理体系CORBA，异步处理有多种方式，如回调、事件服务、通知服务等。事件服务和通知服务是CORBA用来处理异步消息的标准服务，他们主要负责消息的处理、派发、维护等工作。对一些简单的异步处理过程，我们可以通过回调机制来实现。

下面我们集中比较具有代表性的语言（C、Object Pascal）和架构（CORBA）来分析回调的实现方式、具体作用等。

2 过程语言中的回调（C）

2.1 函数指针
回调在C语言中是通过函数指针来实现的,通过将回调函数的地址传给被调函数从而实现回调。因此，要实现回调，必须首先定义函数指针，请看下面的例子：

void Func(char *s)；// 函数原型
void (*pFunc) (char *);//函数指针

可以看出，函数的定义和函数指针的定义非常类似。

一般的化，为了简化函数指针类型的变量定义，提高程序的可读性，我们需要把函数指针类型自定义一下。

typedef void(*pcb)(char *);

回调函数可以象普通函数一样被程序调用，但是只有它被当作参数传递给被调函数时才能称作回调函数。

被调函数的例子：

void GetCallBack(pcb callback)
{
/*do something*/
}
用户在调用上面的函数时，需要自己实现一个pcb类型的回调函数：
void fCallback(char *s) 
{
/* do something */
} 
然后，就可以直接把fCallback当作一个变量传递给GetCallBack,
GetCallBack（fCallback）;

如果赋了不同的值给该参数，那么调用者将调用不同地址的函数。赋值可以发生在运行时，这样使你能实现动态绑定。

2.2 参数传递规则
到目前为止，我们只讨论了函数指针及回调而没有去注意ANSI C/C++的编译器规范。许多编译器有几种调用规范。如在Visual C++中，可以在函数类型前加_cdecl，_stdcall或者_pascal来表示其调用规范（默认为_cdecl）。C++ Builder也支持_fastcall调用规范。调用规范影响编译器产生的给定函数名，参数传递的顺序（从右到左或从左到右），堆栈清理责任（调用者或者被调用者）以及参数传递机制（堆栈，CPU寄存器等）。

将调用规范看成是函数类型的一部分是很重要的；不能用不兼容的调用规范将地址赋值给函数指针。例如：

// 被调用函数是以int为参数，以int为返回值
__stdcall int callee(int); 

// 调用函数以函数指针为参数
void caller( __cdecl int(*ptr)(int)); 

// 在p中企图存储被调用函数地址的非法操作
__cdecl int(*p)(int) = callee; // 出错

指针p和callee()的类型不兼容，因为它们有不同的调用规范。因此不能将被调用者的地址赋值给指针p，尽管两者有相同的返回值和参数列

2.3 应用举例
C语言的标准库函数中很多地方就采用了回调函数来让用户定制处理过程。如常用的快速排序函数、二分搜索函数等。

快速排序函数原型：

void qsort(void *base, size_t nelem, size_t width, int (_USERENTRY *fcmp)(const void *, const void *));
二分搜索函数原型：
void *bsearch(const void *key, const void *base, size_t nelem,
				 size_t width, int (_USERENTRY *fcmp)(const void *, const void *));

其中fcmp就是一个回调函数的变量。

下面给出一个具体的例子：

#include <stdio.h>
#include <stdlib.h>

int sort_function( const void *a, const void *b);
int list[5] = { 54, 21, 11, 67, 22 };

int main(void)
{
   int  x;

   qsort((void *)list, 5, sizeof(list[0]), sort_function);
   for (x = 0; x < 5; x++)
      printf("%i\n", list[x]);
   return 0;
}

int sort_function( const void *a, const void *b)
{
   return *(int*)a-*(int*)b;
}

2.4 面向对象语言中的回调（Delphi）

Dephi与C++一样，为了保持与过程语言Pascal的兼容性，它在引入面向对象机制的同时，保留了以前的结构化特性。因此，对回调的实现，也有两种截然不同的模式，一种是结构化的函数回调模式，一种是面向对象的接口模式。

2.4.1 回调函数

回调函数类型定义：

type
   TCalcFunc=function (a:integer;b:integer):integer;

按照回调函数的格式自定义函数的实现，如

function Add(a:integer;b:integer):integer
begin
  result:=a+b;
end;
function Sub(a:integer;b:integer):integer
begin
  result:=a-b;
end;

回调的使用

function Calc(calc:TcalcFunc;a:integer;b:integer):integer

下面，我们就可以在我们的程序里按照需要调用这两个函数了

c:=calc(add,a,b);//c=a+b
c:=calc(sub,a,b);//c=a-b

2.4.2 回调对象

什么叫回调对象呢，它具体用在哪些场合？首先，让我们把它与回调函数对比一下，回调函数是一个定义了函数的原型，函数体则交由第三方来实现的一种动态应用模式。要实现一个回调函数，我们必须明确知道几点：该函数需要那些参数，返回什么类型的值。同样，一个回调对象也是一个定义了对象接口，但是没有具体实现的抽象类（即接口）。要实现一个回调对象，我们必须知道：它需要实现哪些方法，每个方法中有哪些参数，该方法需要放回什么值。

因此，在回调对象这种应用模式中，我们会用到接口。接口可以理解成一个定义好了但是没有实现的类，它只能通过继承的方式被别的类实现。Delphi中的接口和COM接口类似，所有的接口都继承与IInterface（等同于IUnknow），并且要实现三个基本的方法QueryInterface, _AddRef, 和_Release。

• 定义一个接口
  

  type IShape=interface(IInterface) procedure Draw; end

• 实现回调类
  

  type TRect=class(TObject,IShape) protected function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; public procedure Draw; end; type TRound=class(TObject,IShape) protected function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; public procedure Draw; end;

• 使用回调对象
  

  procedure MyDraw(shape:IShape); var shape:IShape; begin shape.Draw; end;

如果传入的对象为TRect，那么画矩形；如果为TRound，那么就为圆形。用户也可以按照自己的意图来实现IShape接口，画出自己的图形：

MyDraw(Trect.Create);
MyDraw(Tround.Create);

2.4.3 回调方法

回调方法(Callback Method)可以看作是回调对象的一部分，Delphi对windows消息的封装就采用了回调方法这个概念。在有些场合，我们不需要按照给定的要求实现整个对象，而只要实现其中的一个方法就可以了，这是我们就会用到回调方法。

回调方法的定义如下：

TNotifyEvent = procedure(Sender: TObject) of object; 
TMyEvent=procedure(Sender:Tobject;EventId:Integer) of object;

TNotifyEvent 是Delphi中最常用的回调方法，窗体、控件的很多事件，如单击事件、关闭事件等都是采用了TnotifyEvent。回调方法的变量一般通过事件属性的方式来定义，如TCustomForm的创建事件的定义：

property OnCreate: TNotifyEvent read FOnCreate write FOnCreate stored IsForm;

我们通过给事件属性变量赋值就可以定制事件处理器。

用户定义对象（包含回调方法的对象）：

type TCallback=Class
    procedure ClickFunc(sender:TObject);
end;
procedure Tcallback.ClickFunc(sender:TObject);
begin
  showmessage('the caller is clicked!');
end;

窗体对象：

type TCustomFrm=class(TForm)
  public
	procedure RegisterClickFunc(cb:procedure(sender:Tobject) of object);
end;

procedure TcustomFrm..RegisterClickFunc(cb:TNotifyEvent);
begin
  self.OnClick=cb;
end;

使用方法：

var
  frm:TcustomFrm;
begin
  frm:=TcustomFrm.Create(Application);
  frm.RegisterClickFunc(Tcallback.Create().ClickFunc);
end;

3 回调在分布式计算中的应用（CORBA）

3.1 回调接口模型
CORBA的消息传递机制有很多种，比如回调接口、事件服务和通知服务等。回调接口的原理很简单，CORBA客户和服务器都具有双重角色，即充当服务器也是客户客户。

回调接口的反向调用与正向调用往往是同时进行的，如果服务端多次调用该回调接口，那么这个回调接口就变成异步接口了。因此，回调接口在CORBA中常常充当事件注册的用途，客户端调用该注册函数时，客户函数就是回调函数，在此后的调用中，由于不需要客户端的主动参与，该函数就是实现了一种异步机制。

从CORBA规范我们知道，一个CORBA接口在服务端和客户端有不同的表现形式，在客户端一般使用桩（Stub）文件，服务端则用到框架（Skeleton）文件，接口的规格采用IDL来定义。而回调函数的引入，使得服务端和客户端都需要实现一定的桩和框架。下面是回调接口的实现模型：

3.1.1 范例

下面给出了一个使用回调的接口文件，服务端需要实现Server接口的框架，客户端需要实现CallBack的框架：

module cb
{
	interface CallBack;
	interface Server;

interface CallBack 
{
    	void OnEvent(in long Source,in long msg);
};
  	interface Server 
{
    	long RegisterCB(in CallBack cb);
		void UnRegisterCB(in long hCb);
};
};

客户端首先通过同步方式调用服务端的接口RegistCB，用来注册回调接口CallBack。服务端收到该请求以后，就会保留该接口引用，如果发生某种事件需要向客户端通知的时候就通过该引用调用客户方的OnEvent函数，以便对方及时处理。

本文源码 下载。