4 ms·
Rust, C#, and Swift have all the unsafe features as well. The difference is you don't really need to touch them. C++ hasn't even added a safe .at() method to s
by sirwhinesalot 3y ago
Rust, C#, and Swift have all the unsafe features as well. The difference is you don't really need to touch them.
C++ hasn't even added a safe .at() method to std::span yet, all you have is the [] operator which is unsafe despite the damn object carrying the length around.
It's an attitude problem, C and C++ devs just don't give a shit. Their languages are unsafe because they want them that way.
- Rochus 3y agoMy question was, why on earth they consider Object Pascal memory safe. In contrast to the other languages mentioned in the report it doesn't even have automatic memory management. You can call dispose on a pointer while other pointers are still pointing to the object, as you can do in C++. Unsafe operations are neither specially treated by the syntax (in contrast to the unsafe sections in the languages you mentioned). C++ has even a lot more possibilities to write safe code than Object Pascal.
- sirwhinesalot 3y agoProper bounds checks vs C++'s "do everything wrong by default" is a big deal! Other than that, Object Pascal and C++ are about the same safety wise so I agree it should not be considered a "memory safe" language. Though personally I don't think "memory safe" vs "memory unsafe" is the right distinction since you can write 100% memory safe code in memory unsafe languages (and I don't mean making 0 bugs, I mean writing code using only safe APIs). The real problem to me is one of attitude. If people cared enough you'd have proper memory safe subsets of C and C++ in use today. That's one area where Object Pascal has an advantage, getting "fancy" with pointers just isn't part of the culture. I wrote about it here: https://btmc.substack.com/p/memory-unsafety-is-an-attitude-problem https://btmc.substack.com/p/memory-unsafety-is-an-attitude-p...
- Rochus 3y ago> Proper bounds checks vs C++'s "do everything wrong by default" is a big deal! I don't remember how it is in Delphi, but in FreePascal, the bounds-checks are usually turned off: "By default, the compiler doesn’t generate code to check the ranges of array indices, enumeration types, subrange types, etc." (https://www.freepascal.org/docs-html/prog/progsu65.html https://www.freepascal.org/docs-html/prog/progsu65.html). > Object Pascal and C++ are about the same safety wise Because in C++ constructors and destructors are guaranteed by standard and compiler, even in case of an exception and with value type, it's easier to make the code safe. Also the wide-ranging operator overloading and template features support safe coding style. Object Pascal only has a fraction of this. So C++ offerst both ways, careless low-level pointer fiddling and adding and assuring safety nets for every data structure and method.
- sirwhinesalot 3y agoI personally always turned them on. Unlike with C arrays for example (which lose track of their length) Pascal keeps it around so the cost of a bounds-check is exactly what one would expect. Perhaps I'm wrong regarding the culture of Pascal users though, only speaking for myself as someone who mostly coded in Delphi for fun. Most C++ implementations provide an option to turn on bounds checks for operator [] in various container types but this actually against the standard, and std::span doesn't even have .at() standardized yet despite the implementation amounting to an if and a call to operator []. So safety in C++ is very hit and miss. All the necessary tools are there but the standard is lousy as all heck. Like I argue in my blog, it's an attitude problem. Don't use raw pointers/pointer arithmetic. Only use bounds checked operations even if you're 100% sure you got the bounds right (if it's that obvious the compiler will remove the check too). Don't store references anywhere, they should be ephemeral. Use std::unique_ptr and std::shared_ptr as appropriate, they are your friends. Don't use unsafe casts/untagged unions. etc. It's not hard to have a linter check most of this. It's a matter of doing it.