C++ 多态的实现原理与内存模型

  多态在C++中是一个重要的概念,通过虚函数机制实现了在程序运行时根据调用对象来判断具体调用哪一个函数。

     具体来说就是:父类类别的指针(或者引用)指向其子类的实例,然后通过父类的指针(或者引用)调用实际子类的成员函数。在每个包含有虚函数的类的对象的最前面(是指这个对象对象内存布局的最前面)都有一个称之为虚函数指针(vptr)的东西指向虚函数表(vtbl),这个虚函数表(这里仅讨论最简单的单一继承的情况,若果是多重继承,可能存在多个虚函数表)里面存放了这个类里面所有虚函数的指针,当我们要调用里面的函数时通过查找这个虚函数表来找到对应的虚函数,这就是虚函数的实现原理。注意一点,如果基类已经插入了vptr, 则派生类将继承和重用该vptr。vptr(一般在对象内存模型的顶部)必须随着对象类型的变化而不断地改变它的指向,以保证其值和当前对象的实际类型是一致的。

  以上这些概念都是C++程序员很熟悉的,下面通过一些具体的例子来强化一下对这些概念的理解。

1. 

#include<iostream>
using namespace std;

class IRectangle
{
public:
    virtual ~IRectangle() {}
    virtual void Draw() = 0;
};

class Rectangle: public IRectangle
{
public:
    virtual ~Rectangle() {}
    virtual void Draw(int scale)
    {
        cout << "Rectangle::Draw(int)" << endl;
    }
    virtual void Draw()
    {
        cout << "Rectangle::Draw()" << endl;
    }
};

int main(void)
{
    IRectangle *pI = new Rectangle;
    pI->Draw();
    pI->Draw(200);
    delete pI;
    return 0;
}

  该段代码编译失败:

C:/Users/zhuyp/Desktop>g++ -Wall test.cpp -o test -g

test.cpp: In function ‘int main()’:
test.cpp:29:17: error: no matching function for call to ‘IRectangle::Draw(int)’
pI->Draw(200);
^
test.cpp:29:17: note: candidate is:
test.cpp:8:18: note: virtual void IRectangle::Draw()
virtual void Draw() = 0;
^
test.cpp:8:18: note: candidate expects 0 arguments, 1 provided

C:/Users/zhuyp/Desktop>

  以上信息表明,在父类IRectangle中并没有Draw(int)这个函数。确实,在父类IRectangle中没有这样签名的函数,但是不是多态吗,new 的不是子类Rectangle吗?我们注意到指针 pI 虽然指向子类,但是本身确是父类 IRectangle 类型,因此在执行 pI->draw(200)的时候查找父类vtable,父类的vtable 中没有Draw(int)类型的函数,因此编译错误。

  如果将 pI->draw(200) 这一句修改,将pI进行一个down cast 则编译正常,dynamic_cast<Rectangle *>(pI)->draw(200); 此时调用的是子类的指针,查找的是子类的vtable,该vtable中有签名为 draw(int) 的函数,因此不会有问题。

2.

#include <iostream>
using namespace std;

class Base
{
public:
    ~Base()
    {
        cout << "~Base()" << endl;
    }
    void fun()
    {
        cout << "Base::fun()"  << endl;
    }
};

class Derived : public Base
{
public:
    ~Derived()
    {
        cout << "~Derived()" << endl;
    }
    virtual void fun()
    {
        cout << "Derived::fun()"  << endl;
    }
};

int main()
{
    Derived *dp = new Derived;
    Base *p = dp;
    p->fun();
    cout << sizeof(Base) << endl;
    cout << sizeof(Derived) << endl;
    cout << (void *)dp << endl;
    cout << (void *)p << endl;
    delete p;
    p = NULL;

    return 0;
}

  编译并运行程序:

