Deriving from an iterator?

[Mark P]

Is it guaranteed that STL iterators are aggregate types and can thus be
derived from?

I'm thinking along the lines of, for example:

class DerIter : public std::vector<int>::iterator
{...};

My concern is whether the standard might allow an implementation to use
a bare pointer as an iterator.

Thanks,
Mark

[Clark S. Cox III]

On 2006-02-17 13:53:22 -0500, Mark P
<us****@fall2005REMOVE.fastmailCAPS.fm> said:

Is it guaranteed that STL iterators are aggregate types and can thus be
derived from?
No.
I'm thinking along the lines of, for example:

class DerIter : public std::vector<int>::iterator
{...};

My concern is whether the standard might allow an implementation to use
a bare pointer as an iterator.

Yes, it does allow it (and many implementations do use raw pointers).
For example, there is nothing preventing std::vector<T>::iterator from
being of type (T*).

Additionally, even if the iterator is aggregate, it likely won't have a
virtual destructor.

What are you trying to accomplish that cannot be accomplished by using
a has-a relationship and providing a conversion operator?


--
Clark S. Cox, III
cl*******@gmail.com

[Roland Pibinger]

On Fri, 17 Feb 2006 18:53:22 GMT, Mark P
<us****@fall2005REMOVE.fastmailCAPS.fm> wrote:

Is it guaranteed that STL iterators are aggregate types and can thus be
derived from?
No, an iterator may be a good old pointer.
I'm thinking along the lines of, for example:

class DerIter : public std::vector<int>::iterator
{...};

My concern is whether the standard might allow an implementation to use
a bare pointer as an iterator.

Why would you want to do that? You iterator wouldn't be polymorohic
anyway.

Best wishes,
Roland Pibinger

[Pete Becker]

Clark S. Cox III wrote:

Additionally, even if the iterator is aggregate, it likely won't have a
virtual destructor.

Since the usual idiom is to pass iterators by value, this makes no
difference. I can't think of a situation where you'd want to delete an
iterator.

--

Pete Becker
Roundhouse Consulting, Ltd.

[Pete Becker]

Roland Pibinger wrote:

Why would you want to do that? You iterator wouldn't be polymorohic
anyway.

Sure it would. At compile time, that is. Which is how iterators are
used: you instantiate algorithms on iterator types. Which, of course,
doesn't answer why someone would want to do it. But there's no inherent
reason it wouldn't work.

--

Pete Becker
Roundhouse Consulting, Ltd.

[Mark P]

Clark S. Cox III wrote:

On 2006-02-17 13:53:22 -0500, Mark P
<us****@fall2005REMOVE.fastmailCAPS.fm> said:

Is it guaranteed that STL iterators are aggregate types and can thus
be derived from?

No.

I'm thinking along the lines of, for example:

class DerIter : public std::vector<int>::iterator
{...};

My concern is whether the standard might allow an implementation to
use a bare pointer as an iterator.

Yes, it does allow it (and many implementations do use raw pointers).
For example, there is nothing preventing std::vector<T>::iterator from
being of type (T*).

Additionally, even if the iterator is aggregate, it likely won't have a
virtual destructor.

What are you trying to accomplish that cannot be accomplished by using a
has-a relationship and providing a conversion operator?

Thanks for the info. I briefly considered the idea when dealing with a
design issue but quickly abandoned it. (It was something convoluted
involving a derived class virtual function using a covariant return type
to return something derived from an iterator, but it really wasn't
sensible.) At the time I posted, I was just curious to know the offical
rules.

[Andrew Koenig]

"Mark P" <us****@fall2005REMOVE.fastmailCAPS.fm> wrote in message
news:CY*******************@newssvr12.news.prodigy. com...

Is it guaranteed that STL iterators are aggregate types and can thus be
derived from?

No.

[Csaba]

"Andrew Koenig" <ar*@acm.org> wrote in news:EVsJf.36009$id5.11617@bgtnsc04-
news.ops.worldnet.att.net:

"Mark P" <us****@fall2005REMOVE.fastmailCAPS.fm> wrote in message
news:CY*******************@newssvr12.news.prodigy. com...

