Scott Currie - How is Visual C++ (Whidbey) going to make my code more secure?

Play Scott Currie - How is Visual C++ (Whidbey) going to make my code more secure?
Sign in to queue


Developers are being asked to create more secure code. The next version of Visual C++, code-named Whidbey, will introduce several new security-protection capabilities. Here Scott Currie, Scott Currie, program manager of Visual C++ discusses the new security-focused changes.


C++, Security



Download this episode

The Discussion

  • User profile image
    Sven Groot
    Sounds interesting. You'll defenitely need to get those secure C APIs standardised though, everybody from Linux to MacOS could benefit from that kind of thing. Not that they'd trust it if it comes from Microsoft, but still...
    Also, real C++ programmers don't use C APIs anyway, I mean, who needs scanf and char* when you've got std::cin and std::string (both of which are safe btw)? Wink

    Also, it's not exactly clear to me what's so new about this stack buffer overrun protection... VS.NET 2003 does that too. Sure, I assume you've optimised it more, but is there anything really completely totally new added to it? That didn't become very clear from the video to me.
  • User profile image
    Hmm. Looks like this is a good idea for me to use. My programs use a lot of buffers. This will fix a lot of peoples code that would just crash because they didn't use malloc().

    Good idea.
  • User profile image
    Don't dis the C APIs entirely, I use printf and sprintf all the time (and indirectly via CString::Format). Creating formatted output with them is SO much easier compared to using the stream classes and manipulators and the horribly-named functions that I have to look up every single time.
  • User profile image
    Sven Groot
    Easier, perhaps. Less readable and more error-prone, definitely.

    It's probably a matter of taste, but I prefer the C++ way whenever there is one anyway.
  • User profile image
    It'll be cool if you could give us more samples.Thank you.
  • User profile image
    I'm just curious, have the STL functions that take 2 iterators (begin and end) for the input container and 1 for the optput been reworked too? So that they take also an iterator to the end of the output?

    I'm thinking of algorithms like copy or transform.

Add Your 2 Cents