|
Boost : |
Subject: Re: [boost] Iterator facade example could use some changes/documentation adjustments
From: Jacob McIntosh (nacitar_at_[hidden])
Date: 2010-02-11 10:16:32
> From: Jeffrey Hellrung <jhellrung_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] Iterator facade example could use some
> changes/documentation adjustments
>
> I think this is a valid concern, though I'm guessing this would cause
> problems at most infrequently. I'm having difficulty coming up with a
> use case where this would be a problem. Did you stumble upon this while
> writing "real" code?
It just came to mind while I was writing some of my own iterators. I
wasn't even using iterator facade to do it, as I ended up using raw
pointers for iterators in my use case, but I started looking at the
documentation for is_convertible to figure out why they chose that
conversion, and noticed the other behavior.
And, though I personally haven't used that in real code, I could
imagine a developer having the bright idea of converting a derived
iterator into a base one thinking it will _only_ remove his need to
explicitly cast the value provided by the derived iterator for
whatever purpose.
But, even disregarding that, on a more basic level... using
is_convertible to allow conversion from non-const to const iterators
is really doing more than just that. It's letting you do a host of
other things as well... and though my example involved derived
classes, The same would happen in cases like converting an integer
iterator into a double iterator, as is_convertible returns true in
that case as well. Any time the size of the types is different, it
could cause problems. This is arguably a very stupid usage of
iterators, but if we can enforce proper usage via compile time errors
rather than runtime errors... why not?
>
> Would this motivate the existence of an is_iterator_convertible
> metafunction, which is identical to is_convertible except for pointers?
>
> - Jeff
>
I'm not sure what there is to gain from this, would have to see what
functionality is_iterator_convertible would provide. IMO, it doesn't
make a whole lot of sense to convert an iterator<A> to iterator<B>
unless A == const B. Converting a const iterator to non-const
iterator wouldn't enforce the access of the const iterator, and doing
so in a copy constructor removes the need to const_cast for clarity.
And converting an iterator<derived> to iterator<base>... or
iterator<int> to iterator<double> doesn't seem to make much sense, to
me.
- Jacob
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk