I think he's highlighting that security is a genuine concern (which is good), but he seems to be misinformed about how C++ is actually supported on.NET. If the situation were what the article seems to indicate, I'd be concerned too.
Fortunately, it's not. Maybe I can provide some more context about my design so that he can see how this is a choice that makes the world more, not less, secure.
You can and should write perfectly verifiable code in C++ targeting.NET, perfectly safe code where you're not allowed to use those dangerous casts, etc. It's called
/clr:safe
and it's encouraged. And writing verifiable C++ code means a lot more than just writing C# code in C++ syntax (though you can do just that if you like) -- you also get to use templates and automatic destructors and other major C++ power features safely and verifiably.
For example, consider one of those other C++ power features: STL. Of course, the plain native STL isn't bounds-checked or verifiable. But we also provide a complete STL/CLR library (previously also called STL.NET) which is fully verifiable. STL/CLR is a library that brings all of C++'s familiar containers, iterators, and algorithms straight to the managed world with full interoperability with the CLI container interfaces. This is what you can do (only) in a language that supports both templates and generics: Have a template, like stdcli::vector, that implements a generic interface, like IList. You can use it as a vector (it is one); code that uses a std::vector today can work seamlessly with a stdcli::vector. You can use it as an IList (it is that, too); C# and VB (and C++) code can happily foreach on it.
And I think I already mentioned this is all completely safe and verifiable.
STL/CLR is an example of how C++ on.NET really brings together the best of both worlds, with no compromises: C++ code gets its usual full STL style of programming and full template specialization and everything else that makes the Standard C++ language and library so powerful. And you can still take one of those container objects and pass it directly to a C# or VB app that can use it naturally. It's safe.
Sure, you can also explicitly disable safe mode and write/call unsafe code too if you want -- in any language. That's not specific to C++; you can do that with C# unsafe and Java JNI. If it's immoral to call into unsafe code when you need to, why does C# have unsafe, and why does Java have JNI?
One thing this discussion does underscore, though, is the design choice difference between the JVM's "one language" and the CLR's "many languages." There's a lot of C++ code out there. Which is better for security -- to ignore that code and tell people to throw it all away because tossing it is good for them, or to give C++ developers an easier migration to take their existing valuable code and make it also be safe and verifiable?
For those interested in some more details, I've written about a number of these issues on my blog.
Right, and this sea change has other interesting consequences too. See also my recent blog at http://pluralsight.com/blogs/hsutter/archive/2004/ 12/17/3957.aspx about The Concurrency Revolution. It's an overview of an article I just wrote on exactly this topic that will appear in the March issue of Dr. Dobb's Journal. A shorter version will be in the February C/C++ Users Journal.
>It's the.net runtime framework i'm in morbid fear of.
That's fine, but just note that you're probably already running it -- as of Windows XP SP1, the.NET runtime installs as part of the OS. And it will continue to do so in future versions of Windows, in particular in Longhorn when it won't just ship with the OS but it will be the at the heart of it, the OS's primary API.
>if it's not on your machine, then you don't have to worry about.net applications running;
FWIW, it's not always easy to tell when an app you want to run happens to be a.NET app (just as it's not always easy to tell what compiler an app was built with or what class libs it uses, etc.). For example, I have been using NewsGator (plugs into Outlook) to pull in RSS feeds into my email, and I didn't realize until recently that NewsGator is a.NET app -- I was running a system monitoring tool and watching another process when I happened to notice that NewsGator was being jitted and gc'd.
Slashdot Mirror
Fortunately, it's not. Maybe I can provide some more context about my design so that he can see how this is a choice that makes the world more, not less, secure.
You can and should write perfectly verifiable code in C++ targeting .NET, perfectly safe code where you're not allowed to use those dangerous casts, etc. It's called
and it's encouraged. And writing verifiable C++ code means a lot more than just writing C# code in C++ syntax (though you can do just that if you like) -- you also get to use templates and automatic destructors and other major C++ power features safely and verifiably.For example, consider one of those other C++ power features: STL. Of course, the plain native STL isn't bounds-checked or verifiable. But we also provide a complete STL/CLR library (previously also called STL.NET) which is fully verifiable. STL/CLR is a library that brings all of C++'s familiar containers, iterators, and algorithms straight to the managed world with full interoperability with the CLI container interfaces. This is what you can do (only) in a language that supports both templates and generics: Have a template, like stdcli::vector, that implements a generic interface, like IList. You can use it as a vector (it is one); code that uses a std::vector today can work seamlessly with a stdcli::vector. You can use it as an IList (it is that, too); C# and VB (and C++) code can happily foreach on it.
And I think I already mentioned this is all completely safe and verifiable.
STL/CLR is an example of how C++ on .NET really brings together the best of both worlds, with no compromises: C++ code gets its usual full STL style of programming and full template specialization and everything else that makes the Standard C++ language and library so powerful. And you can still take one of those container objects and pass it directly to a C# or VB app that can use it naturally. It's safe.
Sure, you can also explicitly disable safe mode and write/call unsafe code too if you want -- in any language. That's not specific to C++; you can do that with C# unsafe and Java JNI. If it's immoral to call into unsafe code when you need to, why does C# have unsafe, and why does Java have JNI?
One thing this discussion does underscore, though, is the design choice difference between the JVM's "one language" and the CLR's "many languages." There's a lot of C++ code out there. Which is better for security -- to ignore that code and tell people to throw it all away because tossing it is good for them, or to give C++ developers an easier migration to take their existing valuable code and make it also be safe and verifiable?
For those interested in some more details, I've written about a number of these issues on my blog.
Cheers,
Herb
Right, and this sea change has other interesting consequences too. See also my recent blog at http://pluralsight.com/blogs/hsutter/archive/2004/ 12/17/3957.aspx about The Concurrency Revolution. It's an overview of an article I just wrote on exactly this topic that will appear in the March issue of Dr. Dobb's Journal. A shorter version will be in the February C/C++ Users Journal.
That's fine, but just note that you're probably already running it -- as of Windows XP SP1, the .NET runtime installs as part of the OS. And it will continue to do so in future versions of Windows, in particular in Longhorn when it won't just ship with the OS but it will be the at the heart of it, the OS's primary API.
>if it's not on your machine, then you don't have to worry about .net applications running;
FWIW, it's not always easy to tell when an app you want to run happens to be a .NET app (just as it's not always easy to tell what compiler an app was built with or what class libs it uses, etc.). For example, I have been using NewsGator (plugs into Outlook) to pull in RSS feeds into my email, and I didn't realize until recently that NewsGator is a .NET app -- I was running a system monitoring tool and watching another process when I happened to notice that NewsGator was being jitted and gc'd.
Herb