Re: Should value_type, reference_type, etc. be in standard iterator types?
Chris Jefferson schrieb:
Here is an interesting question that came up recently. Is the
following standards conforming?
list<int>::iterator::value_type t;
It might compile, or not - no guarantee. The iterator types
of all containers of the container library are implementation
defined and no such guarantees are given. An exception
to this rule is, that all reverse iterator's do provide this
guarantee, because they are specified to be std::reverse_iterator's
(which derives from std::iterator and thus is supposed to
provide these typedef's). Personally I never used this
knowledge as advantage to access reverse_iterator typedef's
by directly asking the iterator type itslef, I always use
Container-typedef's or std::iterator_traits.
In this special situation I see no reason, why you should not
use list<int>::value_type (which is int, of course).
In general std::iterator_traits is the way to go - why don't you
use it?
The most obvious manner of making sure iterator_traits works for non-
pointer iterator types is to insert value_type, difference_type, etc.
into the iterator. However, is this required? I can think of two ways
around this:
It is not required. The iterator types *specified* in the standard
do follow this convention (specified), but no user/implementation-
defined iterator is required to do so. This is a good thing, IMO.
1) Specialise iterator_traits for the iterators of each of the
standard containers
2) Make iterator_traits a friend of the iterators and make the
typedefs private.
These are the obvious solutions, but not the only choices.
The reason this came up originally is:
vector<int>::iterator::value_type t;
In compilers where vector::iterator is a raw pointer, this code
clearly won't work. In the case where iterator is not a pointer, I can
think of 3 readings of the standard.
First, I don't see any reason, why you shouldn't use either
ContainerType::value_type of
std::iterator_traits<ItratorType>::value_type.
std::iterator_traits is the perfect example of an interface
adaption. IMO it is a bad programming style, if I have to think
about the actual implementation of an implementation-defined
entity. If you differentiate between iterator types at this level,
where do you stop? Consequently all types, which need
any form of an adaptor, are wrongly written, then?
1) This has to work, as the standard doesn't allow messing around with
the definition of iterator_traits.
I don't understand what you mean with "messing around"
here. The C++ standard has provided std::iterator_traits as an
customization point for exactly this reason and you are allowed
to specialize it for your types, see section 24.3.3. You can
also use std::iterator as a helper class or any other approach
that fulfills the constraints.
2) This may or may not work depending on how vector<int>::iterator is
implemented.
The standard guarantees no more and no less than this.
3) Implementations should try to stop this working as a QOI issue.
IMO, this is a very illogical reasoning. I cannot see why
preventing it would increase QOI, because such typedefs don't
represent a danger by itself.
Any comments / suggestions? Would it possibly be worth saying this
typedefs have to be defined, simply because they are so frequently
defined? Perhaps even require that vector::iterator is a class in C+
+09 just to standardise behaviour?
It would be *possible* to require that, but I see no convincing
reasons for that. IMO, you should accept this pattern of interface
adaption and use std::iterator_traits - it was invented for this
reason.
Interface adaptions foster code robustness and remove
unnecessary dependencies.
Greetings from Bremen,
Daniel Kr?gler
---
[ 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 ]