C Pointers have been ignored by some for as long as the language has existed. I read this sentence over 15 years ago and I guess people still want to ignore a great tool. The reality is that pointers are essential for any programmer. At my embedded systems consulting company we still see customers that pass huge variables, often blowing up the stack and we have to explain pointers and how they should avoid passing such large elements.
AS the post by CEO points, function pointers can be a bit tricky, but oftentimes using them to create a dynamic handler can make branching to different handlers very extensible, and I think that is something very desirable.
Avoiding pointers is like a mechanic not using power tools. Sure, you can hurt yourself, but if you learn to leverage them you can do the job quicker and cleaner.
There are some subtleties about pointers, but it still seems like a pretty narrow topic. The entire C language was described in what is actually a reasonably compact book, after all. I would at least hope that it also covers smart pointers as defined in the latest c++ standards. Restricting the book to common C usage means that it is of use to a much smaller audience.
Hi Jack -- I'm not a programmer -- I just dabble -- but recently I've found myself having to use pointers and sometimes I find it hard to wrap my brain around -- I think I need to get a copy of this book.
I concur, while I've probably written more software in my career then others who consider them selves hardware engineers (hudreds of thousands of lines of code in either C/C++/mainsail/perl/tcl/python) and while pointers are conceptally very easy to understand. When you bounce around between interpretted and compiled languages all the time I tend to forget about the "nuances" between how pointers our implemented in one language versus how to referance a variable location in another.
So, I for one think a dedicated book on the subject (albeit w.r.t. just C/C++) should have come years ago :-).
In case you find my 'dread' as baffling as I yours, let me outline my reasons. C was created (~1972) and adopted by people who were currently writing in assembly language. They saw the Index Register as an essential element of programming and, understandably, enshrined it in their new language as the Pointer. This was the Tricky Age of programming where cool tricks were greatly admired, and the pointer is one of the coolest, because you can do amazing tricks with it and produce startling effects, though not necessarily the ones you intended. 40+ years later people are still doing this.
IMO the greatest advance in pointer technology was its removal. This is accomplished neatly in Java. Because of this, and the fact that all array references are checked, it is impossible to access any memory not explicitly named in your program. Further, there are Java systems that can calculate absolute upper limits on the execution time of code, which allows one to know if scheduling deadlines can be met. In addition, there are garbage collectors whose execution time is known and which can operate concurrently with user code. These features have allowed the definition of a "Safety Critical Java." One of the best known and most highly developed of these is Martin Schoeberl's JOP (Java Optimized Processor). It has the novel feature that the "operating system" (which reduces to a scheduler) is itself written in Java. No memory management unit is needed. There is also a multiprocessor version.
I'm not knowledgeable about the existence of a Safety Critical C, but a quick search turns up many suggestions for making C safer (but not Safe). I can only hope that some pointer blunder won't send my pacer into Lala land.
I can understand your reasoning regarding trust of Java over C, but keep in mind that that level of abstraction has its price. Years ago I ported a Java VM to a new RTOS, and the variable handling code was a nightmare. Making things simple can be a very complex process, and an application written in Java is at the mercy of the underlying VM code. The difference in who is dreading what depends on the level of trust in that code.