I Hate C++: Dots and Arrows...

C++ was a huge disappointment. Touted as a next-generation C language, it should have had all the power of a modern, object-oriented language, but with fewer of the painful and annoying aspects of C. It was the big chance to take the lessons of what was right and wrong about C -- generally a pretty good language -- and apply them to language designed from the ground up to be a standard.

An opportunity that was entirely squandered.

I have a long list of these things -- little things that affect every C programmer every day that could have been fixed in C++. I don't want to list them all because that would be boring, but I want to give a couple of examples. As part 1 of my series, I give you the difference between 'dot' and 'arrow'. It leaves a bad taste in my mouth every single time it trips me up.

There is only one interesting thing you can do with pointers in C: you can dereference them. They can be treated as quasi-numbers for certain purposes, but when the rubber meets the road you have to follow the pointer and find the object that it refers to. This is done like this:

x = *x_ptr;

Structures, on the other hand, are mainly containers for things, so what you do is access their fields. This is done like this:

x = s.x_field;

It turns out that real-world code almost always deals with pointers to structures, and most of the time when you want to act on a pointer to a structure you want to access the fields of the structure. Using the notation of pointers and structures, this would be done like this:

x = (*s_ptr).x_field;

Even the original creators of the C language realized that this is ugly in the extreme. So they added some syntactic sugar to their compiler to hide this idiom. Instead of a combination of asterisk and dot, C programmers write this:

x = s_ptr->x_field;

This arrow operator only works on pointers to structures, and the dot operator only works on structures. The compiler will complain if you confuse the two -- telling you very specifically that you are using the wrong set of punctuation marks. I consider this one of the most annoying design flubs in the original C language. The two forms are logically identical; there's no reason why they shouldn't be interchangeable. I should be able to write:

x = s_ptr.x_field;

There's no possible ambiguity since the dot operator cannot apply to a pointer. If it's a pointer to a structure the compiler should be able to dereference it automatically before accessing the field. Using a different operator was sheer laziness on the part of the original C-compiler authors.

Is this fixed in C++? It was a golden opportunity, but no. C++ compilers still smugly point out that you're using the wrong operator but don't lift a finger to help. C++ will make implicit casts left and right, calling hidden methods behind your back at a moment's notice, but it will not treat a dereference like a cast -- converting automatically from a pointer to the thing itself as needed. That's just lame.

- jack*

UPDATE: part 2

Comments

[Luca]

I couldn't disagree more. A structure has fields to access, a pointer doesn't. You cannot use the same operator symbol for two completely different operations. That would be confusing and misleading at best.

Plus, the arrow is pretty explanatory (it points somewhere) and does not require much more typing than a dot. Moreover, if a reader looks at a fragment of your code can immediately recognize which variables are pointers and which are not, just looking at how you use them.

[Too]

I could not agree more with the article (better late than never). Luca wrote "You cannot use the same operator symbol for two completely different operations". I beg to disagree - yes you can use the same symbol for two different operations. In fact probably every symbol in C++ has more than 1 meaning depending on context or more overloads based on the type.

Language should be simple to use and if out of 4 possibilities (pointer->field, pointer.field, struct->field, struct.field) 2 produce error, one operator is enough to encode the information.

If hungarian notation + ide highlighting is not enough for somebody to determine on what kind of variable the field is accessed, only OS accessibility features can help.