Thomas Hruska wrote: > > I'm probably the most guilty party here. My view is that pointers are > an _advanced topic_. It doesn't mean you shouldn't learn how to use > them nor use them at all. >
I'm moreso referring to this question by Paul Herring, "Why are you using pointers in C++?" That seems to imply that we should not use pointers in C++. I agree with you that pointers should not be taught right away, and most formal curricula do not teach it right away (in fact, you'll probably go at least half a semester before reaching them). > They have their place. HOWEVER! Pointers > are almost always taught too early in the process of learning C/C++. > Most people are still learning the basic constructs of the language when > pointers are taught. To have to learn the basic constructs (for loops, > if-then-else, etc.) AND simultaneously learn an advanced topic such as > pointers is too much for most people. > In a formal curriculum, C++ is not the first language you take. Generally you start with "Computer Logic" (which is an introduction to a language like Java, VB.net, etc.), followed by C/pascal, then C++. So generally, all they need to do is carry over the same logic but adapt to the C syntax (which is really just memorization, the logic is the same). They won't be "learning" basic code structures, but rather learning the C++ syntax and how to adapt their logic to it. But if you are talking about simple tutorials to learn C++, then I agree. > In addition, C++ makes it entirely possible to write complete programs > without using a single _obvious_ pointer anywhere in the application > layer (i.e. anything requiring an _explicit_ dereference to access > data). I consider passing-by-reference to still not really tread on > pointer territory since you are guaranteed that an object is always > passed at _compile-time_ (i.e. the compiler makes sure the object will > be passed). > Of course, but that in no way means you shouldn't use a pointer. That goes down to a pointer vs. reference debate, both of which have their pros and cons. > > Personally, I abuse temporary objects that allow me to avoid pointers > within the main application layer. C++ makes it easy, the performance > loss is _generally_ minimal and within acceptable tolerance, the code is > MUCH more readable, AND I'm practically guaranteed to have a program > free of crash bugs and memory leaks. The moment I start using pointers > within the application layer is the moment I know I'm probably throwing > the application's stability and maintainability out the window (usually > in favor of performance but I very much prefer the first two). > First of all, that is entirely a case-by-case issue. If your programs suddenly becomes unstable due to *you* using pointers, then you need to study pointers a little more. I know what you are saying, and it happens to the best of us, but it *should not* happen with careful planning and error-checking. No reason to throw out an extremely powerful feature of C++ simply because the person using it isn't using it properly. > BTW, the application layer sits on the library layer. Any "C++ API" > (usually a third-party library) will go in a layer I call the > third-party layer, which is _below_ the library layer (I don't like > third-party code). It will get wrapped up inside functionality in the > library layer I write one time with an interface I want to use so I > never have to deal with it again and the code will be solidly written in > case of future use of that code. Then the application layer uses the > library layer accordingly. Again, no obvious pointers at the > application layer. > You are re-inventing the wheel by wrapping a library that wraps something else. If you are going to write a library around another library, why not just write the library yourself? Now don't take that question at face value - I know there are wrappers around the Windows API and whatnot (but for entirely different purposes, however). It seems like you go out of your way to avoid pointers when they need not be avoided with proper use and proper error-checking. > > As a result, I can read files, access databases, connect to remote > websites and retrieve data, etc. without using a single direct/obvious > pointer at the application layer in C++. This is why I say pointers are > NOT necessary to create entire, powerful applications: Because I've > done it before. Now those applications might not always perform > spectacularly (temporary object abuse), but they get the job done. > Just create a typedef if you are afraid of pointers, the Windows API does it quite often. > > > C++ makes it possible to defer teaching pointers until MUCH later on. > I agree. So here is my conclusion: you should *not* avoid pointers in C++. If they consistently cause your program to develop memory leaks and crashes, then you need to go back and re-learn how pointers work. I agree that pointers should not be taught too early when learning C++ (and they usually aren't in a formal curriculum). [Non-text portions of this message have been removed]