C:/Users/zhuyp/Desktop>test.exe
Base::fun()
1
8
0x3856a0
0x3856a0
~Base()

  编译器使用的是gcc4.8.1 可以看出 p 和 pb 的值是相同的,因此可以得出结论,现代C++编译器已经没有为了性能的问题将vptr指针放在类内存模型的最前面了。

3.

#include<iostream>
using namespace std;

class B
{
    int b;
public:
    virtual ~B()
    {
        cout << "B::~B()" << endl;
    }
};

class D: public B
{
    int i;
    int j;
public:
    virtual ~D()
    {
        cout << "D::~D()" << endl;
    }
};

int main(void)
{
    cout << "sizeB:" << sizeof(B) << " sizeD:" << sizeof(D) << endl;
    char *ch = NULL;
    
    B *pb = new D[2];

    cout<<"size *pb "<<sizeof(pb)<<"/tend"<<endl;
    
    delete [] pb;

    return 0;
}

  程序运行出错,在输出 pb 的大小之后。可见是在delete [] pb 的时候出了问题。

  我们知道释放申请的数组空间的时候需要使用 delete [] ,那 delete 怎么知道要释放多大的内存呢?delete[]  的实现包含指针的算术运算,并且需要依次调用每个指针指向的元素的析构函数,然后释放整个数组元素的内存。

  由于C++中多态的存在,父类指针可能指向的是子类的内存空间。由于上面的例子中delete [] 释放的是多态数组的空间,delete[] 计算空间按照 B 类的大小来计算,每次偏移调用析构函数是按照B类来进行的,而该数组实际上存放的是D类的指针释放的大小不对(由于 sizeof(B) != sizeof(D) ,),因此会崩溃。

C:/Users/zhuyp/Desktop>test.exe
sizeB:16 sizeD:24
size *pb 8 end

注意:本代码在64bit环境中执行的,因此 *pb 是 8.

 

Win7 下安装ubuntu14.04双系统

  之前canonical取消了wubi,在ubuntu14.04的ISO里面又发现了这个玩意儿,使用wubi安装很简单。将ISO解压出来之后双击wubi.exe 不断向下操作进行了(途中会出现一些错误提示,先不要管)。

  但是当安装完成之后发现无法进入图形界面,在命令行“startX”神马的也不行了。仔细回忆一下在安装的时候出现的错误:无法为某些目录分配挂载点,这样就意味着,tmp或者var等等这些重要的目录都不能够被正确的挂载在磁盘的挂载点上面。

  该信息表明:当前无法为某些目录分配挂载点,这样就意味着,tmp或者var等等这些重要的目录都不能够被正确的挂载在磁盘的挂载点上面。导致的结果:一大半的程序无法正确的运行,并且部分系统的配置数据将无法保存在计算机的硬盘当中。

  在进入Ubuntu的Grub启动项管理界面后,我们选中「Ubuntu」项后按下「e」键表明编辑当前的启动项代码。然后在这一大串的代码中找到「ro」的参数,将其修改为「rw」然后按下「F10」键执行这段引导代码,并且引导进入Ubuntu作业系统。

  等待到进入到Ubuntu14.04的图形界面的桌面之后,我们打开超级终端,并且输入一句这样的命令并回车:
  #>sudo gedit /etc/grub.d/10_lupin
  然后按下「Ctrl + F」并且输入「ro $」(注意ro后面有一个空格),然后将文中的「ro」修改为「rw」并保存退出。
  最后再更新一下Grub的启动项即可,在超级终端中输入如下命令:
  #>sudo update-grub
  重启计算机即可看到想要的效果了。

 

  接下来进行一些基本的配置:

 

安装flash:

  #>sudo rm /var/lib/dpkg/updates/*
  #>sudo apt-get update
  #>sudo apt-get upgrade
  #>sudo apt-get install flashplugin-nonfree

  安装完flash之后需要重启firefox才能生效。

当然也可以选择安装一个chrome

获取安装包(前提是你能够上google):

  #>wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb  

