3 ms·
True, but most of these issues can be mitigated by using best practices - use vectors instead of raw arrays, avoid shared ownership (and use shared pointers whe
by 10098 13y ago
True, but most of these issues can be mitigated by using best practices - use vectors instead of raw arrays, avoid shared ownership (and use shared pointers when you can't), etc. Of course, these don't make the language safe, but they do help alleviate the problem a great deal.
I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages. I mean, we already can detect some problems using static code checking tools (i.e. PVS-studio), so it must be feasible.
- pcwalton 13y ago> I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages. Rust does this. :) It is not easy to get right—the borrow checker required a lot of design work to achieve the right balance between expressiveness and practicality—but I think we've shown that it is possible. (Disclaimer: I work on Rust.)
- pjmlp 13y agoLike most languages in the Pascal family. Arrays are bounded. You can usually disable bounds checking locally if you really need the extra ms, for cases the compiler is not able to optimize them. Proper strings instead of char pointers that might be null terminated or not. Var parameters and unbounded vector parameters to handle arguments that need to be changed. Oberon family has already proven it is possible to write desktop operating systems in GC enabled systems programming languages. Now as you say, many of these things are possible in modern C++. The problem is getting everyone on board, specially when dealing with old code bases littered with C like constructs.