What does this statement mean? "good C++ programming typically doesn't use pointers in complicated ways."

In this other question in the winning answer I read:开发者_开发问答

... good C++ programming typically doesn't use pointers in complicated ways.

What does it mean to not use pointers in complicated ways?

(I'm really hoping that this isn't a subjective question)

Of course it's subjective. Some people seem to consider almost all pointers "complicated", while some easily move among three (or more) levels of indirection while doing lots of arithmetic, never getting confused.

As the guy who wrote that, I can at least tell you what I meant.

In a good C++ program, of the sorts I'm familiar with, pointers are used to indicate objects, mostly so they can be passed around and used polymorphically. They aren't used to pass by reference, because that's what references are for. There is NO pointer arithmetic. There aren't many raw pointers. Pointers aren't usually used to build up data structures, since most of the data structures you're going to want a lot are built into the standard library or maybe Boost.

In other words, modern C++ typically uses pointers in the same way Java does, except that Java doesn't use the word because it has no concept of something other than a primitive datatype that's accessible except by pointer (at least not when I last used Java). The translation is from something like Foo bar = new Foo(); (syntax not guaranteed) to smart_ptr<Foo> bar = new Foo; and from bar.snarf() to bar->snarf(). At least to get started, a Java programmer doesn't need to pick up the concept like he or she would if he or she were moving to C.

I suspect it simply means to not have raw pointers all over the place. Pointers should generally be held within a class that owns the pointer and is responsible for deleting the pointed-to object (e.g. std::auto_ptr). Doing so generally makes your code simpler.

My understanding of that answer is that "modern" C++ doesn't need much use of pointers because most data structures you'd use already come built in either Boost or the standard library.

So "complicated ways" of using pointers would be from having pointers to pointers and structure traversal using pointers to really complicated and potentially unsafe ways of using pointers, such as pointer math or worse.

I personally think that it depends on what code are you writing. There is a lot of code that needs you to write ad-hoc data structures, so I would take that sentence with a pinch of salt.

This statement doesn't make any sense, since it isn't possible to use pointers in C++ in a complicated way.

#define NONCOMPLICATED *

...Ducks and runs away...

if the pointers in question

1) are used only as references to heap allocated memory chunks.

2) The pointer in question exists in only one location.

2.1) if on stack they use a out-of-scope deleting smart-pointer (or are deleted manually at end of scope).

2.2) if they belong to a class the correct compiler generated member functions are defined.

Than I would say they are being used in a sensible and non-complicated way :D

Pointers are not the issue. The statement is a version of the more general statement that a program should do nothing complicated. The essence of designing a program is removing complexity.

"Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.” (Alan Perlis)

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." (Albert Einstein)

Beginning C++ programmers, or people coming from Java or C# tend to use pointers everywhere.

You need an object of type Foo? Foo* f = new Foo();. Class Bar contains a member object? Make that a pointer to a dynamically allocated object.

And that is not the right way to go. The Foo object can be allocated on the stack. There's no need to use dynamic allocation, and there's no need to use a pointer. Bar can store the member object directly, rather than a pointer to it.

In good C++ code, pointers should be rare. Not because eliminating pointers in itself makes your code better, but because heavy use of pointers is a sign that the person who wrote the code pretends the language is Java or C#.

Other examples are reliance on arrays and pointers where std::vector would've solved the problem. Or using pointers to implement pass by reference, when actual references could have been used.

Well yes, of course it's subjective - one person's "complicated" is another's "so simple I can do it when asleep". For a slightly different slant, how about thinking of using pointers at all, and why one would do so. You can also think about the maintainability of the code. The question from which you got the quote mentions hiring recent grads - if an organization is in the habit of hiring people who don't have experience with pointers, then yes, in that organization good c++ code won't have extensive use of pointers.

Use pointers where you must, but nowhere else.

It means that the use of pointers is of course, obvious to the reader. What exactly that implements out to depends on the given system.

For many people, they do not have the requisite experience and expertise to solve complex problems in memory-level development(debuggers, kernels, drivers, etc). That domain requires pointer understanding - or, rather, understanding of what's going on that makes a pointer solution the most obvious.

Most problems do not require memory-level solutions; hence the use of Java, Haskell, C#, and other unpointer languages.

I would beg to differ with the original claim. The issue isn't complication, it is encapsulation vs coupling. Good C++ programs encapsulate pointers inside classes which have the sole purpose of managing the pointer(s), maintaining the invariants, and preventing use of pointers that have become invalid (e.g. by iteration off the end of an array). There might be a lot of heavy pointer math going on inside the class in order to provide linked lists, hash tables, compare-and-swap, software transactional memory with ACID semantics, etc., but all users are protected against such implementation details. And the pointer math isn't complicated by program logic, those things are done elsewhere.