myajax95斑竹,请发表一下关于reference counting的见解

在实际开发中,在哪里可以用到这项技术??

回头会写详细的一篇文章。另外讨论得那么热闹怎么没人提 static_cast dynamic_cast 呀，通过C++提供的指针类型转换可以避免无数void* int*之类的类型错误。如果说这个问题，可能还得提起Run time library。就是对于一个class 的指针，用IsKindOf之类的检查一下。内容比较多，我争取总结的全面一点。

smart pointer最常见到的地方是在COM interface里对于COM server指针的管理。用处就是实现像JAVA,C#那样的garbage collection了。
平时写程序时用这个smart pointer也是很保险的编程风格，可惜我对这块东西没有那么熟练，所以练习的也不多。争取写完这个总结之后能够用于日常的程序里。

使用引用计数的出发点大概有两个：资源共享和垃圾回收。两者也是互相纠缠的。
如果资源可以被多个客户所共享，必然会带来何时以及由谁来释放的问题；
如果是为了跟踪资源的使用状况以便在不被占用时释放它，也会在客观上促成它的共享功能。

引用计数用途广泛，简单，但是有运行时开销。
vc中的CString,_bstr_t等类就使用了它；在windows中，内核对象、COM技术等也采用了引用计数机制。

dynamic_cast 还请你详细讨论,我只粗劣的知道在多态中使用,可以判断"向下"转换是否成功,如果成功就转换成派生类指针,不成功就null

CString里面也有reference count 吗？怎么用的？

那边完全就不能算是讨论，完全是吵架，就算做是增加C++人气吧，呵呵。

有的,它已经是自动使用了,不用程序员关心,据我所知,连standard c++的 basic_string<char>都是用引用计数

CString技术干什么？又不自己delete自己，计数有什么意义？

是为了实现copy-on-write，节省空间和拷贝开销。

仔细学习中

Copy-on-write (sometimes referred to as "COW") is an optimization strategy used in computer programming. The fundamental idea is that if multiple callers ask for resources which are initially indistinguishable, you can give them pointers to the same resource. This fiction can be maintained until a caller tries to modify its "copy" of the resource, at which point a true private copy is created to prevent the changes becoming visible to everyone else. All of this happens transparently to the callers. The primary advantage is that if a caller never makes any modifications, no private copy need ever be created.

Copy-on-write finds its main use in virtual memory operating systems; when a process creates a copy of itself, the pages in memory that might be modified by either the process or its copy are marked copy-on-write. When one process modifies the memory, the operating system's kernel intercepts the operation and copies the memory so that changes in one process's memory are not visible to the other.

Another use is in the calloc function. This can be implemented by having a page of physical memory filled with zeroes. When the memory is allocated, the pages returned all refer to the page of zeroes and are all marked as copy-on-write. This way, the amount of physical memory allocated for the process does not increase until data is written. This is typically only done for larger allocations.

Copy-on-write can be implemented by telling the MMU that certain pages in the process's address space are read-only. When data is written to these pages, the MMU raises an exception which is handled by the kernel, which allocates new space in physical memory and makes the page being written to correspond to that new location in physical memory.

One major advantage of COW is the ability to use memory sparsely. Because the usage of physical memory only increases as data is stored in it, very efficient hash tables can be implemented which only use little more physical memory than is necessary to store the objects they contain. However, such programs run the risk of running out of virtual address space -- virtual pages unused by the hash table cannot be used by other parts of the program. The main problem with COW at the kernel level is the complexity it adds, but the concerns are similar to those raised by more basic virtual memory concerns such as swapping pages to disk; when the kernel writes to pages, it must copy them if they are marked copy-on-write.

COW is also used outside the kernel, in library, application and system code. The string class provided by C++'s Standard Template Library, for example, was specifically designed to allow copy-on-write implementations. One hazard of COW in these contexts arises in multithreaded code, where the additional locking required for objects in different threads to safely share the same representation can easily outweigh the benefits of the approach.

The COW concept is also used in virtualization/emulation software such as Bochs, QEMU, and UML for virtual disk storage. This allows a great reduction in required disk space when multiple VMs can be based on the same hard disk image, as well as increased performance as disk reads can be cached in RAM and subsequent reads served to other VMs out of the cache.