亚洲日本欧美在线,国产精品日韩欧美一区,国产午夜精品视频免费不卡69堂

C++ library series -- in the MFC multiple-thread environment, how to quit worker-thread safely which begins with AfxBeginThread

flagman — Sun, 11 Dec 2011 12:35:00 GMT

In the MFC environment, normally, thread should be launched with AfxBeginThread for taking usage of MFC multiple-thread mechanism; In such mechanism, those datastructures, such as AFX_MODULE_STATE, would be used by MFC framework to maintain related thread information. It runs well when threads, launched with AfxBeginThread, quit before the main thread, which is responsible for initializing C run-time, but if such main thread quit before any other thread launched by AfxBeginThread, the current application would crash.

Such crash comes from the _afxThreadData (CThreadSlotData* _afxThreadData, which is defined in AFXTLS.cpp as global data structure) has been destructed while the main thread quits and it will invoke related function to clean up global data structures, including _afxThreadData definitely.

Consequently, serious developer should prepare for such case (other worker thread quits before main thread).

The reasonable resolve for such issue, would ensure any other threads should quit before the main thread.

.h file

/////////////////////////////////////////////////////////////////////////////

// CSafeEnterLeaveThread thread

class CSafeEnterLeaveThread : public CWinThread

{

DECLARE_DYNCREATE(CSafeEnterLeaveThread)

protected:

CSafeEnterLeaveThread(); // protected constructor used by dynamic creation

// Attributes

public:

// Operations

public:

// Overrides

// ClassWizard generated virtual function overrides

//{{AFX_VIRTUAL(CSafeEnterLeaveThread)

public:

virtual BOOL InitInstance();

virtual int ExitInstance();

//}}AFX_VIRTUAL

// Implementation

protected:

virtual ~CSafeEnterLeaveThread();

// Generated message map functions

//{{AFX_MSG(CSafeEnterLeaveThread)

// NOTE - the ClassWizard will add and remove member functions here.

//}}AFX_MSG

DECLARE_MESSAGE_MAP()

};

.cpp file

/////////////////////////////////////////////////////////////////////////////

// CSafeEnterLeaveThread

IMPLEMENT_DYNCREATE(CSafeEnterLeaveThread, CWinThread)

CSafeEnterLeaveThread::CSafeEnterLeaveThread()

{

}

CSafeEnterLeaveThread::~CSafeEnterLeaveThread()

{

}

BOOL CSafeEnterLeaveThread::InitInstance()

{

// TODO: perform and per-thread initialization here

ASSERT(this->m_hThread);

CMainApp::RegisterMFCThread(this->m_hThread);

return TRUE;

}

int CSafeEnterLeaveThread::ExitInstance()

{

// TODO: perform any per-thread cleanup here

ASSERT(this->m_hThread);

CMainApp::UnRegisterMFCThread(this->m_hThread);

return CWinThread::ExitInstance();

}

BEGIN_MESSAGE_MAP(CSafeEnterLeaveThread, CWinThread)

//{{AFX_MSG_MAP(CSafeEnterLeaveThread)

// NOTE - the ClassWizard will add and remove mapping macros here.

//}}AFX_MSG_MAP

END_MESSAGE_MAP()

And in the CMainApp,

set g_ThreadHandleSet;

HANDLE g_ThreadHandleArray[MAXIMUM_WAIT_OBJECTS];

CCriticalSection g_csGlobalData;

void CAccgbApp::CheckAllOtherMFCThreadsLeave()

{

int count = g_ThreadHandleSet.size();

if (count == 0) return;

set::iterator it;

int idx = 0;

for (it = g_ThreadHandleSet.begin(); it != g_ThreadHandleSet.end() && idx < MAXIMUM_WAIT_OBJECTS; it++, idx++)

{

g_ThreadHandleArray[idx] = *it;

}

if (count > idx) count = idx;

::WaitForMultipleObjects(count, g_ThreadHandleArray, TRUE, INFINITE);

}

void CAccgbApp::CleanupGlobalData()

{

g_csGlobalData.Lock();

g_ThreadHandleSet.empty();

g_csGlobalData.Unlock();

}

BOOL CAccgbApp::RegisterMFCThread(HANDLE hThread)

{

if (hThread == NULL) return FALSE;

g_csGlobalData.Lock();

if (g_ThreadHandleSet.find(hThread) == g_ThreadHandleSet.end())

g_ThreadHandleSet.insert(hThread);

g_csGlobalData.Unlock();

return TRUE;

}

void CAccgbApp::UnRegisterMFCThread(HANDLE hThread)

{

if (hThread == NULL) return;

g_csGlobalData.Lock();

if (g_ThreadHandleSet.find(hThread) != g_ThreadHandleSet.end())

g_ThreadHandleSet.erase(hThread);

g_csGlobalData.Unlock();

}

flagman 2011-12-11 20:35 发表评论

操作�pȝ��怎么�Ҏ��一个HWND句柄�Q�找到相应的代码

