About raw pointers — no you can’t do same as in C++. There’s no malloc/free, and placement new is still unstable. Also they feel foreign to the language, and sometimes I can’t even get them from the standard collections (like when I need 2 mutable pointers to different elements).
About the safety, it’s important to understand there’s a price. In some cases, it causes simple things hard to implement, or cost performance.
For example, there’re algorithms out there that modify items of the same collection at the same time, both single threaded like sorting, and parallel.
Can such algorithm cause a data race? Yes.
Is it good the compiler tells me about that? Sure.
Is it good the compiler prevents me from doing that at all, and forces me to code some workarounds, that will cost me time to implement, will be ugly, and/or will sacrifice runtime performance? Not sure, I like having a choice.
There is no problem using raw pointers for non owning pointers. Also a lot of safe abstractions can be built on top of raw pointers (and smart pointers are obviously an example).
Yes, it's safe to cast a reference to a raw pointer and a raw pointer to an address.
It might have been nicer in some ways if the language had restricted that a bit more up front, but it would probably have taken some design work to do that while still supporting a lot of the low-level stuff people need to do.
Not sure, I used them quite extensively in various projects and tried avoiding raw pointers. The only concern can be some cost of overhead when using them.
The UB is a lot more manageable if you pass nostrict-aliasing and similar to the compiler, or if you use a compiler that doesn't do that style of trickery.
The includes and raw pointers are a build your own abstraction thing. Annoying if the abstraction you're building is the one a different language gives you to work with. For example, a struct with multiple arrays of the same length - in C that's multiple pointers and one size, in other languages that's probably multiple sizes and asserts that they haven't diverged.
It's not a perfect language but it's really rather good.
And how do you want to write it? With 'safer' JVM based languages? Rust? Go?
C++ has the best memory model out there. Why do they want to extract raw C pointers from smart ones? This seems like a bad practice if you need to do that.
Safety. Without pointer arithmetic it's possible to create a language that can never derive an illegal address that succeeds incorrectly. Compiler and hardware technology have advanced to the point where a loop using array indices can be as efficient as a loop using pointer arithmetic. Also, the lack of pointer arithmetic can simplify the implementation of the garbage collector.
I feel like raw pointers and indices are about the same. Indices can be runtime bounds-checked, with a violation resulting in a crash. Raw pointers—if they're single heap allocations—are also runtime validity-checked, in the sense that violations will (probabilistically) result in a General Protection Fault, given a large address space and ASLR.
References (i.e. pointers the compiler knows about), on the other hand, are strictly better than either. Indices can only be bounds-checked at runtime, while references can be both alias-checked and bounds-checked (if they're references into a slice of memory that is known to the compiler) at compile-time.
But, of course, you can't do math to references. Construct a pointer by through an integer cast + math, and now the compiler has no idea what that thing is, what it's inside of, or how many other pointers point to the same place it does.
in my experience, it's almost inevitable that you end up calling some code you don't control that returns raw pointers. better hope you have access to the source or at least some good docs :)
My impression was that its facilities for type- and memory-safe pointer usage were fairly sophisticated and unlike anything in more popular languages, which is what I was going off of. I must admit I haven't written any ATS, just done a cursory skim of the documentation and watched a Strange Loop talk a few years back.
This example looks like it should be turned into a malloc variant, i.e. needs only to be written once. Raw pointer access is also available in other languages of course, albeit it is usually made much more difficult.
It's not particularly terrifying - it's just an array of pointers, and it's well known how it's implemented for the main compilers. As I've pointed out elsewhere I don't think it's necessary though, and it definitely creates a dependency on the compiler that may or may not be acceptable.
About the safety, it’s important to understand there’s a price. In some cases, it causes simple things hard to implement, or cost performance.
For example, there’re algorithms out there that modify items of the same collection at the same time, both single threaded like sorting, and parallel.
Can such algorithm cause a data race? Yes.
Is it good the compiler tells me about that? Sure.
Is it good the compiler prevents me from doing that at all, and forces me to code some workarounds, that will cost me time to implement, will be ugly, and/or will sacrifice runtime performance? Not sure, I like having a choice.
reply