raid san's List: C++

• SEH是属于操作系统的特性，不为特定语言设计，但是实际上，作为操作系统的特性，几乎就等同与面向C语言设计
• 《Windows核心编程》是Windows编程领域必看的第二本书，第一本是《Programming Windows》
• RaiseException(0, 0, 0, NULL);
• 因为C语言没有智能指针，那么就不能缺少finally的异常语法
• finally仅仅是一条保证finally语句执行的块，并不是异常处理的handle语句（与except不同），所以，假如光是有finally语句块的话，实际效果就是异常会继续向上抛出。（异常处理过程也还是继续）
• SEH奇怪的语法在于finally与except无法同时使用，不然会报编译错误
• 难道因为SEH设计过于老了？-_-!因为在现在的语言中finally都是允许与except（或类似的块，比如catch）同时使用的
• 一个很大的优点就是其对异常进程的完全控制，这一点是C++异常所没有的，因为其遵循的是所谓的终止设定
• EXCEPTION_CONTINUE_EXECUTION (–1)   表示在异常发生的地方继续执行，表示处理过后，程序可以继续执行下去。 C++中没有此语义
• 本就不知道C++中类/对象的概念，所以，实际上不能识别并且正确的与C++类/对象共存
• 简而言之就是将实际类/对象的使用全部放进函数中，利用函数对对象生命周期的控制，来避开SEH的不足

9 more annotations...

• 微软的测试者版本，支持的是托管代码，本地代码必须支持CLR，所以那个哥们将编译器的CLR选项打开，但是重新建立单元测试文件的时候，系统识别不出文件中的类和方法。根据强人的解释，本地C++代码在CLR Metadata里面是用类似结构的东西来表示的，开发环境无法识别这样的元素，如果要识别这些元素，需要以托管代码（Managed）C++的书写方式编写程序
• 要使用测试者版本测试C++本地非托管代码的具体设置方法，比较繁琐，而且还只能测试静态库（static library）。反正说白了，就是C++本地非托管代码基本没法用测试者版本里内建的单元测试功能来进行驱动开发测试，即使想测，也要费相当大的周章。看来，VC下面的本地非托管C++开发，要想搞测试驱动，还是乖乖的用CPPUnit为上策

• 这是因为CppUnit会用到VS IDE来定位和显示错误的Test Case的源文件和代码行, 而导入的IDE Com对象的Version不正确,只需要把Project TestPlugInRunner 文件MsDevCallerListCtrl.cpp 67行
  
  #import "libid:80cc9f66-e7d8-4ddd-85b6-d9e6cd0e93e2" version("7.0") lcid("0") raw_interfaces_only named_guids
  
  改为:
  
  
  1. #if _MSC_VER >= 1300 && _MSC_VER < 1400
  2. //vs 2003
  3. #import "libid:80cc9f66-e7d8-4ddd-85b6-d9e6cd0e93e2" version("7.0") lcid("0") raw_interfaces_only named_guids
  4. #elif _MSC_VER >= 1400 && _MSC_VER < 1500
  5. //vs 2005
  6. #import "libid:80cc9f66-e7d8-4ddd-85b6-d9e6cd0e93e2" version("8.0") lcid("0") raw_interfaces_only named_guids
  7. #elif _MSC_VER >= 1500
  8. //vs 2008   
  9. #import "libid:80cc9f66-e7d8-4ddd-85b6-d9e6cd0e93e2" version("9.0") lcid("0") raw_interfaces_only named_guids
  10. #endif
  重新Build该Project即可。
• VC7Handler

• 对于N=1的情况，称为binary semaphore
• 有的系统上，主要的差异是mutex一定要由获得锁的进程来释放。而semaphore可以由其它进程释放
• spin lock与semaphore的主要区别是spin lock是busy waiting，而semaphore是sleep

1 more annotation...

• MFC and STL one always has to be carefull of #include placements. It can happen when you place includes for header files that use STL after MFC's macros that override operator 'new'
  
  For example, suppose you have a class CMyClass that uses STL and it has corresponding myclass.h file. Suppose also you have a MFC file (somemfc.cpp) that uses CMyClass. You need to make sure you put #include "myclass.h" BEFORE #define new DEBUG_NEW statements! For example code below will compile OK:
  
   

  #include "myclass.h"
  
  #ifdef _DEBUG
  #define new DEBUG_NEW
  #undef THIS_FILE
  static char THIS_FILE[] = __FILE__;
  #endif

• 当内存不够分配的时候抛出bad_alloc异常
• 放入N个T类型的数据的容器到底需要多大共享内存？因为容器本身是有消耗，而这点BOOST并没有接口告诉我