tags:

views:

634

answers:

12

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)

+12  A: 

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.

unwind
You can not expect that people maintaining your code can follow the flow of multiple levels of indirection.
SoMoS
I'm maintaining your code, I'm a psychopath and I know where you live, don't use 3 levels of pointer indirection
Patrick
You can tell how good a C programmer is by the number of stars in front of his or her variables. That's where the term "four-star programmer" comes from.
Kevin Panko
+5  A: 

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.

Vinko Vrsalovic
@Vinko So you're saying that an ad-hoc data structure would justify the use of pointer math? :\ *scratches head*
leeand00
@leeand00: No, ad-hoc data structures potentially justify pointers to pointers (to pointers). I was trying to answer what are complicated ways: FROM "pointers to pointers" TO "really complicated and unsafe, like pointer math" (ad-hoc data structures may justify the former, but never the latter)
Vinko Vrsalovic
+7  A: 

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.

jon hanson
RAII (http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization) deserves a mention
Firas Assaad
I didn't mention it as it doesn't just apply to pointers.
jon hanson
This is what I think it means. Programming in an OO way, it's easier to keep track of pointer scope.
JimDaniel
@Firas Concerning RAII; Hmm, seeing as the guy that wrote C++ came up with the idea, I'm pretty sure this can't be wrong.
leeand00
+2  A: 

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...

drhirsch
did you mean an "uncomplicated way"...?
jon hanson
@jon Thanks Google ;)
leeand00
No, I meant it exactly like I wrote it ;-)
drhirsch
A: 

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.

Liz Albin
+1  A: 

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

Hassan Syed
A: 

Use pointers where you must, but nowhere else.

DevSolar
+8  A: 

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.

David Thornley
So the problem is really a C problem, not a C++ problem?
leeand00
(It's just that people think they are programming in C++ when they are really programming in C?)
leeand00
Lots of people do write C++ in the style of C with a few additions. (Compare the old saying, "You can write FORTRAN in any language.") I don't think treating C++ as C with classes and a few other things is the right approach.
David Thornley
And all this raw power of C++ goes away in the endless parade of wrappers on wrappers, copy constructors and reference counting...:-P Just don't get this too seriously, please. ;-)After years of working with C++ I simply came to realization that when C++ program gets big or complicated enough that I cannot manage my pointers, it's time to move to another language with real GC.And nice and clear C (not C++) extension and embedding API.(So Java is far away in the queue.)
Tomek Szpakowicz
+1  A: 

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)

William Pursell
+1  A: 

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.

jalf
A: 

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.

Paul Nathan
A: 

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.

Ben Voigt