微尘--KeepMoving

为了忘却的记忆
posts - 3, comments - 2, trackbacks - 0, articles - 13
  C++博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

2008年3月7日

 转自 chenxixia 的 Blog

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=455591



设有一个Win32下的可执行文件MyApp.exe,这是一个Win32应用程序,符合标准的PE格式。MyApp.exe的主要执行代码都集中在其源文件MyApp.cpp中,该文件第一个被执行的函数是WinMain。初学者会认为程序就是首先从这个WinMain函数开始执行,其实不然。

    在WinMain函数被执行之前,有一系列复杂的加载动作,还要执行一大段启动代码。运行程序MyApp.exe时,操作系统的加载程序首先为进程分配一个4GB的虚拟地址空间,然后把程序MyApp.exe所占用的磁盘空间作为虚拟内存映射到这个4GB的虚拟地址空间中。一般情况下,会映射到虚拟地址空间中0X00400000的位置。加载一个应用程序的时间比一般人所设想的要少,因为加载一个PE文件并不是把这个文件整个一次性的从磁盘读到内存中,而是简单的做一个内存映射,映射一个大文件和映射一个小文件所花费的时间相差无几。当然,真正执行文件中的代码时,操作系统还是要把存在于磁盘上的虚拟内存中的代码交换到物理内存(RAM)中。但是,这种交换也不是把整个文件所占用的虚拟地址空间一次性的全部从磁盘交换到物理内存中,操作系统会根据需要和内存占用情况交换一页或多页。当然,这种交换是双向的,即存在于物理内存中的一部分当前没有被使用的页也可能被交换到磁盘中。

    接着,系统在内核中创建进程对象和主线程对象以及其它内容。

    然后操作系统的加载程序搜索PE文件中的引入表,加载所有应用程序所使用的动态链接库。对动态链接库的加载与对应用程序的加载完全类似。

    再接着,操作系统执行PE文件首部所指定地址处的代码,开始应用程序主线程的执行。首先被执行的代码并不是MyApp中的WinMain函数,而是被称为C Runtime startup code的WinMainCRTStartup函数,该函数是连接时由连接程序附加到文件MyApp.exe中的。该函数得到新进程的全部命令行指针和环境变量的指针,完成一些C运行时全局变量以及C运行时内存分配函数的初始化工作。如果使用C++编程,还要执行全局类对象的构造函数。最后,WinMainCRTStartup函数调用WinMain函数。

   WinMainCRTStartup函数传给WinMain函数的4个参数分别为:hInstance、hPrevInstance、lpCmdline、nCmdShow。

    hInstance:该进程所对应的应用程序当前实例的句柄。WinMainCRTStartup函数通过调用GetStartupInfo函数获得该参数的值。该参数实际上是应用程序被加载到进程虚拟地址空间的地址,通常情况下,对于大多数进程,该参数总是0X00400000。

    hPrevInstance:应用程序前一实例的句柄。由于Win32应用程序的每一个实例总是运行在自己的独立的进程地址空间中,因此,对于Win32应用程序,WinMainCRTStartup函数传给该参数的值总是NULL。如果应用程序希望知道是否有另一个实例在运行,可以通过线程同步技术,创建一个具有唯一名称的互斥量,通过检测这个互斥量是否存在可以知道是否有另一个实例在运行。

    lpCmdline:命令行参数的指针。该指针指向一个以0结尾的字符串,该字符串不包括应用程序名。

    nCmdShow:指定如何显示应用程序窗口。如果该程序通过在资源管理器中双击图标运行,WinMainCRTStartup函数传给该参数的值为SW_SHOWNORMAL。如果通过在另一个应用程序中调用CreatProcess函数运行,该参数由CreatProcess函数的参数lpStartupInfo(STARTUPINFO.wShowWindow)指定。



 

posted @ 2008-03-07 16:38 微尘 阅读(525) | 评论 (0)编辑 收藏

2008年2月29日

 

 

本文档深入分析了std::deque,并提供了一个指导思想:当考虑到内存分配和执行性能的时候,使用std::deque要比std::vector好。

  介绍

  本文深入地研究了std::deque 容器。本文将讨论在一些情况下使用deque> 比vector更好。读完这篇文章后读者应该能够理解在容量增长的过程中deque 与vector在内存分配和性能的不同表现。由于deque> 和vector的用法很相似,读者可以参考vector 文档中介绍如何使用STL容器。

  Deque总览

  deque和vector一样都是标准模板库中的内容,deque是双端队列,在接口上和vector非常相似,在许多操作的地方可以直接替换。假如读者已经能够有效地使用vector容器,下面提供deque的成员函数和操作,进行对比参考。

  Deque成员函数

