Which is one of the reasons why in the modern world (of fast CPUs and large RAM) code should be edited using editors that "understand" the language's syntax.
What makes it unclear is exactly this 'pointery stuff'. There's nothing inherently unsafe about strongly typed pointers, but that's not the same as direct memory modification (which is obviously unsafe).
Strongly typed pointers is just another name for direct memory access.
The following is perfectly typesafe:
SuperClass[] items = GetArrayOfSubClass();
Now if we try to do unsafe things to items, we may end up accidentally accessing memory we shouldn't.
unsafe
{
for (int i=0; i < items.Length; i++)
{
var currentItem = &items[i*sizeof(SuperClass)];
}
}
This may or may not work, based on the runtime memory-layout of the subclass.
Basically the presence of unsafe {} means that beyond this point correctness cannot be guaranteed by the compiler. That's in fact what the keyword is for.
And that's the marker you are looking for. No need to go digging deeper into the code looking for the actual pointers themselves.
Lots of languages (like C#) allow pointers, but only inside blocks explicitly declared to be unsafe.
I think that is equally clear, if not even more. And again: I don't think this is any more polluting than weird out of place PEEK/POKE statements.
That is true, my point was that for C and C++ that is not clear at all.
You cannot simply search for & and * regarding point operations because those are also valid numeric operators, thus with context dependent meaning.
Being able to search for PEEK/POKE, SYSTEM.PUT/SYSTEM.GET, or just unsafe blocks makes all the difference tracking down unsafe code.
Also note that unsafe code blocks is older than C almost for 10 years, as ESPOL/NEWP already had such feature in 1961.
> You cannot simply search
Which is one of the reasons why in the modern world (of fast CPUs and large RAM) code should be edited using editors that "understand" the language's syntax.
What makes it unclear is exactly this 'pointery stuff'. There's nothing inherently unsafe about strongly typed pointers, but that's not the same as direct memory modification (which is obviously unsafe).
Strongly typed pointers is just another name for direct memory access.
The following is perfectly typesafe:
Now if we try to do unsafe things to items, we may end up accidentally accessing memory we shouldn't.
This may or may not work, based on the runtime memory-layout of the subclass.
Basically the presence of unsafe {} means that beyond this point correctness cannot be guaranteed by the compiler. That's in fact what the keyword is for.
And that's the marker you are looking for. No need to go digging deeper into the code looking for the actual pointers themselves.