安装deb:

  #>sudo dpkg -i google-chrome-stable_current_amd64.deb

但是安装时会出现问题,执行下面命令:

  #>sudo apt-get install libxss1 libappindicator1 libindicator7

之后就可以使用Chrome了。 

 

使用过Centos的对任意位置右键打开终端都是比较怀念的,可以通过以下方式来增加这个功能

sudo apt-get install nautilus-open-terminal

重新加载文件管理器

nautilus -q

安装一个libevent:

#>sudo apt-cache search libevent

选择安装libevent-dev

#>sudo apt-get install libevent-dev

 

ubuntu 上使用valgrind

  Valgrind是一个GPL的软件,用于Linux(For x86, amd64 and ppc32)程序的内存调试和代码剖析。你可以在它的环境中运行你的程序来监视内存的使用情况,比如C 语言中的malloc和free或者 C++中的new和 delete。使用Valgrind的工具包,你可以自动的检测许多内存管理和线程的bug,避免花费太多的时间在bug寻找上,使得你的程序更加稳固。

  Valgrind的主要功能
  Valgrind工具包包含多个工具,如Memcheck,Cachegrind,Helgrind, Callgrind,Massif。下面分别介绍个工具的作用:

Memcheck 工具主要检查下面的程序错误:

  1.使用未初始化的内存 (Use of uninitialised memory)
  2.使用已经释放了的内存 (Reading/writing memory after it has been free’d)
  3.使用超过 malloc分配的内存空间(Reading/writing off the end of malloc’d blocks)
  4.对堆栈的非法访问 (Reading/writing inappropriate areas on the stack)
  5.申请的空间是否有释放 (Memory leaks – where pointers to malloc’d blocks are lost forever)
  6.malloc/free/new/delete申请和释放内存的匹配(Mismatched use of malloc/new/new [] vs free/delete/delete [])
  7.src和dst的重叠(Overlapping src and dst pointers in memcpy() and related functions)
Callgrind
  Callgrind收集程序运行时的一些数据,函数调用关系等信息,还可以有选择地进行cache 模拟。在运行结束时,它会把分析数据写入一个文件。callgrind_annotate可以把这个文件的内容转化成可读的形式。

Cachegrind
它模拟 CPU中的一级缓存I1,D1和L2二级缓存,能够精确地指出程序中 cache的丢失和命中。如果需要,它还能够为我们提供cache丢失次数,内存引用次数,以及每行代码,每个函数,每个模块,整个程序产生的指令数。这对优化程序有很大的帮助。

Helgrind
  它主要用来检查多线程程序中出现的竞争问题。Helgrind 寻找内存中被多个线程访问,而又没有一贯加锁的区域,这些区域往往是线程之间失去同步的地方,而且会导致难以发掘的错误。Helgrind实现了名为” Eraser” 的竞争检测算法,并做了进一步改进,减少了报告错误的次数。

Massif
  堆栈分析器,它能测量程序在堆栈中使用了多少内存,告诉我们堆块,堆管理块和栈的大小。Massif能帮助我们减少内存的使用,在带有虚拟内存的现代系统中,它还能够加速我们程序的运行,减少程序停留在交换区中的几率。

Ubuntu 安装valgrind:

#> sudo apt-get install valgrind

valgrind 使用:

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

int main()
{

    char *ptr = (char *)malloc(1024);
    
    ptr[1024] = 0; //

    memcpy(ptr+1, ptr, 100);

    char ch = ptr[1024];

    free(ptr);
    free(ptr);

    char *ptr1;
    *ptr1 = 'a';

    char *ptr2 = (char *)malloc(1024);

    return 0;
}

#> valgrind –tool=memcheck –leak-check=yes ./valgTest

ubuntu 上使用valgrind

  注意在编译程序的时候加上-g选项,打印错误信息的时候会给出行号。上面的执行结果给出了六个错误。

  下面看一个多线程竞争的情况:

