I read from somewhere that when using C++ it is recommended not to use pointers. Why is pointers such a bad idea when you are using C++. For C programmers that are used to using pointers, what is the better alternative and approach in C++?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
I think they mean you should use smart pointers instead of regular pointers.
In C++ the emphasis would be on garbage collection and preventing memory leaks (just to name two). Pointers are a fundamental part of the language, so not using them is pretty much impossible except in the most trival of programs.
Since I’m the one who published the polemic “don’t use f*cking pointers” I feel that I should comment here.
First of all, as a polemic it obviously represents an extreme viewpoint. There are definitely legitimate uses of (raw) pointers. But I (and many professional C++ programmers) maintain that these cases are exceedingly rare. But what we really mean is the following:
Here, “own memory” essentially means that at some point
The rationale for this is quite simple: raw pointers which own memory introduce a source of error. And these errors are prolific in existing software: memory leaks and double deletion – both a direct consequence of unclear resource ownership (but going in opposite direction).
This problem can be entirely eliminated, at virtually no cost, by simply using smart pointers instead of raw pointers (caveat: this still requires thinking, of course; shared pointers can lead to cycles and thus once again to memory leaks – but this is easily avoidable).
Unlike other languages, C++ has very strong support for value semantics and simply doesn’t need the indirection of pointers. This wasn’t immediately realised – historically, C++ was invented to facilitate easy object orientation in C, and relied heavily on constructing object graphs which were connected by pointers. But in modern C++, this paradigm is rarely the best choice, and modern C++ idioms often don’t need pointers at all. They operate on values rather than pointers.
Unfortunately, this message has still not caught on in large parts of the C++ user community. As a result, most of the C++ code that is written is still littered with superfluous pointers which make the code complex, slow and faulty / unreliable.
For somebody who knows modern C++, it’s clear that you very rarely need any pointers (either smart or raw; except when using them as iterators). The resulting code is shorter, less complex, more readable, often more efficient and more reliable.
Simply because there are abstractions available to your which hide the more temperamental aspects of using pointers, such as access to raw memory and cleaning up after your allocations. With smart pointers, container classes, and design patterns like RAII, the need for using raw pointers is diminished. That said, like any abstraction, you should understand how they actually work before moving beyond them.
One of reasons is too wide application of pointers. They can be used for iteration over containers, for avoiding copying large objects when passing to function, non-trivial life-time management, accessing to random places in memory, etc. And once you used them for one purpose, other their features become available immediately independently on intent.
Selection of a tool for exact purpose makes code simpler and intent more visible - iterators for iterations, smart pointers for life-time management, etc.
Relatively simply, the C mentality is "Got a problem? Use a pointer". You can see this in C strings, function pointers, pointers-as-iterators, pointer-to-pointer, void pointer- even in the early days of C++ with member pointers.
But in C++ you can use values for many or all of these tasks. Need a function abstraction?
If you were a soldier you would have, say, an assault rifle and a knife.
It is easier and safer to kill people with the assault rifle than it is with the knife so people will tell you to use that when you can.
However, sometimes you have to use the knife. If you are careful you can sneak up, kill your target and sneak away again safely but the potential for things going wrong is much higher.
So use the rifle when you can and use the knife when you have to.
The same is true of references (rifle) and pointers (the knife).
Disclaimer: This analogy is presented as is with no warranties of any kind. It is not guaranteed to by logically proof against absurdities nor can is necessarily be sensibly extended to cover anything other than the author's original intent.
Besides the reasons already listed, there is an obvious one: better optimisations. Aliasing analysis is far too complicated in presense of a pointer arithmetics, whereas references hints an optimiser, so a much deeper aliasing analysis is possible if only references are used.
Beside the risk of memory leaks stated by @jmquigley pointer and pointer arithmetic can be considered problematic because pointers can point everywhere in memory causing "hard to find bugs" and "security vulnerableties".
That is why they were nearly abandoned in C# and Java.
C++ supports most of C, features, plus Objects and Classes. C already had pointers and other stuff.
Pointers are a very useful technique, that can be combined with Object Orientation, and C++ supports them. But, this technique, is difficult to teach and difficult to understand, and, its very easy to cause unwanted errors.
Many new programming languages pretend not to use pointers with objects, like Java, .NET, Delphi, Vala, PHP, Scala. But, pointers are still used, "behind the scenes". These "hidden pointer" techniques are called "references".
Anyway, I consider pointer (s) as a Programming Pattern, as a valid way to solve certain problems, as well as Object Oriented Programming does.
Other developers may have a different opinion. But, I suggest students and programmers learn how to:
(1) Use pointers without objects
(2) objects without pointers
(3) explicit pointers to objects
(4) "hidden" pointers to objects ( A.K.A. reference) ;-)
In that order.
Even if is difficult to teach, and difficult to learn. Object Pascal (Delphi, FreePascal, others) and
And, later, novice programmers, can move to "hidden pointers to objects" programming languages like: Java, C#, Object Oriented PHP, and others.
Talking about VC6, when you cast a pointer of a class (that you instantiate) into a variable (e.g. DWORD), even if this pointer is local you can access the class over all the functions that use the same heap. The instantiated class is defined as local but in fact it is not. As far as I know, any address of a heap variable, structure or class is unique along all the life of the hosting class.
EDIT Thats a very little part of the original code. The CSRecodset class is only a casting class of CXdbRecordset, where all the real code is. Doing so I can let the user take benefit of what I wrote without loosing my rights. I do not pretend to demonstrate that my database engine is professional but it really works.
EDIT: requested by DeadMG:
protected by gnat Jan 7 '15 at 12:26
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?