Why is Visual C++ 2010 still calling Orphan_all when a vector is destroyed with _ITERATOR_DEBUG_LEVEL=0 ?
Hi ho, Visual C++ newbie here. (I came up to speed on Visual C++ 6 somewhat ages ago, and have used the IDE sporadically since then, but still don't feel comfortable with it. Give me a good old commandline and get off my lawn, that's my attitude.)
I'm helping out on an app built with Visual C++ 2010 (it's a solution file with 20 subprojects), and noticed something odd: even though _ITERATOR_DEBUG_LEVEL and _SECURE_SCL are both defined to zero in the project's properties, adding /FAs for one of the .cpp files still shows calls to checked iterator stuff, e.g.
call DWORD PTR __imp_?_Orphan_all@_Container_base0@std@@QAEXXZ
I've verified (with printf) that both defines are zero. Furthermore, these calls seem very fragile; if I delete seemingly trivial amounts of code from the function involved, the calls to Orphan_all vanish.
So: why is Visual C++ 2010 still calling Orphan_all when a vector is destroyed with _ITERATOR_DEBUG_LEVEL=0 ?
(Also, I've also heard that the cl.exe itself in windows sdk v7.1 and several games all seem to import _Orphan_all@_Container_base0@std@@QAEXXZ from msvcp100.dll, which seems odd for released products. What should msvcp100.dll's _Orphan_all@_Container_base0@std@@QAEXXZ do -- is it a no-op, or does it actually do things, like the one in msvcp100d.dll?)
[EDIT: asked at
http://stackoverflow.com/questions/...-destroyed-with and got excellent answers within minutes. That site is on fire! I now suspect that the optimizer just missed removing a few calls that it should have known would be no-ops.]
- Edited by Dan Kegel Friday, July 20, 2012 4:57 AM
Friday, July 20, 2012 4:10 AM
Reply
|
Quote
|
Dan Kegel
0 Points
Answers
0
Sign in to vote
I understand the issue clearly now. The example program
#include <stdio.h> #include <vector> using namespace std; int main() { vector<int> foo; vector<int> bar; vector<int> baz; foo.push_back(1); swap(foo, bar); baz = bar; printf("top of baz is %d\n", baz.back()); return 0; }
when compiled with /FAs shows various calls to _Orphan_all and _Swap_all... and compiling with /E shows that those functions are empty inline functions. As described in
http://channel9.msdn.com/Series/C9-...nced-STL-3-of-n
that's normal, and the optimizer usually inlines these calls (which, since they're empty, removes them). When you compile with /Od, or when the function in question is too big for the optimizer, the calls are not inlined, and the (empty) implementation in msvcp100.dll is called (and just returns).
So, in short, all is well, and those calls are not normally a performance problem.