What madness that is, I don’t think vb developers are mission out on much from not having increment and decrement operators, other than the migraines every now an then 🙂
My biggest problem with these oh-so-wonderful operators is the undefined order of side-effects.
About four years ago, I was working as a test lead on a game, and we were trying to upgrade from Visual C++ 4.2 to Visual C++ 6.0 so we could use the newest DirectX libraries to help us out with a bug. The project was over 320KLOC, and large portions had been written by developers that were no longer around.
Once the project had been upgraded, we did a build and began testing, and found that the entire graphics engine was no longer working correctly. After tracing into the code, we found wonderful gems similar to this:
m_i++ = o->f(++m_i, ++m_i);
In VC4.2, that would compile out one way. In VC6, it would compile another way. We ended up staying in VC4.2 so that we could actually ship.
What madness that is, I don’t think vb developers are mission out on much from not having increment and decrement operators, other than the migraines every now an then 🙂
Pingback: Richard Clark
My biggest problem with these oh-so-wonderful operators is the undefined order of side-effects.
About four years ago, I was working as a test lead on a game, and we were trying to upgrade from Visual C++ 4.2 to Visual C++ 6.0 so we could use the newest DirectX libraries to help us out with a bug. The project was over 320KLOC, and large portions had been written by developers that were no longer around.
Once the project had been upgraded, we did a build and began testing, and found that the entire graphics engine was no longer working correctly. After tracing into the code, we found wonderful gems similar to this:
m_i++ = o->f(++m_i, ++m_i);
In VC4.2, that would compile out one way. In VC6, it would compile another way. We ended up staying in VC4.2 so that we could actually ship.
http://www.zen13120.zen.co.uk/Blog/2004/09/blog-link-of-week-36.html