函数
描述
c.assign(beg,end)
c.assign(n,elem)
将[beg; end)区间中的数据赋值给c。
将n个elem的拷贝赋值给c。
c.at(idx)
传回索引idx所指的数据,如果idx越界,抛出out_of_range。
c.back()
传回最后一个数据,不检查这个数据是否存在。
c.begin()
传回迭代器重的可一个数据。
c.clear()
移除容器中所有数据。
deque<Elem> c
deque<Elem> c1(c2)
Deque<Elem> c(n)
Deque<Elem> c(n, elem)
Deque<Elem> c(beg,end)
c.~deque<Elem>()
创建一个空的deque。
复制一个deque。
创建一个deque,含有n个数据,数据均已缺省构造产生。
创建一个含有n个elem拷贝的deque。
创建一个以[beg;end)区间的deque。
销毁所有数据,释放内存。
c.empty()
判断容器是否为空。
c.end()
指向迭代器中的最后一个数据地址。
c.erase(pos)
c.erase(beg,end)
删除pos位置的数据,传回下一个数据的位置。
删除[beg,end)区间的数据,传回下一个数据的位置。
c.front()
传回地一个数据。
get_allocator
使用构造函数返回一个拷贝。
c.insert(pos,elem)
c.insert(pos,n,elem)
c.insert(pos,beg,end)
在pos位置插入一个elem拷贝,传回新数据位置。
在pos位置插入>n个elem数据。无返回值。
在pos位置插入在[beg,end)区间的数据。无返回值。
c.max_size()
返回容器中最大数据的数量。
c.pop_back()
删除最后一个数据。
c.pop_front()
删除头部数据。
c.push_back(elem)
在尾部加入一个数据。
c.push_front(elem)
在头部插入一个数据。
c.rbegin()
传回一个逆向队列的第一个数据。
c.rend()
传回一个逆向队列的最后一个数据的下一个位置。
c.resize(num)
重新指定队列的长度。
c.size()
返回容器中实际数据的个数。
C1.swap(c2)
Swap(c1,c2)
将c1和c2元素互换。
同上操作。

  Deque操作

函数
描述
operator[]
返回容器中指定位置的一个引用。

  上面这些特征和vector明显相似,所以我们会提出下面的疑问。

  问题:如果deque和vector可以提供相同功能的时候,我们使用哪一个更好呢?

  回答:如果你要问的话,就使用vector吧。

  或者你给个解释?

  非常高兴你这样问,的确,这并不是无中生有的,事实上,在C++标准里解释了这个问题,下面有一个片断:

  vector在默认情况下是典型的使用序列的方法,对于deque,当使用插入删除操作的时候是一个更好的选择。

  有趣的是,本文就是要非常彻底地理解这句话。

  什么是新的?

  细读上面两张表格,你会发现和vector比较这里增加了两个函数。

  1、c.push_front(elem) —— 在头部插入一个数据。

  2、c.pop_front() —— 删除头部数据。

  调用方法和c.push_back(elem)和c.pop_back()相同,这些将来会告诉我们对于deque> 会非常有用,deque可以在前后加入数据。>

  缺少了什么?

  同时你也会发现相对于vector> 缺少了两个函数,你将了解到deque> 不需要它们。

  1、capacity()—— 返回vector当前的容量。

  2、reserve() —— 给指定大小的vector> 分配空间。

  这里是我们真正研究的开始,这里说明deque> 和vector它们在管理内部存储的时候是完全不同的。deque是大块大块地分配内存,每次插入固定数量的数据。vector是就近分配内存(这可能不是一个坏的事情)。但我们应该关注是,vector每次增加的内存足够大的时候,在当前的内存不够的情况。下面的实验来验证deque不需要capacity()和reserve()> 是非常有道理的。

  实验一 —— 增长的容器

  目的

  目的是通过实验来观察deque和vector在容量增长的时候有什么不同。用图形来说明它们在分配内存和执行效率上的不同。

  描述

  这个实验的测试程序是从一个文件中读取文本内容,每行作为一个数据使用push_back插入到deque> 和vector中,通过多次读取文件来实现插入大量的数据,下面这个类就是为了测试这个内容:

