A bunch of cunts, mostly in the Australian sense. Except that one guy.

Pointers are difficult to explain if you have no idea what a...

...processor is or does...

Quoted from here:


but Ive seen it said a few times during the various conversations on this topic in the main forum.

I *really* dont get that, I have *no idea* how the processor works...it still feels like magic to me (all these electrons get together and obey my written instructions to display and calculate stuff)...but I got pointers very early on...and would have done so quicker if I wasn't a little confused by the syntax, and learning c, and how to use a computer, and whatnot.

There is likely something Im missing still cause I dont get the belief that an understanding of the processor is necessary to understand pointers.
Anyone feel like explaining it to me?
Permalink Jesus H Christ 
January 2nd, 2006
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.
Permalink Simon Lucy 
January 2nd, 2006

This topic was orginally posted to the off-topic forum of the
Joel on Software discussion board.

Other topics: January, 2006 Other topics: January, 2006 Recent topics Recent topics