#include <pthread.h>
#include <stdio.h>
 
int a = 0;
 
void* child_fn (void* arg)
{
         a++;
         return NULL;
}
 
int main () 
{
         pthread_t child;
         pthread_create(&child,NULL, child_fn, NULL);
         a++;
         pthread_join(child,NULL);
         return 0;
}

 

zhuyp@ubuntu:~/valgrind$ valgrind –tool=helgrind ./helTest
==5639== Helgrind, a thread error detector
==5639== Copyright (C) 2007-2013, and GNU GPL’d, by OpenWorks LLP et al.
==5639== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==5639== Command: ./helTest
==5639==
==5639== —Thread-Announcement——————————————
==5639==
==5639== Thread #1 is the program’s root thread
==5639==
==5639== —Thread-Announcement——————————————
==5639==
==5639== Thread #2 was created
==5639== at 0x51562CE: clone (clone.S:74)
==5639== by 0x4E44199: do_clone.constprop.3 (createthread.c:75)
==5639== by 0x4E458BA: pthread_create@@GLIBC_2.2.5 (createthread.c:245)
==5639== by 0x4C30C90: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5639== by 0x40068D: main (helTest.c:15)
==5639==
==5639== —————————————————————-
==5639==
==5639== Possible data race during read of size 4 at 0x60104C by thread #1
==5639== Locks held: none
==5639== at 0x40068E: main (helTest.c:16)
==5639==
==5639== This conflicts with a previous write of size 4 by thread #2
==5639== Locks held: none
==5639== at 0x40065E: child_fn (helTest.c:8)
==5639== by 0x4C30E26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5639== by 0x4E45181: start_thread (pthread_create.c:312)
==5639== by 0x515630C: clone (clone.S:111)
==5639==
==5639== —————————————————————-
==5639==
==5639== Possible data race during write of size 4 at 0x60104C by thread #1
==5639== Locks held: none
==5639== at 0x400697: main (helTest.c:16)
==5639==
==5639== This conflicts with a previous write of size 4 by thread #2
==5639== Locks held: none
==5639== at 0x40065E: child_fn (helTest.c:8)
==5639== by 0x4C30E26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5639== by 0x4E45181: start_thread (pthread_create.c:312)
==5639== by 0x515630C: clone (clone.S:111)
==5639==
==5639==
==5639== For counts of detected and suppressed errors, rerun with: -v
==5639== Use –history-level=approx or =none to gain increased speed, at
==5639== the cost of reduced accuracy of conflicting-access information
==5639== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

 前面写过一个使用coredump调试死锁的方法,这里使用valgrind 的 helgrind 工具也可以检查出死锁问题。

#include <iostream>
#include <thread>
#include <mutex>
#include <chrono>
using namespace std;

mutex m1,m2;


void func_2()
{
    m2.lock();
    cout<< "about to dead_lock"<<endl;
    m1.lock();
    
}

void func_1()
{
    m1.lock();
    
    chrono::milliseconds dura( 1000 );// delay to trigger dead_lock
    this_thread::sleep_for( dura );
        
    m2.lock();
    
}


int main()
{

    thread t1(func_1);

    thread t2(func_2);
    
    t1.join();
    t2.join();
    return 0;

}

 