flagman — Mon, 04 Apr 2011 06:16:00 GMT

�?�?�?的大作中提到: �?/em>

: 比如我有一个CMyButton的类�Q�我现在有他的一个handle
: �~�译器怎么�Ҏ��q�个句柄扑ֈ�CMyButton的代码的�Q?/em>

�?�?某某的大作中提到: �?br>: �q�个和OS/Compiler没关�p�，是库��L��作用
: 以从某个文章里看的，说MFC用了一个大map�Q�没验证�q?br>: 有本讲GDI的书里，用了WNDCLASS里的extra bytes来实现的�q�个映射

MFC的应用里�Q�每个MFC�U�程�Q�必��要使用MFC方式启动的线�E�）都维护有一个MFC object和HWND之间�?/p>
mapping�Q�整个MFC框架��是使用�q�个机制来实现应用��C++对象和系�l��原生�H�口内核对象之间的关联；

因�ؓ�q�个mapping是以�U�程为单位来�l�护的，每个�U�程间互不关联，所以，一个应用里对于涉及UI�H�口�?/p>
��d��最好是都放在同一个线�E�里面，一般就是当前进�E�的�ȝ��E�，否则可能出现MFC object和HWND之间

兌��不上的问题，而且�q�样的问题还很隐蔽�?br>

至于WNDCLASS�l�构自带的extra bytes域，是以前缺乏应用框架的时代�Q��用Win32 API直接开发时�Q�让每个