#include <deque>
#include <fstream>
#include <string>
#include <vector>

static enum modes
{
 FM_INVALID = 0,
 FM_VECTOR,
 FM_DEQUE
};

class CVectorDequeTest
{
 public:
  CVectorDequeTest();
  void ReadTestFile(const char* szFile, int iMode)
  {
   char buff[0xFFFF] = {0};
   std::ifstream inFile;
   inFile.open(szFile);
   while(!inFile.eof())
   {
    inFile.getline(buff, sizeof(buff));
    if(iMode == FM_VECTOR)
     m_vData.push_back(buff);
    else if(iMode == FM_DEQUE)
     m_dData.push_back(buff);
   }
   inFile.close();
  }
  virtual ~CVectorDequeTest();
 protected:
  std::vector<std::string> m_vData;
  std::deque<std::string> m_dData;
};


  结果

  测试程序运行的平台和一些条件:

CPU 1.8 GHz Pentium 4
内存 1.50 GB
操作系统 W2K-SP4
文件中的行数 9874
平均每行字母个数
1755.85
读文件的次数
45
总共插入的数据个数 444330


  使用Windows任务管理器来记录执行效率,本程序中使用了Laurent Guinnard 的CDuration类。消耗系统资源如下图:


  注意在vector分配内存的最高峰,vector在分配内存的时候是怎样达到最高值,deque就是这样的,它在插入数据的同时,内存直线增长,首先deque的这种内存分配单元进行回收的话,存在意想不到的后果,我们希望它的分配内存看上去和vector一样,通过上面的测试我们需要进一步的测试,现提出一个假设:假设deque分配的内存不是连续的,一定需要释放和收回内存,我们将这些假设加入后面的测试中,但是首先让我们从执行的性能外表分析一下这个实验。

  究竟分配内存需要消耗多久?

  注意看下面这张图片,vector在不插入数据的时候在进行寻求分配更多内存。


  同时我们也注意到使用push_back插入一组数据消耗的时间,注意,在这里每插入一组数据代表着9874个串,平均每个串的长度是1755.85。

 

实验二—— vector::reserve()的资源

  目的

  这个实验的目的是vector在加入大量数据之前调用reserve(),和deque进行比较,看它们的内存分配和执行效率怎么样?

  描述

  本实验中的测试基本上和实验一相同,除了在测试类的构造函数中加入下面这行代码:

m_vData.reserve(1000000);

  结果

  测试程序运行的平台和一些条件:

CPU
1.8 GHz Pentium 4
内存
1.50 GB
操作系统
W2K-SP4
文件中的行数
9874
平均每行字母个数
1755.85
读文件的次数
70
总共插入的数据个数
691180

  使用Windows任务管理器来记录执行效率,本程序中使用了>Laurent Guinnard 的CDuration类。消耗系统资源如下图:


  我们注意到vector不在需要分配花费多余的时间分配内存了,这是由于我们使用了reserve()对于所测试的>691180个数据为我们每一次插入大量数据的时候保留了足够的内存空间,对于deque存储分配的假设,观察这个测试中的内存分配图形和上一个图形,我们需要进一步量化这个测试。

  怎样改良内存分配的性能呢?

  下面这个图例说明随着数据的增加,容量在增加:


  当增加数据的时候对容量的增加在vector和deque执行效率基本一样,然而,vector在插入数据的时候有一些零星的时间消耗,看下面的图例:


  通过统计分析vector和deque在插入平均为>1755.85长度的>9874个数据所花费的时间,下面是总结的表格:


Vector

Deque

Mean

0.603724814 sec

Maximum

0.738313000 sec

Minimum

0.559959000 sec


Std. Dev

0.037795736 sec

6-Sigma

0.226774416 sec

Mean

0.588021114 sec

Maximum

0.615617000 sec

Minimum

0.567503000 sec

Std. Dev

0.009907800 sec

6-Sigma

0.059446800 sec


  实验三——内存回收

  目的

  本实验是对假设deque分配的内存不是临近的,而且很难回收进行量化测试分析。

  描述

  在本实验中再次用到了实验一中的代码,在调用函数中加入记录增加数据执行的效率具体入下面操作:

