ansaurus

Question

Does operator precedence in C++ differ for pointers and iterators?

Answer 1

+2 A:

*it++ = tolower(*it); 
*p++ = tolower(*p);

Both of these lines invoke undefined behaviour. You cannot modify the value of a variable more than once in a single statement (++ modifies once, operator = modifies twice).

So the fact that you get different values is unsurprising.

Dean Harding 2010-05-28 06:37:58

`operator++` and `operator=` applied here to two different variables in each case. There's no UB.

Kirill V. Lyadvinsky 2010-05-28 06:41:35

@Kirill V. Lyadvinsky: There is undefined behaviour for both the pointer and iterator case as there is a possible sequencing of the operations were there is no intervening sequence point between the read of the value of `it` (or `p`) for the `*` operator on the RHS of the assignment and the increment operation on the LHS of the assignment.

Charles Bailey 2010-05-28 06:45:22

Whatever the case, the lines are certainly confusing and I wouldn't want to see it written like that anyway :-)

Dean Harding 2010-05-28 06:47:25

@Charles Bailey, changing the same variable twice in between two sequence points is UB. Here is only one change. I think the problem is that the order of compute arguments of the function `operator=` is unspecified.

Kirill V. Lyadvinsky 2010-05-28 06:49:37

@Kirill V. Lyadvinsky: Reading (except to determine the value to be written) and writing the same variable without an intervening sequence point also causes UB.

Charles Bailey 2010-05-28 06:59:31

@Kirill V. Lyadvinsky: For clarity, I am, of course, talking about the write to `it` implied by the `++` not the write implied by the assignment which isn't directly to `it`.

Charles Bailey 2010-05-28 07:17:48

For the `char*` case, we have undefined behavior due to `*` being applied twice in combination with `++`; for the `std::string::iterator` case, we might merely have *unspecified* evaluation order of those same operators. If the iterator type is a user-defined type and not merely an alias for `char*`, then the overloaded operators are functions and thus there are more sequence points. But even though it's defined, it still might not yield the desired results.

Rob Kennedy 2010-05-28 07:24:54

@Rob Kennedy: Even in the iterator case where there are more sequence points, there are valid orderings of sub-exressions where `it++` and `*it` are not separated by a sequence point and 5 / para 8 says that this means that you have UB.

Charles Bailey 2010-05-28 07:28:56

Answer 2

+2 A:

The grammar works exactly the same for pointers and iterators. The operations implied by operators are turned into function calls for objects of class type (such as most iterators).

The issue with your code isn't with operator precedence though, in both of these lines there is no sequencing between the increment operation and the second read of the same variable that is incremented elsewhere in the statement. Because of this, you have undefined behaviour so he might see any behaviour from your program including the results that you are seeing.

*p++ = tolower(*p);

*it++ = tolower(*it);

You need to reformulate this statement in a way in which the sequencing is defined. I'm guessing that you want something like this.

char c = tolower(*p);
*p++ = c;

Charles Bailey 2010-05-28 06:40:10

+1: your addon works, but i've vague undestanding why

oraz 2010-05-28 07:04:43

Rationale for downvote, anyone?

Charles Bailey 2010-05-28 07:14:50

+1 for good suggestion. May be it's wrong suggestion in the end, but it's helpful. Consider to add links to the Standard.

Kirill V. Lyadvinsky 2010-05-28 07:17:59

@oraz: In C++ there fewer restrictions than some languages in how an implementation breaks down an evaluates the sub-expressions of any given expressions. If the result of the expression depends on the order in which the sub-expressions are performed then it is often the case that you have not guarantees on what will actually happen. The solution (for the programmer) is to break down complex expressions into smaller expression which exactly express your intent.

Charles Bailey 2010-05-28 07:26:47

Answer 3

+8 A:

The problem is that the order of evaluation of arguments of operator= is unspecified. This is according to C++ Standard 5.2.2/8. Consider the following:

*it++ = tolower(*it);

is equal to

operator=( *it++, tolower(*it) );

Now *it++ could be computed before tolower(*it) and vice versa.

Kirill V. Lyadvinsky 2010-05-28 06:57:13

It's worse than unspecified behavior, there is undefined behavior in the original expression. There is a possible ordering of subexpressions where `it++` is evaluated (i.e. a write to `it`) before `it` is read in the parameter evaluation for `tolower` with no intervening sequence point. This can happen whether or not the assignment operator is a function call or not. Either way 5 [expr], para 8 confirms that this is undefined behaviour.

Charles Bailey 2010-05-28 07:20:32

ansaurus

tags:

views:

answers:

Does operator precedence in C++ differ for pointers and iterators?

related questions