Re: Deprecate the use of plain pointers as standard container iterators
johnchx2@yahoo.com () wrote (abridged):
It also means we have defined an open-ended family
of functions rather than the exactly 2 I wanted.
What I'm trying to suggest is that defining a function with a parameter
whose type is a typedef defined by an external module (in this case the
standard library) is in fact very much like defining an open ended
family of functions.
It is like defining one member of that family (albeit we don't know which
one).
I do see your point, but I don't think you see mine yet. The example below
may make it clearer.
The header-file vs. cpp-file difference is a bit of a red herring IMHO,
for a couple of reasons: first, the need to put function templates in
headers is simply a hack to get around non-conforming compilers.
(Export *really* is in the standard; maybe someday the folks at
Microsoft and the gcc team will get around to implementing it....)
I disagree; I don't think "export" helps much here. It's still the case
that if we change a template function's implementation, the compiler will
have to do more work than if we change a non-template function's
implementation.
Second, even without export, you can get the same effect with an
explicit instantiation of the template in a .cpp file.
This is better, and an under-used feature - it does solve the problem of
managing dependencies on our function's definition. However, it doesn't
solve the problem of declaring a family of functions. For example:
#include <vector>
//void func( std::vector<int>::iterator );
template <typename T> void func( T );
template void func( std::vector<int>::iterator );
void func( double x );
void test() {
func( 1 );
}
This fails to compile because there is no definition of the template for
the int argument. If I delete the template and uncomment the simple
iterator overload, the code does compile.
(I tested this with http://www.comeaucomputing.com/tryitout/ - thank you,
Comeau.)
But it's not just about container iterator types...it's about typedef's
in general.
Agreed.
You get into exactly the same issues if you try to write:
void g( size_t ) {}
void g( unsigned ) {}
Agreed. However, the existence of this problem does not mean we should not
fix the vector problem.
The vector problem is worse, for me, partly because I quite often need to
work with both iterators and pointers, and because if they are different
types there is no implicit conversion from one to the other. Where-as a I
can usually write single overload which will handle both size_t and
unsigned cases of g().
I also think it is easier to fix the vector problem. I think it is more
reasonable to require vector<X>::iterator to be a unique type than to
require vector<X>::size_t to be unique.
-- Dave Harris, Nottingham, UK.
---
[ 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 ]