for(xRun=0; xRun<NUMBER_OF_XRUNS; xRun++)
{
 df = new CVectorDequeTest;
 elapsed_time = 0;

 for(i=0; i<NUMBER_OF_RUNS*xRun; i++)
 {
  cout << "Deque - Run " << i << " of " <<
  NUMBER_OF_RUNS*xRun << "... ";
  df->ReadTestFile("F:\\huge.csv",DF_DEQUE);
  deque_data.push_back(datapoint());
  deque_data.back().time_to_read = df->GetProcessTime();
  elapsed_time += deque_data.back().time_to_read;
  deque_data.back().elapsed_time = elapsed_time;
  cout << deque_data.back().time_to_read << " seconds\n";
 }
 vnElements.push_back(df->GetDequeSize());
 cout << "\n\nDeleting... ";
 del_deque.Start();
 delete df;
 del_deque.Stop();
 cout << del_deque.GetDuration()/1000000.0 << " seconds.\n\n";
 vTimeToDelete.push_back(del_deque.GetDuration()/1000000.0);
}

  结果

  本测试和上面两个实验在相同的平台上运行,除了插入的数据由>9874到>691180,需要插入>70次,下面图例显示了>deque在插入数据的时候分配内存的情况,在deque里插入了平均每个长度为>1755.85的字符串。>


  尽管从几个曲线图中看到的实际消耗时间不同,但些曲线图都精确到了>R2=95.15%。所给的数据点都实际背离了下表中统计的曲线图数据:

deque Results

Mean

0.007089269 sec

Maximum

11.02838496 sec

Minimum

-15.25901667 sec

Std. Dev

3.3803636 sec

6-Sigma

20.2821816 sec

  在相同的情况下比较vector的结果是非常有意义的。下面图就是将vector和deque在相同的情况下分配内存消耗的时间比较图:


  这些数据在这个测试中是>R2=82.12%。这或许可以经过每个点反复运行得到更加优化,在这个问题中这些数据适当地标注了这些点,所给的数据点都实际背离了下表中统计的曲线图数据:


vector Results

Mean

-0.007122715sec

Maximum

0.283452127 sec

Minimum

-0.26724459sec

Std. Dev

0.144572356sec

6-Sigma

0.867434136sec


实验四—— vector::insert() 和 deque::insert() 执行特点比较

  目的

  deque主张使用参数为常量的insert()。但怎么样能和vector::insert()比较一下呢?本实验的目的就是比较一下vector::insert()> 和 deque::insert()的工作特点。

  描述

  在容器的容器多次插入数据,在这里可能不符合你的需求,既然这样你可以使用insert(),试验代码也和实验一基本一样,使用insert()代替push_back(),使用insert(>)来测试。

  结果

  当插入常量给deque的时候,从下图可以看出和vector的对比来。


  注意两张图片中时间轴的不同,这是将>61810个数据插入到容器中。


  实验五——读取容器的性能

  目的

  这个实验将测试vector::at(),vector::operator[],deque::at()和deque::operator[]的性能。首先应该是operator[]比at()效率要高,因为它不进行边界检查,同时也比较vector和deque。

  描述

  这个实验将测试中的容器有1000000个类型为std::string,每个字符串长度为1024的数据,分别使用at()和operator[]这两个操作来访问容器容器的数据,测试它们运行的时间,这个测试执行50次,统计每次执行的结果。

  结果

  我们看到使用vector和deque访问容器中的数据,他们执行的性能差别很小,使用operator[]和at()访问数据的性能差别几乎可以忽略不计,下面是统计的结果:


vector::at()

Mean

1.177088125sec

Maximum

1.189580000sec

Minimum

1.168340000sec

Std. Dev

0.006495193sec

6-Sigma

0.038971158sec

deque::at()

Mean

1.182364375sec

Maximum

1.226860000sec

Minimum

1.161270000sec

Std. Dev

0.016362148sec

6-Sigma

0.098172888sec

vector::operator[]

Mean

1.164221042sec

Maximum

1.192550000sec

Minimum

1.155690000sec

Std. Dev

0.007698520sec

6-Sigma

0.046191120sec

deque::operator[]

Mean

1.181507292sec

Maximum

1.218540000 sec

Minimum

1.162710000sec

Std. Dev

0.010275712sec

6-Sigma

