It may not always be true, but languages with stronger type safety normally also have a larger execution overhead. This is somewhat unavoidable since the extra checking to make sure the types match does take machine cycles. Of course the compiler can enforce a lot of these rules, so some of the performance hit could be at compile time, but it is still there.
In addition, you lose some flexibility. Its kind of like swimming with water wings (to continue my pool analogy). You are much less likely to drown, they limit what you can do at the same time. You are not likely to pick up too many things off the bottom of the pool with water wings on, unless you are really creative and strong. The flexibility in C/C++ remains there for a reason - it is helpful to at least some sorts of problems. It may or may not be the best for security, but it is a "cost" that should be considered as well as compile or run-time performance. Does this help? Brad Quoting AF <securecod...@nxtg.net>: > Brad Andrews wrote: >> [..] >> Perhaps we will get to a world where all the "management overhead" >> doesn't matter, but until then, the extra cost for type safety should >> be weighed against other factors, not just discounted out of hand. >> > Hi Brad, > Could you please explain what you mean by "the extra cost for type safety"? _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
