微软也会错，后置++很危险！

    // Line 11: set screen = doc . parentwindow . screen 
    level=0;//因为是代码片段，我特意加了初始化，以防歧义原来发生代码中没有的
    VariantCopy(&root[++level], &doc);//拷贝doc内容到root[++level]
    AutoWrap(DISPATCH_PROPERTYGET|DISPATCH_METHOD, &root[level+1], root[level++].pdispVal, L"parentwindow", 0);//可以看成root[level++].parentwindow对象赋值给root[level+1]
   //下面的可以不看
    AutoWrap(DISPATCH_PROPERTYGET|DISPATCH_METHOD, &rVal, root[level].pdispVal, L"screen", 0);
    VariantClear(&root[level--]);
    VariantClear(&root[level--]);
    VariantCopy(&screen, &rVal);
    VariantClear(&rVal);

上面的代码来自微软的VB to VC automation Code Converte

大家是不是认为
1、VariantCopy(&root[++level], &doc)是doc对象赋值给root[1]
2、root[1].parentwindow对象赋值给root[2]
其实，我也是这样想的，但是经过跟踪发现root[1].parentwindow对象赋值给了root[3]。

环境：VS2008+Win7

结果是：在第一个AutoWrap中，传给root[1].parentwindow对象赋值给root[3]，

事实，我们忽略的一点，根据C++ primer，后置++只是通过返回一个++之前的原值，带来延时++的效果，通过优先级再有差异也是在也是在

[level++]这个括号之中完成的，那么root[level+1], root[level++].pdispVal中的level到底在上面时候++的，level+1之前，还是之后？这个过程，必然在AutoWrap传入压栈参数之前完成，到底谁先谁后？，不知道!在http://blog.youkuaiyun.com/blankman/article/details/149206作者给我指明了方向：没有明确顺序！所以，root[level+1]中的level是多少，完全看编译器和优化的过程了。

微软的VB to VC automation Code Converte估计自己也忽略了。当下面的代码第二个AutoWrap继续引用root[level].pdispVal是自以为是在操作第一个AutoWrap中的root[level+1]取回的对象，实际上，确实在操作一个完全悬空的对象root[2],而第一个AutoWrap取回的对象其实放在了root[3]中。结果就是第二个AutoWrap一直错啊一直错。