#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
{