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

最新推荐文章于 2024-03-25 10:17:38 发布

原创最新推荐文章于 2024-03-25 10:17:38 发布 · 1k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#微软 #vb #编译器 #优化 #c

VBS 同时被 3 个专栏收录

11 篇文章

订阅专栏

MFC

5 篇文章

订阅专栏

IE控制

2 篇文章

订阅专栏

本文探讨了在C++中使用VariantCopy和AutoWrap时遇到的问题，特别是关于对象赋值过程中level变量的递增操作导致的意料之外的行为。通过分析，揭示了后置递增操作符在实际应用中的不确定性及其对程序逻辑的影响。

    // 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一直错啊一直错。