Crazy On Tap - Pointers are difficult to explain if you have no idea what a...

It's certainly possible to use pointers and understand the logical connections and even be able to do pointer arithmetic without understanding the underlying processor. But that's largely because processors now address, by and large, on even word boundaries and that the pointers are to objects rather than structs.

Now a C programmer will probably say an object in C++ space is just a struct with knobs on. And that's because it was exactly that when C++ was a macro preprocessor. These days though its a language construct of its own and has an internal level of abstraction which appears to protect the programmer from screwing up pointers associated with classes and members of classes.

So it would be reasonable to say that someone that doesn't understand the underlying processor architecture and uses pointer arithmetic is generally fairly lucky if they don't get a C00000005 or bombs or whatever a memory fault looks like to them.

I did write a long historical spiel about processors and why pointer management changed in complexity but then I thought that's pointless, give an example instead.

The original FAT table uses 12bit entries, each entry is a pointer to the beginning of that allocated space on the disk treating it as a contiguous area of memory (heads, cylinders and sectors being calculated afterwards). The process for reading the FAT to follow the chain of a files's allocated space involves treating the FAT itself as a block of memory and then shifting 4bits back and forth to get the actual entry. Once understood this method is straightforward and you can train your eye to follow allocations. But without a knowledge of the difference between bytes and words implementing a FAT reader will be more of trial and error than a solution based upon fundamentals.

Similarly, a DOS directory entry is an odd number of bytes and variables within also end on odd byte boundaries. If a programmer were not to know the difference between word length and a byte and how to define structures that did not align on words then they would never be able to successfully define a structure that they could use pointers to point at at all.

That programmers can get away with not understanding how the processor treats data and pointers to data is because of the seeming abstraction of the pointer. These days it isn't a pointer to a struct (or more usefully a pointer to an instance of a struct inside a tree of structs), but a pointer to an abstract class and after all the compiler/linker/runtime takes care of all of that.

This is both true and untrue at the same time.

The address of an object, class or struct is intrinsically no different to the address of anything else insofar as the processor is concerned. Pointers are unexploded bombs. In the hands of the skilled they can be used to perform magic, in the hands of the unskilled they will kill processes and lose data. If for no other reason than this I wouldn't have anyone writing C++ for me that did not know at a real and instinctive level what the processor (and all the abstracted levels above the processor) was doing with that pointer.

However, unless the language allowed for non-abstracted indirection not having that level of understanding wouldn't stop them from being productive and good developers. Even so, in 4GLs and the rest of it there are concepts of indirection that are just as important to understand.

Within Visual Foxpro, for instance, which is considered a 4GL, you can call by reference or by value, you can macroise to a very great extent and you can create interfaces to interop with C,C++ and Pascal calling units. Without understanding the word/byte problem and the high/low nybble problem a developer trying to access external routines (which can include the Fox runtime itself) will have only frustration and failure.