Channel 9 video: STL Iterator Debugging and Secure SCL - Stephan T. Lavavej

Channel 9 video: STL Iterator Debugging and Secure SCL - Stephan T. Lavavej

  • Comments 9

Hello

Stephan has just completed his latest channel 9 video, this one on debugging in our implementation of the STL: http://channel9.msdn.com/shows/Going+Deep/STL-Iterator-Debugging-and-Secure-SCL/. This topic gets a little confusing as we have two technologies available here, namely Iterator Debugging and Iterator Checking – if you are occasionally confused by exactly what is the difference (and when should you use one or the other) then this video is for you.

You can also see Stephan’s Channel 9 video on TR1 here: http://channel9.msdn.com/shows/Going+Deep/Stephan-T-Lavavej-Digging-into-C-Technical-Report-1-TR1/

Thanks Damien

Visual C++

  • I don't know... why is it that a lot of buzz is about how to debug c++ code? I'd rather use tools, languages and techniques that reduced the introduction of bugs. Where's the buzz about TDD, comprehensive Refactoring, and simple semantics?

    I used to love C++ and used it daily for 7 years. After working solely with Python for a year and now working in Java I just don't miss it.

    If someone really wants to make money, write a great book on C++ Test Driven Development. You'll find you won't need to use a debugger as much. Michael Feathers comes closest with 'Working Effectively With Legacy Code'.

  • [Peter Wood]

    > why is it that a lot of buzz is about how to debug c++ code?

    > I'd rather use tools, languages and techniques that reduced the introduction of bugs.

    Modern C++, including the STL, already eliminates many bugs and drives other bugs upstream from runtime to compiletime. Iterator Debugging (aka _HAS_ITERATOR_DEBUGGING, aka HID) simply provides *even more* checking, in order to drive some of the remaining runtime bugs upstream from being hit by users to being hit by developers/testers.

    > Where's the buzz about TDD, comprehensive Refactoring, and simple semantics?

    TDD is a development process. "Comprehensive Refactoring" appears to be a process that is periodically applied to code. I don't know what "Simple Semantics" are.

    Processes are different from tools. Processes guide how you write, test, and modify code, by specifying what humans should do. Tools are real, physical machinery (well, as real and physical as software ever gets) that powers, tests, and operates on code. The STL is a tool that powers other code; HID automatically tests STL-using code at a low level; a debugger lets you see what your code is doing.

    Processes and tools are basically orthogonal (a process can tell you to use so-and-so tool, of course).

    > You'll find you won't need to use a debugger as much.

    That's not the point of this video and the HID feature (which is somewhat unfortunately named "Iterator Debugging"). HID doesn't make it easier to use a debugger on your code. Actually, it makes it somewhat harder, if you're looking at the raw representation. It's useful to contrast HID with the STL visualizers in VC8 and above. STL visualizers DO make it easier to use a debugger on your code, by hiding the representations of STL objects and processing them into human-readable form, but they DON'T detect any problems with your code. This is the opposite of what HID does.

    HID's purpose in life is to detect problems with your code. Even if you're already using modern C++ practices, you shouldn't turn down extra testing.

    I rarely use the debugger at home (when I do, it means that I've truly failed). But I run my tests in both ship and debug mode (with HID enabled), to increase my confidence in them.

    You generally won't see me talking about processes, which interest me much less than modern tools like the STL and Boost.

    Stephan T. Lavavej, Visual C++ Libraries Developer

  • [quote]why is it that a lot of buzz is about how to debug c++ code[/quote]

    Possible explanation: it's Visual C++ blog, not Python/TDD/Java blog.

    How do you expect to fix problems found in testing without the debugger anyway?

  • @pingpong

    > it's Visual C++ blog

    There is little buzz about C++ in the world outside Microsoft's blog.

    > How do you expect to fix problems found in testing without the debugger anyway?

    If I find a bug I write a test.

    I've just spent 20 minutes writing a reply and I realise I'm just being argumentative. So, I'm going to quit while I'm not ahead.

    I realise I've just dropped in on this particular blog entry and it could have been any. I'm sorry for trolling.

  • @ Peter Wood

    > There is little buzz about C++ in the world outside Microsoft's blog.

    Ahem... perhaps you should consider stepping out of the glass house you are in?

  • I must be a complete failure because I code with the debugger all the time, even when there are no bugs.  I like to use it to show me my data in memory.  I like to use it to cause conditional paths that are not supposed to happen in the code to see how the code degenerates.  I like using it to probe the vast universe of C++ code that has been executed before my line of code.  I have grown so accustomed to coding with it that it is just part of my process of writing code.  The author must have reached C++ enlightenment if he can truly code with out to the point where he feels he has failed as a coder.

  • I know this is off topic, but can anyone explain me why this code:

    template< class A, class B >

    class C : public A

    {

     friend class B;

    };

    fails to compile in Visual C++ 2008, error C2649: 'typename' : is not a 'class' ???

  • Jack: That code is incorrect, but VC9's error message is not especially enlightening. GCC 4.2.1's error message is better:

    error: using template type parameter 'B' after 'class'

    error: friend declaration does not name a class or function

    And Comeau 4.3.10.1's error message:

    error: template parameter "B" may not be used in an elaborated type specifier

         friend class B;

                      ^

    is excruciatingly beautiful as usual.

    The problem is that when you say "friend class X;", X must be a class-name, but B is only a type-name, not a class-name. If you say "but I said template <class A, class B>", remember that there is no semantic difference between that and "template <class A, typename B>". In either case, B might actually be int or double or whatever.

    Stephan T. Lavavej, Visual C++ Libraries Developer

  • The issue seems to be a legacy-compliance-induced hole in the C++ template spec.  Really "template <class A>" and "template <typename A>" should not mean the same thing, it just confuses the naive user.

Page 1 of 1 (9 items)