Re: Deprecate the use of plain pointers as standard container iterators
First of all my examples may not be the best ones to show the problems
I'm writing about, but this doesn't mean that the problems aren't
there, so focusing too much on the details of my code is really missing
the issue I was trying to point out.
kuyper@wizard.net wrote:
Nicola Musatti wrote:
[...]
void f() {
std::vector<int> v;
//...
std::sort(++v.begin(), v.end());
}
If std::vector<>::iterator is a pointer the expression ++v.begin() is
invalid because it attempts to modify an rvalue.
Which opens the question: why does it try to modify an rvalue? Why not
use v.begin()+1 instead? As written, this code pointlessly specifies an
additional operation that doesn't need to be performed, which is
harmless when that operation can be performed, but fails when it can't
be. I don't think this example provides strong support for your
argument. It does provide support for the idea that your code should
never specify any actions beyond those that actually need to be taken,
even if those extra actions seem harmless.
Change the std::vector above with std::list and your objection still
applies yet your suggestion doesn't anymore. The code above attempts to
modify an rvalue because it is reasonable to do so in order to write
clearer, more generic code. Compilers have all the information
available to produce efficient code.
Moreover your own comment is a strong indication that I'm right:
incrementing an iterator rvalue is OK when it is a class instance, but
not when it is a scalar temporary? This is the kind of pitfall that
makes C++ needlessly hard to learn and use.
I might agree to the notion that it was a mistake to allow calling non
const member functions on rvalues, but that's too late to change now,
isn't it?
The following code gives different results on different platforms:
int * find(int * b, int * e, int d) {
return b + d < e ? b + d : e;
}
//...
std::vector<int>::iterator i = find(v.begin(), v.end(), 2);
std::cout << ( i != v.end() ? *i : 0 ) << '\n';
If std::vector<>::iterator is a pointer the user defined find function
is chosen.
"Doctor, it hurts when I hit myself in the head with a hammer."
"Then stop hitting yourself in the head with a hammer."
This implies that I know it is a hammer. Unfortunately the C++ standard
doesn't tell me.
Use std::find(), if you want to make sure that it's actually
std::find() that you're calling. If you actually want the compiler to
consider other possible overloads, make sure that any other overload
that could be selected has acceptable semantics, and doesn't lead to
ambiguity as to which overload should be selected. This is the same
advice that applies whenever calling any function; there's nothing
special about the fact that v.begin() might (or might not) be a
pointer.
But the problem is exactly the fact that semantics are not sufficiently
specified! And what is bad for any function, is pure evil for a
standard library function. This is again a needless pitfall.
Cheers,
Nicola Musatti
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]