ansaurus

Question

Syntax for dereferencing a pointer in C (or C++)

Answer 1

+6 A:

I'll take door #2, Monty! Sure its more difficult to type, but its more clear than finding out which operators dereference which pointer.

Daniel A. White 2009-04-28 15:47:41

FYI - Monty = Monty Hall of "Let's Make a Deal" fame

Daniel A. White 2009-04-28 15:51:49

I'm hoping this is a joke.

Matthew Flaschen 2009-04-29 02:38:28

Answer 2

+9 A:

In C++ I would definitely use ->, because -> can be overloaded.

In C I would use -> as well because it's much easier to read, faster to type and less error prone (hope your colleague doesn't get lost in parenthesis!).

Edouard A. 2009-04-28 15:49:03

I think overloading is a red herring here. An iterator will work with p->a or (*p).a. Use -> because it's far easier to read and far less error-prone. Remember that *(p.a) and (*p).a are two different things, so you have to remember to use (*p).a, but p->a is nice and simple.

David Thornley 2009-04-28 16:30:54

In theory operator*() and operator->() could be overloaded to do wildly different things... hopefully not, though.

ephemient 2009-04-28 17:40:56

-> is often overloaded for smart pointers

Edouard A. 2009-04-29 08:14:15

which often overload operator*() as well.

ephemient 2009-04-29 14:59:24

Answer 3

+1 A:

subjective huh ?

I'll take #2 as well!

toto 2009-04-28 15:49:13

Answer 4

+20 A:

The technical term for syntax # 1 is "nuts."

That said, I'd worry a little about code that has to go indirect 3 times too.

Charlie Martin 2009-04-28 15:50:02

heheh...indirection was due to a domain model represented in C.

paquetp 2009-04-29 02:16:36

Think about using a temp pointer if you're needing to do this more than ones: thingie_s * tp; ... tp = p_member->p_member->p_member; then go indirect once through tp.

Charlie Martin 2009-04-29 16:34:12

Oh yeah, sure, of course ... especially if your doing it more than once.

paquetp 2009-04-30 00:52:40

Answer 5

+1 A:

The second variant obviously looks clearer. The only reason to prefer #1 is the case of some weird operator * and operator -> overloading when #1 has really different effect than #2.

sharptooth 2009-04-28 15:50:11

and if the operators have been overloaded such that they have "really different" effects, the author of that code needs to be dragged out back and shot.

rmeador 2009-04-28 16:12:56

overloading these operators will be banned in the coding standards of any project I work in.

Daniel Daranas 2009-04-29 09:13:57

Answer 6

A:

No 2.

Having said that, don't offend people by changing their code, especially if it is a matter of style. It's just not worth it.

Nemanja Trifunovic 2009-04-28 15:56:04

If I have to figure out what a single line of code says, rather than read it and keep moving, that's a quality problem. I'd change it in a heartbeat.

David Thornley 2009-04-28 16:26:46

So how are you able to work with other people who have different opinions what is readable and what not? I work with 40 other (and smart!) developers and pretty much everybody has their idea how the code should be formatted and what is readable. If we were stepping on each others like that, working together would be a hell and we would have never accomplished anything.

Nemanja Trifunovic 2009-04-28 16:46:05

I would think coding standards would have to be agreed upon. Having a code base with a million different coding styles is a nightmare all its own.

jdizzle 2009-04-28 17:32:01

+1. I'm with Nemanja: Sure it's ugly, and if you're taking over the code from this guy and making sweeping changes, by all means tidy this up, but otherwise don't bother. If you can't handle 3 levels of nested parens, *you* have a problem.

j_random_hacker 2009-04-28 18:41:59

But 3 pointless levels of nested parens? I would take offense.

ephemient 2009-04-28 22:54:26

I agree Nemanja - I would hate it if someone reworked my code, but I think this particular instance merited it, only because I had to eventually modify it. If I didn't have to touch it, I wouldn't have modified it.

paquetp 2009-04-29 02:26:09

Answer 7

+5 A:

You may also wish to discuss the notion of "code ownership" in your team. You colleague does not "own" the code, the company does. Hence anyone employed by the company, with good reason, can edit it.

Colin Desmond 2009-04-28 16:01:07

The question here is not who legally owns the code, but who needs to maintain and debug a particular part of the codebase. If it is the coworker, I say the code should look the way he likes, even if most of us prefer the other way.

Nemanja Trifunovic 2009-04-28 16:49:36

If anyone reading this wants the rest of the story - he started the code, I had to "integrate" it (add it to source control, put it in the proper process, have that process call his function)...it didn't work, so I had to finish it.

paquetp 2009-04-29 02:20:44

In my book, if it didn't work, he doesn't get to complain about you changing it. Of course, given that he prefers the (*p). construct over ->, I'm not shocked that it didn't work.

Michael Kohne 2009-07-21 02:29:10

Answer 8

+14 A:

I think your coworker is either inexperienced, some sort of neophobe, or just plain ol' clueless. You're going to find that the unanimous choice is to use the -> syntax.

jeffamaphone 2009-04-28 16:01:30

That's what I expect...

paquetp 2009-04-28 16:50:36

Answer 9

+8 A:

I'm typing off the cuff here, but my recollection is that the logic for the very existence of the -> operator in C was explained in the 1st edition of K&R as (paraphrasing): because otherwise you'd have to type (*p).a due to the necessary precedence of the * and . operators.

To not use -> for its intended purpose is nuts.

RBerteig 2009-04-28 18:17:45

Answer 10

+1 A:

Bad colleague. Change colleague.

2009-04-29 09:03:03

Answer 11

A:

I've had experiances where "->" wasn't properly implemented in a couple of compilers... so the normal (*p).a was more likely to work when you have mutliple levels of nesting.

Ape-inago 2009-07-21 02:24:09

ansaurus

tags:

views:

answers:

Syntax for dereferencing a pointer in C (or C++)

related questions