0.061654272sec

  结论

  在这篇文章中我们覆盖了多种不同的情况来选择我们到底是该使用vector还是deque。让我们总结一下测试的结果看下面几个结论。

  当执行大数据量的调用push_back()的时候,记住要调用vector::reserve()。

  在实验一中我们研究了vector和deque在插入数据的情况。通过这些假设,我们可以看出deque分配的空间是预先分配好的,deque维持一个固定增长率,在vector实验中我们考虑到应该调用vecor::reserve()>.然后在下面这个例子验证了我们的假设,在使用vector的时候调用reserve()能够膀子我们预先分配空间,这将是vector一个默认选择的操作。

  当你分配很多内存单元的时候,记住使用deque回收内存要比vector消耗时间多。

  在实验三中我们探讨了vector和deque在回收非邻接内存块上的不同,分别证明了vector在分配内存的时候是线性增长,而deque是指数增长,同样,vector要回收的内存比deque多的多,如果你循环调用了push_back(),那么deque将获取大量的内存,而且是临近的。我们通过测试发现在分配内存单元消耗的时间和vector的时间接近。

  如果你计划使用insert(),或者需要pop_front(),那就使用deque。

  由于vector没有提供pop_front()函数,但在实验四的结果中可以看出没有insert()是非常好的,同时也告诉我们为什么deque在STL类中要作为单独的一个类划分出来。

  对于访问数据,vector::at()效率最高。

  在实验五中统计的数据表示,所有访问数据方法的效率是非常接近的,但是vector::at()效率最高。这是因为最优的平衡图访问时间为最低的六个西格玛值。

  最后

  我希望本文能够带你认识deque,而且对它感兴趣或者一个启发,欢迎继续讨论关于vector和deque任何问题和内容。

posted @ 2008-02-29 22:04 微尘 阅读(507) | 评论 (0)编辑 收藏

2008年2月25日

 
       相信大家在编码中,有时会见到某某函数前面加了 extern "C" 的关键字修饰,尤其在模块(Dll)提供的头文件中。但是否很清楚的了解它的作用, 我当时第一次碰到时,其实是懂非懂的^_^。查了些资料,才明白其用法,详细如下。

      1. 首先说下编译器编译函数时,对函数名的处理。
         在C语言中,对函数如: IRoleView* RoleViewCreate(int nType); 编译后生成的函数名是RoleViewCreate
         但是在C++中,由于存在函数重载的特性,所以编译时C++编译器会根据参数、返回值等信息对函数名改编,如上面函数在C++编译器中生成的函数名是 ?RoleViewCreate@@YAPAVIRoleView@@H@z
      
     2. extern "C"的含义。
         extern "C" 有两重含义:
        其一,被修饰的变量或函数是extern的存储类型,它告诉编译器,其声明的变量或函数可以被本模块和外部某块使用。
        其二,被其修饰的函数或变量是按照C语言的方式来编译和链接的。
        注意,extern "C"写法 只在C++中被支持,C语言不支持该写法。
   
    3. extern "C"的两种惯用用法:
        a) 在C++中使用C语言的函数或变量,在包含C语言提供的头文件是,需要用 extern "C" { } 来包含头文件。如下:
           extern "C"
          {
               #include "lua.h"    //lua.h是C编写,并提供的头文件
          }
        这里引用下第1点的函数来说明上述写法的用途:假设lua.h中包含函数 IRoleView* RoleViewCreate(int nType), 那么C语言的编译时生成的函数名是RoleViewCreate,而当C++客户程序去使用它时,默认是按C++的链接方式(即不加以上的 extern "C"时),所以C++客户程序会去外部模块中查找函数名为
?RoleViewCreate@@YAPAVIRoleView@@H@z的函数,这样C++编译器会找不到该函数,报出"无法解析的外部标识符"的错误; 而当加上
extern "C" { } 时,它就告诉编译器头文件中包含的函数或变量要按照C语言的编译链接方式进行,所以C++编译器会去外部模块查找函数名为
RoleViewCreate的函数,从而得到正确结果。

      b) 在C中调用一个C++语言中的函数或变量时,C++的头文件需要添加 extern "C",这是为了让编译器对函数或变量按C语言的方式进行编译,已供C语言调用; 但在C语言中,不能直接包含声明了extern "C"的头文件,而应该在C文件中把在C++头文件中定义的函数,声明为 extern类型,因为在C语言中,并不支持extern "C"的写法;

参考资料:《C++中extern "C" 含义深层探索》作者:宋宝华
                    《C++ Primer》
        

posted @ 2008-02-25 20:46 微尘 阅读(405) | 评论 (0)编辑 收藏