Deriving from an iterator?

Discussion in 'C++' started by Mark P, Feb 17, 2006.

  1. Mark P

    Mark P Guest

    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
     
    Mark P, Feb 17, 2006
    #1
    1. Advertising

  2. On 2006-02-17 13:53:22 -0500, Mark P
    <> 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
     
    Clark S. Cox III, Feb 17, 2006
    #2
    1. Advertising

  3. On Fri, 17 Feb 2006 18:53:22 GMT, Mark P
    <> 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
     
    Roland Pibinger, Feb 17, 2006
    #3
  4. Mark P

    Pete Becker Guest

    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, Feb 17, 2006
    #4
  5. Mark P

    Pete Becker Guest

    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.
     
    Pete Becker, Feb 17, 2006
    #5
  6. Mark P

    Mark P Guest

    Clark S. Cox III wrote:
    > On 2006-02-17 13:53:22 -0500, Mark P
    > <> 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.
     
    Mark P, Feb 17, 2006
    #6
  7. "Mark P" <> wrote in message
    news:CYoJf.13967$...

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


    No.
     
    Andrew Koenig, Feb 17, 2006
    #7
  8. Mark P

    Csaba Guest

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

    > "Mark P" <> wrote in message
    > news:CYoJf.13967$...
    >
    >> 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.
     
    Csaba, Feb 18, 2006
    #8
  9. On Fri, 17 Feb 2006 15:26:53 -0500, Pete Becker <>
    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
     
    Roland Pibinger, Feb 18, 2006
    #9
  10. Roland Pibinger wrote:
    > On Fri, 17 Feb 2006 15:26:53 -0500, Pete Becker <>
    > 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
     
    James Dennett, Feb 18, 2006
    #10
  11. Mark P

    Pete Becker Guest

    Roland Pibinger wrote:
    > On Fri, 17 Feb 2006 15:26:53 -0500, Pete Becker <>
    > 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.
     
    Pete Becker, Feb 18, 2006
    #11
  12. "Pete Becker" <> wrote in message
    news:...
    > Roland Pibinger wrote:
    >> On Fri, 17 Feb 2006 15:26:53 -0500, Pete Becker <>
    >> 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
     
    Eugene Kalenkovich, Feb 18, 2006
    #12
  13. Csaba wrote:

    > "Andrew Koenig" <> wrote in
    > news:EVsJf.36009$id5.11617@bgtnsc04- news.ops.worldnet.att.net:
    >
    >> "Mark P" <> wrote in message
    >> news:CYoJf.13967$...
    >>
    >>> 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
     
    Stein Gulbrandsen, Feb 19, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hendrik Maryns
    Replies:
    18
    Views:
    1,467
  2. greg
    Replies:
    6
    Views:
    483
    Dietmar Kuehl
    Jul 17, 2003
  3. Replies:
    6
    Views:
    698
    Jim Langston
    Oct 30, 2005
  4. Steven D'Aprano

    What makes an iterator an iterator?

    Steven D'Aprano, Apr 18, 2007, in forum: Python
    Replies:
    28
    Views:
    1,275
    Steven D'Aprano
    Apr 20, 2007
  5. David Bilsby
    Replies:
    5
    Views:
    2,097
    David Bilsby
    Oct 9, 2007
Loading...

Share This Page