This is the second of a series of articles examining a 2009 interview with Bjarne Stroustrup. The first part is here with links to the other parts:
In Masterminds of Programming, Stroustrup defends pointers: “What Java doesn’t have — and good for Java for that — is C and C++’s ability to misuse pointer arithmetic.” But he then says that you won’t have problems in well-written C++. But the potential for malicious use is there, and how much well-written C++ is there? Stroustrup actually confirms this point: “Unfortunately, there is also lot of poorly written and unnecessarily low-level C++ around.” That is again a burden on programmers to get it right for something that should not be there at all.
Stroustrup: “Essentially all arrays and most pointers belong deep in implementations that most programmers don’t have to see.” That is exactly the point I make about pointers — there is no need to expose them at all. Pointers can be completely abstracted beneath control structures like for each. That is pointers should not be deep in implementations (interpreted to mean in some library also written in C++), but they should be handled by the compiler — thus they belong buried in the compiler. Not all platforms support C-like pointers, they are inherently dangerous.
Stroustrup: “There is, however, an important place where pointers — and pointer manipulation — is a boon: the direct and efficient expression of data structures.” But as above this is not needed — use suitable foreach loops or iterators that abstract any need to expose pointers and direct and fraught with danger programmer manipulation. Sure programmers might feel that direct control is somehow more powerful, but that is part of the low-level attitude that needs to be dissuaded.
Stroustrup: “Java’s references are lacking here; for example you can’t express a swap operation in Java.” Well, when has a real program ever needed a swap operation? Swap really is an academic curiosity. If it were so essential, all languages would provide an inbuilt swap operator x :=: y or x < → y.
OK, that is an artificial academic justification. What about “Another example is simply the use of pointers for low-level direct access to (real) memory; for every system, some language has to do that, and often that language is C++.” Has he forgotten C? Any cases for direct access to memory are very rare, mostly for memory-mapped functionality in a system. However, that is non-semantic. What function should a memory location represent? What if the chip manufacturer decides to change the location in the future. What I propose is that instead of these primitive catch-all techniques based on memory locations, that a small semantic language is developed for each platform. The semantics of what the platform does is made clear in the language, not obfuscated by being memory mapped. C and C++ pointers are just lowest-common-denominator primitive ways to do things at that level.
Stroustrup: “The “dark side” of having pointers (and C-style arrays) is of course the potential for misuse: buffer overhangs, pointers into deleted memory, uninitialized pointers, etc. However, in well-written C++ that is not a major problem.” But by his own admission there is a lot of poorly-written C++. So it is a major problem. It is not just poorly-written code, but deliberate malicious code whether well- or poorly-written.
Stroustrup: “You simply don’t get those problems with pointers and arrays used within abstractions.” Well, to avoid those problems altogether the abstractions should be provided in the language itself, not left to libraries, which we can hope are well written. Again pointers are particular to certain platforms and should be handled in the compiler, not exposed in the language and dealt with deep in library implementations. That requires both understanding and discipline on the part of the programmer. This is really what I object to in C and C++, pushing responsibility out to the programmer for things programmers should not have to deal with since they are machine oriented and not abstract and problem oriented.
Not only are these technical points about pointers, but pointers are entirely the wrong way for programmers to think.