zhuyp@ubuntu:~/valgrind$ g++ -Wall dead_lock_demo.cpp -o dead_lock_demo -g -std=c++11 -lpthread
zhuyp@ubuntu:~/valgrind$ valgrind –tool=helgrind ./dead_lock_demo
==5646== Helgrind, a thread error detector
==5646== Copyright (C) 2007-2013, and GNU GPL’d, by OpenWorks LLP et al.
==5646== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==5646== Command: ./dead_lock_demo
==5646==
about to dead_lock  // 执行到这里,Ctrl + C 结束进程,则打印出如下信息
^C==5646== —Thread-Announcement—————————————— 
==5646==
==5646== Thread #2 was created
==5646== at 0x56702CE: clone (clone.S:74)
==5646== by 0x4E44199: do_clone.constprop.3 (createthread.c:75)
==5646== by 0x4E458BA: pthread_create@@GLIBC_2.2.5 (createthread.c:245)
==5646== by 0x4C30C90: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5646== by 0x510CE3E: std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==5646== by 0x401789: std::thread::thread<void (&)()>(void (&)()) (thread:135)
==5646== by 0x40112D: main (dead_lock_demo.cpp:33)
==5646==
==5646== —————————————————————-
==5646==
==5646== Thread #2: Exiting thread still holds 1 lock
==5646== at 0x4E4BF2C: __lll_lock_wait (lowlevellock.S:135)
==5646== by 0x4E47656: _L_lock_909 (pthread_mutex_lock.c:151)
==5646== by 0x4E4747E: pthread_mutex_lock (pthread_mutex_lock.c:79)
==5646== by 0x4C32072: pthread_mutex_lock (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5646== by 0x40101B: __gthread_mutex_lock(pthread_mutex_t*) (gthr-default.h:748)
==5646== by 0x401421: std::mutex::lock() (mutex:134)
==5646== by 0x401111: func_1() (dead_lock_demo.cpp:25)
==5646== by 0x40278C: void std::_Bind_simple<void (*())()>::_M_invoke<>(std::_Index_tuple<>) (functional:1732)
==5646== by 0x4026E6: std::_Bind_simple<void (*())()>::operator()() (functional:1720)
==5646== by 0x40267F: std::thread::_Impl<std::_Bind_simple<void (*())()> >::_M_run() (thread:115)
==5646== by 0x510CBEF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==5646== by 0x4C30E26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5646==
==5646== —Thread-Announcement——————————————
==5646==
==5646== Thread #3 was created
==5646== at 0x56702CE: clone (clone.S:74)
==5646== by 0x4E44199: do_clone.constprop.3 (createthread.c:75)
==5646== by 0x4E458BA: pthread_create@@GLIBC_2.2.5 (createthread.c:245)
==5646== by 0x4C30C90: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5646== by 0x510CE3E: std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==5646== by 0x401789: std::thread::thread<void (&)()>(void (&)()) (thread:135)
==5646== by 0x40113E: main (dead_lock_demo.cpp:35)
==5646==
==5646== —————————————————————-
==5646==
==5646== Thread #3: Exiting thread still holds 1 lock
==5646== at 0x4E4BF2C: __lll_lock_wait (lowlevellock.S:135)
==5646== by 0x4E47656: _L_lock_909 (pthread_mutex_lock.c:151)
==5646== by 0x4E4747E: pthread_mutex_lock (pthread_mutex_lock.c:79)
==5646== by 0x4C32072: pthread_mutex_lock (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5646== by 0x40101B: __gthread_mutex_lock(pthread_mutex_t*) (gthr-default.h:748)
==5646== by 0x401421: std::mutex::lock() (mutex:134)
==5646== by 0x4010DF: func_2() (dead_lock_demo.cpp:14)
==5646== by 0x40278C: void std::_Bind_simple<void (*())()>::_M_invoke<>(std::_Index_tuple<>) (functional:1732)
==5646== by 0x4026E6: std::_Bind_simple<void (*())()>::operator()() (functional:1720)
==5646== by 0x40267F: std::thread::_Impl<std::_Bind_simple<void (*())()> >::_M_run() (thread:115)
==5646== by 0x510CBEF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==5646== by 0x4C30E26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5646==
==5646==
==5646== For counts of detected and suppressed errors, rerun with: -v
==5646== Use –history-level=approx or =none to gain increased speed, at
==5646== the cost of reduced accuracy of conflicting-access information
==5646== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 1 from 1)

吐槽一下,刚刚在Linux操作并编辑该博文,各种不适应啊,还是换到Windows下来编辑要方便些。。。