A
Angel Tsankov
Should pre/post increment/decrement return const or non-const?
What about other functions?
What about other functions?
Angel said:Should pre/post increment/decrement return const or non-const?
What about other functions?
Ian Collins said:Non-const, otherwise the expression can't be an lvalue.
Ian said:Non-const, otherwise the expression can't be an lvalue.
Angel said:Should pre/post increment/decrement return const or non-const?
What about other functions?
You're right, I probably wouldn't, but ++iter could be if you wanted toKai-Uwe Bux said:Ian Collins wrote:
Why would you want, e.g., iter++ to be an lvalue? Also, the standard
specified the following requirements for iterators:
Ian said:You're right, I probably wouldn't, but ++iter could be if you wanted to
assign something to the result,
*(++i) = x;
where i is some type with const and non-const operator*().
Then again, if iter were some form of smart pointer, one might want to
write
*(i++) = x;
because it's valid for normal pointers. Make sense, or am I lacking
caffeine?
is somewhat expected, based on the behaviour of the built-in types,
'other functions' are certaintly not. And even then, if you are
the one who designs and implements pre- and post-increments for
your UDTs, you're free to make them do what you please. For all
we care, they can all return 'void'. Do as your model dictates.
There is no good enough general rule.
Good point, I was a little short on caffeine.Kai-Uwe Bux said:int & operator* ( void ) const {
return ( *ptr );
}
}; // iter_dummy
int main ( void ) {
iter_dummy iter ( 4 );
*(iter++) = 5;
}
Note how operator*() is const as it does not change the iterator but only
the pointee. Thus, you can have iter++ return a const reference, yet
*(iter++) be and lvalue.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.