Is it guaranteed that STL iterators are aggregate types and can thus be
derived from?

No.

In fact, Scott Meyers in "Efective STL" item 27 says "... it is common for
implementations of string and vector to use pointers as iterators".
--
Life is complex, with real and imaginary parts.

[Roland Pibinger]

On Fri, 17 Feb 2006 15:26:53 -0500, Pete Becker <pe********@acm.org>
wrote:

Roland Pibinger wrote:

Why would you want to do that? You iterator wouldn't be polymorohic
anyway.
Sure it would. At compile time, that is.

I really suggest to limit the meaning of polymorphism to 'late
binding'. Otherswise someone could also rightfully speak of e.g.
'preprocessor polymorphism'.
Which is how iterators are
used: you instantiate algorithms on iterator types. Which, of course,
doesn't answer why someone would want to do it. But there's no inherent
reason it wouldn't work.

--

Pete Becker
Roundhouse Consulting, Ltd.

Oh, new signature

[James Dennett]

Roland Pibinger wrote:

On Fri, 17 Feb 2006 15:26:53 -0500, Pete Becker <pe********@acm.org>
wrote:

Roland Pibinger wrote:

Why would you want to do that? You iterator wouldn't be polymorohic
anyway.

Sure it would. At compile time, that is.

I really suggest to limit the meaning of polymorphism to 'late
binding'. Otherswise someone could also rightfully speak of e.g.
'preprocessor polymorphism'.

I strongly suggest qualifying the word polymorphism if
you want to speak of only one kind, such as runtime
polymorphism. The term "polymorphism" is a general one,
covering overloading, template mechanisms, virtual
dispatch and more. Sometimes in context it's clear
which we mean; sometimes it's not.

There is a move to simplify (I'll try to avoid saying
"dumb down") terminology so that we can act as if
programming is easier than actually it is. Simplistic
terminology actually makes mastering the subject harder,
not easier, by generating misunderstandings.

-- James

[Pete Becker]

Roland Pibinger wrote:

On Fri, 17 Feb 2006 15:26:53 -0500, Pete Becker <pe********@acm.org>
wrote:

Roland Pibinger wrote:

Why would you want to do that? You iterator wouldn't be polymorohic
anyway.

Sure it would. At compile time, that is.

I really suggest to limit the meaning of polymorphism to 'late
binding'. Otherswise someone could also rightfully speak of e.g.
'preprocessor polymorphism'.

Well, the term "compile-time polymorphism" is fairly common these days.

--

Pete Becker
Roundhouse Consulting, Ltd.

[Eugene Kalenkovich]

"Pete Becker" <pe********@acm.org> wrote in message
news:ko********************@giganews.com...

Roland Pibinger wrote:

On Fri, 17 Feb 2006 15:26:53 -0500, Pete Becker <pe********@acm.org>
wrote:

Roland Pibinger wrote:

Why would you want to do that? You iterator wouldn't be polymorohic
anyway.

Sure it would. At compile time, that is.

I really suggest to limit the meaning of polymorphism to 'late
binding'. Otherswise someone could also rightfully speak of e.g.
'preprocessor polymorphism'.

Well, the term "compile-time polymorphism" is fairly common these days.

Perhaps this one is too general - though usually this term refers to
templates, overloading resolution is also compile time.

-- EK

[Stein Gulbrandsen]

Csaba wrote:

"Andrew Koenig" <ar*@acm.org> wrote in
news:EVsJf.36009$id5.11617@bgtnsc04- news.ops.worldnet.att.net:

"Mark P" <us****@fall2005REMOVE.fastmailCAPS.fm> wrote in message
news:CY*******************@newssvr12.news.prodigy. com...

Is it guaranteed that STL iterators are aggregate types and can thus be
derived from?

No.

In fact, Scott Meyers in "Efective STL" item 27 says "... it is common for
implementations of string and vector to use pointers as iterators".

I guess this means that i can't overload a function like this:
void f(std::vector<C>::iterator>);
void f(C*);
Is this a general property of the types used in the standard library,
that they may randomly equal to some builtin type, and thereby
inhibit overloading?
--
stein