�H�口�c�（�q�里的类�Q�不是C++ class的概念，而是Windows�pȝ��H�口定义时的一�U�数据结构）都能有个�?/p>
带一些额外的自定义数据的�I�间�Q�这个空间往往被用来存放与当前�H�口�cȝ��关的用户数据�Q�通常是指�?/p>
某个内存区域的指针，当程序操作这个属于这个窗口类的窗口时��可以根据这个附带的自定义数据（�?/p>
者指针）来操作对应的兌��自定义数据；很多后来出现的框�Ӟ��也都使用了这个extra bytes域，来存�?/p>
框架本��n的一些和�H�口�cȝ��兌��的数据结构。从目前��势看，直接使用WNDCLASS以及extra bytes的可�?/p>
性是微乎其微了，但是如果要做好原生应用的开发，很多底层的实现细节最要还是要知道一下，以便�?/p>
优化�l�构和性能�Q�以及出错时的调试处理；因�ؓ无论是Winform/WPF�Q�还是跨�q�_��的WTL/QT/WxWindows�{?/p>
�{�新型的机制或者框架、类库，只要是在Windows�q�_��上搭建的�Q�那都是��Z��前面说过的这套最基本也是

最核心的Win32 API基础之上�?/p>

flagman 2011-04-04 14:16 发表评论

flagman — Sun, 27 Feb 2011 09:09:00 GMT

�q�道千分题，其实是挺有意思的一题：
提供了点�Q�这里是junction�Q�和点之间的距离�Q�或代�h�Q�；
要求以最短的距离�Q�或最��代��P��遍历所有的点，同时每个点可以多�ơ访问；

初看之下�Q�给人的感觉是图论相关的问题�Q�比如旅行者问题、欧拉环�怹��c�R�?/p>
在思考这个问题的时候，忽然间联惛_��了图��Z��的最��生成树�Q�虽然�ƈ不是真正要去得出最��生成树�Q?/p>
但是按照最��生成树所提供的思�\--�q�点很重�?-那就是图和树之间有着相当密切的关�p�：即��最��生

成树�q�不能直接解册��个问题，但是它们之间存在的这层关�pȝ��提供了解决问题的一个有益的��试�?/p>
向；

于是�Q�思考进了一步，问题�?#8220;�?#8221;��化成�?#8220;�?#8221;--如何把当前这个问题采用树的结构和�Ҏ��表达�?/p>
来：树的根节点，很自然地惛_��了由问题中旅行的起始节点来表达；然后�Q�随着节点的不断加入，树就

自然地生成，此处的关键在于如何生成，或者说节点加入的规则，以及每个节点��Z��适应�q�个规则�Q�所

必须持有的相兛_��性信息：最直接的，父子节点之间的关�p�需要维护，从父节点到子节点的距��（或代

��P��必须要保留，其次�Q�考虑到如果每个节炚w��l�护相关的距��（代�h�Q�信息，那么从当前节点到根节

点的代�h也就可以由此递推得出�Q�进一步，我们所要求出的最短�\径（或最��代��P��不就可以从上�q�这

些节点中�l�护的距��M��息中得出吗？�q�是非常关键的一步，它把当前我们构徏的数据结构和问题的要�?/p>
之间建立起了相当直接的联�p�R��这说明我们目前思考的方向是有价值的而且极有可能��着�q�个方向前行

�Q�可以得出相当不错的�l�果�?/p>
昄��Q�既然要求最短�\径（最��代��P��Q�那么我们目前构建出的这颗Junction树（因�ؓ其上的节点在�?/p>
中的物理含义是代表Junction�Q�那�q�里我们��姑且称其�ؓJunction Tree�Q�，树上的每个节点也应当保留

在其之下的子树的最短�\径（最��代��P��Q�这��q��当于把每个节炚w��作�ؓ根节点，然后求出各条子�\�?/p>
的代��P��q�比较得出最短�\径（最��代��P��Q�以及在�q�条最短�\径上的直接子节点�Q?/p>
每加入一个子节点�Q�就要对上述已构建出的这些数据结构中的信息进行维护，以调整每个节点当前的最

短�\径代价和相应�q�条路径上的直接子节点；当所有原“�?#8221;中的“�?#8221;信息�Q�也��是

(fromJunction,toJuction,ductLength)所代表的（起始点，�l�止点，长度代�h�Q�，都按照上�q�方案加�?/p>
Juction Tree之后�Q�我们可以知道从最初的起始节点�Q�也��是Junction Tree的根节点�Q�到最�l�节点的�Q?/p>
Junction Tree上的某条路径上的叶子节点�Q�的最短（最��代��P��路径了�?/p>
对于Juction Tree�q�个ADT抽象数据�l�构的具体实玎ͼ�考虑��C��先队列中二叉堆的�l�典实现往往使用数组

�Q�同时也��Z��W�合TC SRM一贯的��h��快的�E�序设计风格�Q�我们这里同时��用几个数�l�来�l�护前述构徏

出的数据�l�构�?/p>
//////////////////////////////////////////////////////////////////////////////////////////

#include
#include
#include
using namespace std;

const int NIL = -1;
const int MAX = 50;

int Cost[MAX];
int ParentNode[MAX];
int MaxSubNode[MAX];
int MaxSubCost[MAX];

class PowerOutage
{
public:
int estimateTimeOut(vector fromJunction, vector toJunction, vector

ductLength)
{
  if (!CheckParameter(fromJunction, toJunction, ductLength)) return NIL;

  Ini();
  int count = fromJunction.size();
  for (int i = 0; i < count; i++)
  {
   AddNode(fromJunction[i], toJunction[i], ductLength[i]);
  }

  return CalculateMinCost(fromJunction, toJunction, ductLength);
}
private:
void Ini()
{
  memset(Cost, NIL, sizeof(int) * MAX);
  memset(ParentNode, NIL, sizeof(int) * MAX);
  memset(MaxSubNode, NIL, sizeof(int) * MAX);
  memset(MaxSubCost, 0, sizeof(int) * MAX);
}

bool CheckParameter(const vector& fromJunction, const vector& toJunction,

const vector& ductLength)
{
  if (fromJunction.size() != toJunction.size() || toJunction.size() !=

ductLength.size())
   return false;
  return true;
}

void AddNode(int parent, int child, int cost)
{
  if (parent < 0 || child < 0 || cost < 0) return;

  Cost[child] = cost;
  ParentNode[child] = parent;

  int curParent = parent, curChild = child;
  bool adjustParentCost = true;
  while (adjustParentCost && curParent != NIL)
  {
   int candidateParentMaxSubCost = Cost[curChild] + MaxSubCost

[curChild];
   if (MaxSubCost[curParent] < candidateParentMaxSubCost)
   {
    MaxSubCost[curParent] = candidateParentMaxSubCost;
    MaxSubNode[curParent] = curChild;

    curChild = curParent;
    curParent = ParentNode[curParent];
   }
   else
   {
    adjustParentCost = false;
   }
  }
}

int CalculateMinCost(const vector& fromJunction, const vector&

toJunction, const vector& ductLength)
{
  int len = fromJunction.size();
  int minCost = 0;

  set minCostPath;
  minCostPath.insert(0);
  int curNode = MaxSubNode[0];
  while(curNode != NIL)
  {
   printf("%d;",curNode); // print the min cost path

   minCostPath.insert(curNode);
   curNode = MaxSubNode[curNode];
  }

  for (int i = 0; i < len; i++)
  {
   if (minCostPath.find(toJunction[i]) == minCostPath.end())
    minCost += 2 * ductLength[i];
   else
    minCost += ductLength[i];
  }

  return minCost;
}
};

flagman 2011-02-27 17:09 发表评论

flagman — Sat, 12 Feb 2011 09:21:00 GMT

�?某网友讨论道: �?br>: RT�Q�反��的�Ҏ��发现很��用�?/em>

恰恰相反�Q�有些反��的�Ҏ��是�l�常会被使用到的�?/p>
反射��M��上分成两大特性，一是自省，二是发射�Q?/p>
自省的能力极为重要，而且几乎会天天用刎ͼ�很少见到�q�哪�?net应用中不使用attribute的，而attribute�Ҏ��就是metadata通过在自省能力支撑下实现的；当然自省不单单是attribute�Ҏ��的�q�用�Q�只要是在运行时动态检视程序自�w�的�Ҏ��都要由反射的自省能力来支持�Q�比如Visual Studio的IDE�Q�这个集成开发环境本�w�就�?net应用的好案例�Q�对�?net�l��g的自动探��功能；同时�Q�自省的能力也是��Z��虚拟机��^台的语言�Q�比如c#和java�Q�区别于传统语言比如c和c++的重要特性之一�Q�这提供了程序设计开发更��Z��利和安全的运行时环境�Q�相对而言�Q�在c++�Q�当然是native而不是managed�Q�的环境下，除了RTTI极�ؓ单薄的运行时自省�Q�也��是QT�q�个库通过meta-object system部分模拟了自省的�Ҏ��；

反射的另外一个重要特性就是发��，它让“�E�序可以写程�?#8221;了，��要的说就是在�q�行时动态生成MSIL�q�加载运行以及持久化动态生成的MSIL的能力；��p��个特性的支持�Q�让原先一些程序设计和开发领域相对困隑֒��J�琐的工作，比如元编�E�meta programming�Q�比如动态代理dynamic proxy�Q�比如AOP中的基础设施weaver的实玎ͼ�变得可能或相�Ҏ��于实玎ͼ�反射的特性，也是��Z��虚拟机��^台CLR的支持，以metadata为基��来实现的�Q�所以这也是虚拟机��^台语�a�的特有优势，而在传统语言�q�_��上，�q�是难以实现的；比如关于meta programming�Q�c++��是通过模板�Ҏ��实现的�~�译期meta programming�Q�这与虚拟机�q�_��上实现的�q�行时meta programming�q�是有比较大的差距（比如前者如何保证生成的代码的type-safe�Q�；

以上�q�两个特性，自省和发��，都有个共同点�Q�他们都是围�l�着metadata机制�Q��ƈ在虚拟机�q�_��q�行时环境CLR支持下实现的�Q�前者是�q�行时检视相关的metadata�Q�后者是�q�行时动态生成相关的metadata和MSIL�Q�从�q�点也就可以看出�Q�要��x��入理解这些特性，��需要研�I�metadata和MSIL的实玎ͼ�以及虚拟��行时环境的实玎ͼ�在java�q�_��上，��是bytecode和JVM�Q�；

所以，反射�Q�可能是虚拟机��^台所提供的相�Ҏ��为强�Ԍ��最为复杂，和��^台运行时本��n关系最密切�Q�也是区别于传统语言和运行时最鲜明的特性�?/p>

flagman 2011-02-12 17:21 发表评论

C++ library�p�d�� -- static destructors in multiple threads

flagman — Tue, 08 Feb 2011 12:57:00 GMT

In VC++ 8.0, while code compiled with /clr or /clr:pure, static destructors sometimes would not being properly called before process exites in multiple threads.

CRT incorrectly set a lock at _global_unlock which resulted in such issue.

In CLR-mixed mode, during the inialization of static local object, CRT would call _atexit_m(_CPVFV func) in msilexit.cpp to register a special __clrcall callback function which would be called back to destroy such static object when the current AppDomain quited.

In the multithread environment, _atexit_helper which was invoked by _atexit_m, could register such callbace function successfully because it had been guarded by __global_lock() and __global_unlock(). But in the same environment, the _atexit_m would fail to assign the correct value to __onexitbegin_m and __onexitend_m.

__onexitbegin_m and __onexitend_m were shared by the different threads; It's the key point of such issue. For example, the following statements,

__onexitbegin_m = (_CPVFV *)_encode_pointer(onexitbegin_m);
__onexitend_m = (_CPVFV *)_encode_pointer(onexitend_m);

should also guarded by __global_lock() and __global_unlock() or other syn primitives.

__global_lock();
__onexitbegin_m = (_CPVFV *)_encode_pointer(onexitbegin_m);
__onexitend_m   = (_CPVFV *)_encode_pointer(onexitend_m);
__global_unlock();

extern "C" int __clrcall _atexit_m(_CPVFV func)
{
MANAGED_ASSERT(AppDomain::CurrentDomain->IsDefaultAppDomain(), "This fuction must be called in the default domain");

__global_lock();
_CPVFV* onexitbegin_m = (_CPVFV*)_decode_pointer(__onexitbegin_m);
_CPVFV* onexitend_m = (_CPVFV*)_decode_pointer(__onexitend_m);
__global_unlock();

int retval = _atexit_helper((_CPVFV)_encode_pointer(func), &__exit_list_size, &onexitend_m, &onexitbegin_m);

__global_lock();
__onexitbegin_m = (_CPVFV*)_encode_pointer(onexitbegin_m);
__onexitend_m = (_CPVFV*)_encode_pointer(onexitend_m);
__global_unlock();

return retval;
}

flagman 2011-02-08 20:57 发表评论

C++ library�p�d�� -- STL实现中的ODR “one-definition-rule�?for types

flagman — Sun, 19 Dec 2010 03:09:00 GMT

Linking issue
- While different modules (.obj) using istreambuf_iterator/ostreambuf_iterator, compiled with different options on HID/no-HID and SCL/no-SCL, these modules could not be linked successfully;

The error comes directly from the CLR when a type has multiple definitions that are not consistent based upon the ODR, one-definition-rule for types. And, the linker itself isn't involved.

For example, with one module compile with /D_SECURE_SCL=0, while another is compiled with _SECURE_SCL=1;

At first, it's found that with _SECURE_SCL, the only thing that could be different as following,

#if _SECURE_SCL
    typedef _Range_checked_iterator_tag _Checked_iterator_category;
#endif

But, actually, it's not the typedef that changed the layout the these iterators (istreambuf_iterator/ostreambuf_iterator), and further they don't really use the extra pointer that _SECURE_SCL adds.

Finally, it's found the root cause is that, these iterators, istreambuf_iterator/ostreambuf_iterator had been moved from to , and their ultimate base class had been changed from _Iterator_base_secure to _Iterator_base. And, the layout of _Iterator_base would be different between HID and no-HID, and between SCL and no-SCL. It is the cause where the issue comes from.

What we can learn from such issue,
These iterators really shouldn't derive from either _Iterator_base_secure or _Iterator_base, because these classes contain data members (pointers) which are entirely unused. It would result in unnecessary bloat and extra work being performed in ctor/dtor etc.

Introduce a new class, _Iterator_base_universal, which is defined identically regardless of HID/no-HID and SCL/no-SCL. It would contains the three internal typedefs that all standard iterators need to have, and nothing else. And _Iterator_base (in all of its variants) and _Iterator_base_secure now should derive from _Iterator_base_universal to get these typedefs.

Now, when an iterator wants these typedefs, but not the data members of _Iterator_base and _Iterator_base_secure, it could derive from _Iterator_base_universal. And istreambuf_iterator and ostreambuf_iterator are now as small as possible, and keep identical representations or layout across HID/no-HID, SCL/no-SCL.

flagman 2010-12-19 11:09 发表评论

flagman — Sun, 19 Dec 2010 03:04:00 GMT

�?某某提到: �?br>: 一般说COM复杂�Q�首先是名词太多�Q�其�ơ是��Z��ATL的实现比较难�?br>: �q��ƈ不是COM本��n复杂�Q�而是C++已经落后于时代了。所以ATL看�v来才会像天书一�?/em>

虽然对于全新的工�E�项目，推荐通过.net实现�Q�但是，只要你工作在Windows�q�_��上，必然会遇到和COM相关的技术和机制�Q�无论是大量的legacy的工�E�和代码�Q�还是作为OS重要功能以及native�l��g的首选交互�Ş式和接口暴露方式�Q�比如DirectX API�Q�比如一些WMI的API�Q�最有趣的是�Q�即使是.net的核心CLR本��n也是一个COM�l��g�Q�可以通过Host相关接口让native应用来加载，以在当前�q�程中启动整个CLR的虚拟执行环境或者叫托管执行环境(managed executive environment)�?/p>
把握COM有两点很关键�Q?br>1�Q�Interface-based design�Q�从设计和编码思�\上就是要完全��Z��接口�Q?br>2�Q�VirtualTable-based binary compatibility, 实现上无��Z��U�语�a�或者机�Ӟ��只要�W�合��Z��虚表的二�q�制兼容规范�Q�就都可以实施；

COM仅仅是个规范�Q�基于COM的具体技术非�怹�多，OLE�Q�Automation�Q�Structural storage�Q�ActiveX...汗牛充栋�Q�还有COM+�Q�这个是提供企业�U�开发必备的一些基��功能和设施，比如�Q�事务管理机�Ӟ��对象池，安全��理�Q�消息队�?..需要指出，目前即便�?net Framework也没有实现COM+所提供�q�些机制�Q�只是简单的��装了后者�?/p>
COM技术中可能有一些比较困隄��地方�Q�接口的一致性，对象的聚合和生命周期�Q�套��_��跨套间的接口讉K��Q�名字对象，�{�等�Q�这些�ƈ不是COM规范��Zؓ刉��的困难�Q�而是��Z��设计和提供，可以跨进�E�和机器边界�Q�跨异构�q�_��Q�当然必��d��C��COM所规定的基��服务�Q�，透明化具体对象类型及对象生命周期�Q�便于统一部��v和版本管理的�l��g技术，所必须付出的代��P��q�个代�h从开发�h员角度看具体表现为，概念理解的困难以及具体二�q�制实现的困难；

不过从另一个角度看�Q�COM已经很容易了�Q?br>a) COM规范已把要达致这些目标的�pȝ��Q�所必须提供的接口和�Ҏ��抽象了出来�Q�只不过��Z��表达�q�些抽象的概念而新造的术语名词有些陌生和突兀�Q�如果让遇到�怼�问题的每一个设计和开发�h员都自己来做抽象�Q�未必会生成更好的方案；

b) ��Z��帮助设计和开发�h员，��Z��提供了很多的开发库�Q�以提高COM开发的正确性和效率�Q�最显著的就是MFC中关于COM/OLE的辅助类和函敎ͼ�以及��Z��COM而生的ATL�Q�从本质上看�Q�这些类库都是把COM规范中必��d��现的�Q�Windows�q�_��本��n没有提供�Q�具体设计和开发�h员实际实施时会重复实现的�Q�同时又非常�Ҏ��出错的那部分功能�Q�集中到了这些类库里�l�一实现�Q�让具体设计和开发�h员以代码重用的�Ş式来实现COM规范�Q?/p>
当然��Z��也意识到了COM�q�样的一些问题，特别是具体实现时设计和开发�h员必��要��x��几乎所有的二进制细节，于是.net��p��生了�Q�把�q�些规范的许多复杂性都��装在了虚拟机里面，把这些目标功能（跨边界、透明性等�{�）通过一致而又�q�x��的��^台接口和自描�q�的meta data�Q�以一�U�让设计和开发�h员更易接受的风格开放了出来�Q?/p>
COM的媄响是非常�q�大的，比如XPCOM �Q�Firefox上的一�U�插件技术标准，��是�Ҏ��COM的思想和原则制定的�Q�许多评��Q�Firefox的成功是因�ؓ它插件是如此的成功，�q�也��是COM本��n所意料不到的�A献之一�?/p>
�?net的��^��C��Q�即使是.net CLR/SSCLI的具体实��C��大量�q�用了COM的思想和机�Ӟ��可以�?net��是搭徏在COM二进制组件��^��C��上的虚拟机托��^台�?/p>
最后，.net开始时的内部编��h��COM 2.0

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

*) 关于“名词太多”
�q�是要实现可以跨�q�程和机器边界，跨异构��^収ͼ�当然必须实现了COM所规定的基��服务�Q�，透明化具体对象类型及对象生命周期�Q�便于统一部��v和版本管理的�l��g技术，所必须付出的代仗��?/p>
COM规范已把要达致这些目标的�pȝ��Q�所必须提供的接口和�Ҏ��抽象了出来�Q�只不过��Z��表达�q�些抽象的概念而新造的术语名词有些陌生和突兀�Q�如果让遇到�怼�问题的每一个设计和开发�h员都自己来做抽象�Q�未必会生成更好的方案；

举个例子�Q�apartment�Q�套��_��是��Z��抽象传统OS中进�E�和�U�程的实现而新造的术语名词和概念；��M��抽象�q�样的一些概念，不新造术语，是非常困隄��Q�对�?net�Q�后者用了CLR虚拟机来��装了大多数的实现细节，�q�用让�h更容易接受的风格来开放接口，可事实上仍然新造了一些名词和概念�Q�如�c�M��范畴的AppDomain�Q?/p>
*) 关于“��Z��ATL的实现比较难�?#8221;
ATL主要使用了template技术，COM接口��指针�Q�用静态�{换来模拟动态绑定，�{�等�Q�实际�ƈ不是很复杂，只能��c++实现机制的中�{�难度，主要涉及Modern C++ design一书中一些相兌��计理�늚��q�用。对比Boost中某些库的实玎ͼ�ATL很�h道了�?/p>
*) 关于“�q��ƈ不是COM本��n复杂�Q�而是C++已经落后于时代了”
首先COM的规范的��是复杂的，为啥�Q�第一点已�l�说了，��是��Z��要抽象出跨边界和对象透明的组件技术；.net表象上看比较“��单容�?#8221;�Q�风��g��q�设计和开发�h员，实际上复杂事务和实现�l�节都被划分到CLR那个层面上去实现了；�ȝ��一下CLR的开源实现SSCLI�Q�你会发玎ͼ�整个虚拟机��^台的实现�Q�大量运用了COM的思想和机�Ӟ��是一个巨型系�l��^台��的COM server�Q?/p>
其次�Q�COM规范本��n是独立于实现语言的，只要构徏出的�l��g�W�合规范制定的二�q�制兼容�Q�系�l�就可以�q�作�Q�这和C++是否落后时代没有关系。如果开发�h员认为，.net才够先进�Q�也完全可以�?net中的托管语言�Q�如C#来实现COM�l��g�Q?/p>
最后，每种语言都有光��用的范��_��现在可以�q�么�?#8220;如果有一个全新的��目需求，要达致跨边界和对象透明�l��g�Q��ƈ且没有太�q�严苛的性能需求，那么.net�q�_��及其上的托管语言来实玎ͼ�比用C++及相兌��助类库来以COM�l��g形式来实玎ͼ�要更合适，也更快速便捷和节省预算�?#8221;但是�Q�在�q�个判断上我们加了很多严格的�U�束�Q�一旦需求变��_��特别是项目的非功能性需求，要求高性能�q�算或者更��畅的与legacy的native�pȝ��怺��Q�那�?#8220;使用native语言来实现性能关键以及legacy交互功能�Q�通过COM��装�Q�再由COMInterop�?net托管应用调用”可能是更现实的方案。C++是一门活的语�a��Q�不断发展的语言�Q�即使在最新的托管时代里，C#成�ؓ标准��L��Q�但C++/CLI仍然是托��语�a�里功能最完整的语�a��?/p>

flagman 2010-12-19 11:04 发表评论

flagman — Mon, 13 Dec 2010 01:18:00 GMT

金山�p�d��软�g中的一部分代码open source了，自然地引��L��l�上以及IT业界的一片热评。其中关于已�l�开源的�q�部分外围代码的代码质量的问题，更是热中之热�Q�以下是关于�q�个问题个�h的一些思考：

从本质上说这里面��是个trade off�Q�也��是�q��和取舍的问题。��品项目的预算投入�Q�进度压力，各方面�h员的协调�Q�风格和习惯的统一�Q�等�{��?/p>
许多优秀开源项目，比如Boost�Q�其中很多作者本�w�都是学者兼开发或者是带有研究性质的开发�h员，在高校、非盈利�l�织或者商业企业的非直接盈利项目的资金支持下，在很��进度压力和商业压力的情况下�Q�精雕细琢，多次�q�代后，构徏出的�_�֓�代码。用�q�样的标准来要求所有的软�g产品�Q�特别是商业产品�Q�当焉��d��数关�p�重大和长远的基��核心部分外）的构建，是不�U�学的，也是不合��的�Q�因为及时占领市场和��_��的盈利，以及获得用户的赞许才是商业��Y件最重要的目标�?/p>
回头来看金山目前开源的�q�些产品�Q�比如这里讨论的金山卫士�Q�其从推出就是免费的�Q�是��Z��市场上的先期推出的同�c�d��兯��Y件及时比拼占领些许相兛_��Z��额，其�ƈ不是金山的基��和核心��品；从这些先天的条�g看，�q�个产品的商业投入不会很大同时又有快速推出的要求�Q�能有目前这��L��产品质量�Q�是合理的，从企业角度和用户角度看也都是可以接受的�?/p>
说到�q�里�Q�就感觉有必要涉及一�?#8220;重构”�Q�这个现在大安��很重视同时也�l�常谈及的话题。�ؓ何大安��很重视？而且常常谈及�Q�这其中当然有��Y件构建本�w�的特点�Q�比如对需求理解的不断深入和调整、设计的不断改善和演�q�、代码风格的�l�一以及�l�节的完善等�{�；但是�Q�有个大家在潜意识里都感觉到�Q��^时却很少谈及的缘�?-�q�度和成本，因�ؓ有了�q�些压力�Q��品的�W�一版往往不是很完��的�Q�然后如果还做后�l�版本的话，那么��p��引入重构�Q�因为有了这些压力，在经�q�多�q�之后，如果�q�个产品�q�存在的话，那么��p��q�行大规模的重构。简单的��_��重构之所以重要，不仅仅是软�g构徏本��n特点所引发�Q�也是商业压力之下的构徏�q�程的有效应对之道�?br>

flagman 2010-12-13 09:18 发表评论

flagman — Mon, 13 Dec 2010 01:02:00 GMT

Fusion is one of the most importants features among ones in the runtime implementation of CLI.

In the fusion, or any other components or modules, how to retrieve the execution engine instance and how to generate such engine?

UtilExecutionEngine, implemented as COM object, support Queryinterface/AddRef/Release, and exposed via interface IExecutionEngine.

With SELF_NO_HOST defined,
BYTE g_ExecutionEngineInstance[sizeof(UtilExecutionEngine)];
g_ExecutionEngineInstance would be the singleton instance of current execution engine,

otherwise, without SELF_NO_HOST, the 'sscoree' dll would be loaded and try to get the exported function, which is named 'IEE' from such dll. Here, it is the well-known shim, in .net CLR, such module is named 'mscoree'. Further, if 'IEE' could not be found in such dll, system would try to locate another exported function, named 'LoadLibraryShim', and use such function to load the 'mscorwks' module, and try to locate the 'IEE' exportd functionin it.

It's very obvious that Rotor has implemented its own execution engine, but it also gives or make space for implementation of execution engine from 3rd party. Here, .net CLR is a good candidate definitely, Rotor might load the mscorwks.dll module for its usage.

PAL, PALAPI, for example, HeapAlloc, one famous WIN32 API, has been implemented as one PALAPI (defined in Heap.c), to make it possible that the CLI/Rotor be ported smoothly to other OS, such freebsd/mac os.

CRT routines are also reimplemented, such as memcpy, it has been implemented as GCSafeMemCpy

There're many macros in fuctions, such as SCAN_IGNORE_FAULT/STATIC_CONTRACT_NOTHROW/STATIC_CONTRACT_NOTRIGGER, they are for static analysis tool to scan, analyse and figour out the potential issues in code.

From view point of the execution model by CLI, the act of compiling (including JIT) high-level type descriptions would be separated from the act of turning these type descriptions into processor-specific code and memory structures.

And such executino model, in other word, the well-known 'managed execution', would defer the loading, verification and compilation of components until runtime really needs; At the same time, the type-loading is the key trigger that causes CLI's tool chain to be engaged at runtime. Deferred compilation(lead to JIT)/linking/loading would get better portability to different target platform and be ready for version change; The whole deferred process would driven by well-defined metadata and policy, and it would be very robust for building a virtual execution environment;

At the top of such CLI tool chain, fusion is reponsible for not only finding and binding related assemblies, which are via assembly reference defined in assembly, fusion also takes another important role, loader, and its part of functionality is implemented in PEAssembly, ClassLoader classes. For example, ClassLoader::LoadTypeHandleForTypeKey.

For types in virtual execution environment of CLI, rotor defines four kinds of elements for internal conducting,
ELEMENT_TYPE_CLASS for ordinary classes and generic instantiations(including value types);
ELEMENT_TYPE_ARRAY AND ELEMENT_TYPE_SZARRAY for array types
ELEMENT_TYPE_PRT and ELEMENT_TYPE_BYREF for pointer types
ELEMENT_TYPE_FNPTR for function pointer types

every type would be assigned unique ulong-typed token, and such token would be used to look up in m_TypeDefToMethodTableMap (Linear mapping from TypeDef token to MethodTable *)which is maintained by current module; If there it is, the pointer to method table of such type would be retrieved, or it would look up in the loader module, where the method table should exist in while it's JIT loaded, not launched from NGEN image;

And all the unresolved typed would be maintained in a hash table, PendingTypeLoadTable; Types and only those types that are needed, such as dependencies, including parent types, are loaded in runtime, such type is fully loaded and ready for further execution, and other unresolved types would be kept in the previous hash table.

flagman 2010-12-13 09:02 发表评论

flagman — Mon, 13 Dec 2010 00:57:00 GMT

关于�E�序设计语言本��n的设计有许多有趣的话题，比如�Q��ؓ何C++中的�c�L��员函数没有采用类似Java中的“全虚”设计�Q?br>
1) 从语�a�本��n设计上看�Q?br>效率定然是c++当初设计时考虑的重点之一�Q��D个例子，��Z��节省不必要的VTable开销�Q�ATL用template技术静态�{换来模拟动态绑定以支持COM�Ҏ��的实现�Q�和C的兼容，��VTable角度看，问题不大�Q�因为后者可以用函数指针数组来模拟；

2) 再从大多数应用中常见的类�l�承体系上看�Q?br>除了整个�l�承体系所�l�一开攑և�来的接口集（也就是由虚函数所�l�成�Q�，在��承体�pȝ��每个层面另外会有大量的其他辅助成员函敎ͼ�其数量通常比虚函数多的多）�Q�这些成员函数完全没必要设计成虚函数�Q?/p>
3) 从其他语�a�看，
即��较新的虚拟机语言C#(Java��是较老的虚拟��a�),反而定义了比C++更�ؓ严格更�ؓ昑ּ�的成员方法实现或覆盖或重载或新徏的规则；�q�是非常重要的对C++以及Java设计思想的反思�?/p>
4) 从语�a�的适用场合看，
我们现在的讨论，�l�大多数情况下带有一个非帔R��要的默认前提�Q�那��是在用��h��模式下使用C++�Q�如果放宽这个约束，在内核模式下使用C++�Q�那情况又完全不同了�?br>引用下面�q�个文��的观点，http://www.microsoft.com/china/whdc/driver/kernel/KMcode.mspx
首先�Q�用��h��下非常廉�h几乎不用考虑的资源，在内�怸�是非常昂�늚��Q�比如内核堆栈一般就3个page�Q?/p>
在内�怸�能分��?paging)时必��M��证将被执行的所有代码和数据必须有效的驻留在物理内存中，如果�q�时需要多�ȝ��几张虚表以及虚表指针那还是显得非常昂�늚��Q�同时编译器��函数�Q�模板等生成代码的方式，让开发�h员很隄��定要执行一个函数所需要的所有代码的所在位�|�，因此也无法直接控制用于安�|�这些代码的节（个�h认�ؓ可能通过progma segment/datasegment/codesegment对于代码和数据进行集中控�Ӟ��Q�因此在需要这些代码时�Q�可能已�l�被page out了；

所有涉及类层次�l�构�Q�模板，异常�{�等�q�样的一些语�a��l�构在内核态中都可能是不安全的�Q�最好是把类的��用限定�ؓPOD�c�，回到我们的主题虚函数�Q�也��是说内核态下�c�设计中没有虚函数�?/p>

flagman 2010-12-13 08:57 发表评论