STL-container used with references

Discussion in 'C++' started by Severin Ecker, Apr 6, 2004.

  1. hi!

    normally i would simply do the following:

    std::vector<Element> vec;
    void somefunc() {
    Element e;
    vec.push_back(e);
    }

    now Element e is in the vector. thats fine as long as no polymorphic
    behaviour is needed.

    std::vector<Element &> vec;
    void somefunc() {
    Derived_from_Element e;
    vec.push_back(e); //bad idea,.. e is gone after functionscope is left
    }

    what i want to avoid (if possible) are 2 things:
    dynamic allocation of the objects, and having an extracontiner for every
    type derived from the basetype to store the elements.

    i hope, i made clear what i'm trying to do... so is there a solution (except
    for the 2 mentioned above?)

    thx, regards,
    sev
     
    Severin Ecker, Apr 6, 2004
    #1
    1. Advertising

  2. Severin Ecker

    tom_usenet Guest

    On Tue, 6 Apr 2004 15:04:53 +0200, "Severin Ecker" <>
    wrote:

    >hi!
    >
    >normally i would simply do the following:
    >
    >std::vector<Element> vec;
    >void somefunc() {
    > Element e;
    > vec.push_back(e);
    >}
    >
    >now Element e is in the vector. thats fine as long as no polymorphic
    >behaviour is needed.
    >
    >std::vector<Element &> vec;


    You can't hold references in containers - references are just aliases,
    not real objects.

    >void somefunc() {
    > Derived_from_Element e;
    > vec.push_back(e); //bad idea,.. e is gone after functionscope is left
    >}
    >
    >what i want to avoid (if possible) are 2 things:
    >dynamic allocation of the objects, and having an extracontiner for every
    >type derived from the basetype to store the elements.
    >
    >i hope, i made clear what i'm trying to do... so is there a solution (except
    >for the 2 mentioned above?)


    It is obviously hard to avoid dynamic allocation of the objects, since
    all of your derived types can have different sizes and alignment
    requirements. There are techniques for doing it (as long as all
    derived classes are known in advance), but they would be premature
    optimization in this case I am sure. Your best bet is to use a
    container of smart pointers:

    std::vector<shared_ptr<Element> > vec;
    vec.push_back(shared_ptr<Element>(new Derived_from_Element));

    See www.boost.org for shared_ptr.

    Tom
    --
    C++ FAQ: http://www.parashift.com/c -faq-lite/
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
     
    tom_usenet, Apr 6, 2004
    #2
    1. Advertising

  3. Severin Ecker

    Howard Guest

    "tom_usenet" <> wrote in message
    > ...Your best bet is to use a
    > container of smart pointers:
    >
    > std::vector<shared_ptr<Element> > vec;
    > vec.push_back(shared_ptr<Element>(new Derived_from_Element));
    >
    > See www.boost.org for shared_ptr.
    >


    Just curious...What if you don't have (or want) boost? Is there an STL
    solution similar to shared_ptr?

    -Howard
     
    Howard, Apr 6, 2004
    #3
  4. "Howard" <> wrote in message
    news:c4uhgn$...
    >
    > "tom_usenet" <> wrote in message
    > > ...Your best bet is to use a
    > > container of smart pointers:
    > >
    > > std::vector<shared_ptr<Element> > vec;
    > > vec.push_back(shared_ptr<Element>(new Derived_from_Element));
    > >
    > > See www.boost.org for shared_ptr.
    > >

    >
    > Just curious...What if you don't have (or want) boost? Is there an STL
    > solution similar to shared_ptr?
    >


    No, but it's really very simple to roll your own basic smart pointer. It
    would not have all the functionality of boost's but would certainly support
    polymorphism and automatic cleanup.

    Have a look at Scott Meyers book for example code (I think its the More
    Effective C++ one).

    john
     
    John Harrison, Apr 6, 2004
    #4
  5. Severin Ecker

    tom_usenet Guest

    On 06 Apr 2004 11:14:31 EDT, "Howard" <> wrote:

    >
    >"tom_usenet" <> wrote in message
    >> ...Your best bet is to use a
    >> container of smart pointers:
    >>
    >> std::vector<shared_ptr<Element> > vec;
    >> vec.push_back(shared_ptr<Element>(new Derived_from_Element));
    >>
    >> See www.boost.org for shared_ptr.
    >>

    >
    >Just curious...What if you don't have (or want) boost? Is there an STL
    >solution similar to shared_ptr?


    boost::shared_ptr has been proposed for standardization as part of the
    library technical report. Look out for std::tr1::shared_ptr, coming to
    your compiler soon.

    There is no current standard solution, except to write your own smart
    pointer class (not at all recommended - matching boost::shared_ptr's
    functionality is non-trivial).

    Tom
    --
    C++ FAQ: http://www.parashift.com/c -faq-lite/
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
     
    tom_usenet, Apr 6, 2004
    #5
  6. Severin Ecker

    Mike Wahler Guest

    "tom_usenet" <> wrote in message
    news:...
    > >Just curious...What if you don't have (or want) boost? Is there an STL
    > >solution similar to shared_ptr?

    >
    > boost::shared_ptr has been proposed for standardization as part of the
    > library technical report. Look out for std::tr1::shared_ptr, coming to
    > your compiler soon.


    Curiosity:

    What's the significance of the (namespace?) name 'tr1'?

    -Mike
     
    Mike Wahler, Apr 6, 2004
    #6
  7. Severin Ecker

    Pete Becker Guest

    Mike Wahler wrote:
    >
    > What's the significance of the (namespace?) name 'tr1'?
    >


    The C++ standards committee has a Technical Report in the works,
    incorporating recommended library extensions. It's known informally as
    TR1, and its extensions go in namespace std::tr1.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Apr 6, 2004
    #7
  8. Pete Becker wrote:

    > Mike Wahler wrote:
    >
    >>What's the significance of the (namespace?) name 'tr1'?
    >>

    >
    >
    > The C++ standards committee has a Technical Report in the works,
    > incorporating recommended library extensions. It's known informally as
    > TR1, and its extensions go in namespace std::tr1.
    >


    I don't like the sound of this. Are they going to permanently put these
    things in std::tr1::? Why wouldn't they just use std::? If they put it
    in std:: later, will they have to also support it in std::tr1:: for
    compatibility?

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Apr 6, 2004
    #8
  9. Severin Ecker

    Pete Becker Guest

    Kevin Goodsell wrote:
    >
    > Pete Becker wrote:
    >
    > > Mike Wahler wrote:
    > >
    > >>What's the significance of the (namespace?) name 'tr1'?
    > >>

    > >
    > >
    > > The C++ standards committee has a Technical Report in the works,
    > > incorporating recommended library extensions. It's known informally as
    > > TR1, and its extensions go in namespace std::tr1.
    > >

    >
    > I don't like the sound of this. Are they going to permanently put these
    > things in std::tr1::?


    TR1 puts them in std::tr1. Future TRs and future standards could do
    something different.

    > Why wouldn't they just use std::?


    Because they're recommended extensions and not part of the standard.

    > If they put it
    > in std:: later, will they have to also support it in std::tr1:: for
    > compatibility?
    >


    Maybe. Maybe the new stuff won't ever go into the standard.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Apr 6, 2004
    #9
  10. Pete Becker wrote:

    > Kevin Goodsell wrote:
    >
    >>Why wouldn't they just use std::?

    >
    >
    > Because they're recommended extensions and not part of the standard.
    >


    OK. I didn't make the connection that a TR is different from a TC, and
    was thinking that this /would be/ part of the standard (the comment
    "coming to your compiler soon" threw me off). If it's just a
    possibility, this makes more sense.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Apr 6, 2004
    #10
  11. On 2004-04-06, Severin Ecker <> wrote:

    > std::vector<Element &> vec;


    [...]

    > what i want to avoid (if possible) are 2 things:
    > dynamic allocation of the objects, and having an extracontiner for every
    > type derived from the basetype to store the elements.
    >
    > i hope, i made clear what i'm trying to do... so is there a solution (except
    > for the 2 mentioned above?)


    Severin,

    You cannot have a container of references, but you very well can have
    a container of pointers, i.e. something like std::vector<Element*>.
    Better yet, you can use smart pointers, e.g. boost::shared_ptr<Element>.
    In any case, remember that you have to dereference pointers (e.g. using
    functors) when you access the data (for example, using standard
    algorithms).

    You may also want to make your Element class a lightweight proxy that
    holds a reference to an actual data stored outside the container.
    (Some kind of a Featherweight pattern?)

    Hope this helps!
    Sergei.

    --
    Sergei Matusevich,
    Brainbench MVP for C++
    http://www.brainbench.com
     
    Sergei Matusevich, Apr 6, 2004
    #11
  12. "Sergei Matusevich" <> wrote in message
    news:Z4Gcc.27563$...
    [snip]
    > You cannot have a container of references, but you very well can have
    > a container of pointers, i.e. something like std::vector<Element*>.
    > Better yet, you can use smart pointers, e.g. boost::shared_ptr<Element>.


    maybe even better, use a container that takes ownership of the pointers.

    checkout the ptr_container lib in the boost sandbox.

    br

    Thorsten
     
    Thorsten Ottosen, Apr 7, 2004
    #12
  13. Severin Ecker

    tom_usenet Guest

    On Tue, 06 Apr 2004 14:24:13 -0400, Pete Becker <>
    wrote:

    >Mike Wahler wrote:
    >>
    >> What's the significance of the (namespace?) name 'tr1'?
    >>

    >
    >The C++ standards committee has a Technical Report in the works,
    >incorporating recommended library extensions. It's known informally as
    >TR1, and its extensions go in namespace std::tr1.


    How long till Dinkumware starts to track TR1 extensions? Will you wait
    until its almost finalised or even finished (the conservative,
    possibly sensible approach)?

    Tom
    --
    C++ FAQ: http://www.parashift.com/c -faq-lite/
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
     
    tom_usenet, Apr 7, 2004
    #13
  14. Severin Ecker

    Pete Becker Guest

    tom_usenet wrote:
    >
    > How long till Dinkumware starts to track TR1 extensions? Will you wait
    > until its almost finalised or even finished (the conservative,
    > possibly sensible approach)?
    >


    If all goes well, the technical work on TR1 will be finished in October.
    A significant number of changes from the original proposals have been
    the result of our work implementing it.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Apr 7, 2004
    #14
  15. tom_usenet <> wrote:
    > How long till Dinkumware starts to track TR1 extensions? Will you wait
    > until its almost finalised or even finished (the conservative,
    > possibly sensible approach)?


    I cannot speak for Dinkumware, of course, but I know that library writers
    are already implementing what is currently in the TR. Actually, quite a
    few of the defects we processed two weeks ago seem to come from people
    implementing the TR.

    Of course, this is no indication when there will be a release of the TR
    components, even if they closely track what is going on: since there are
    probably still some changes which will be applied, I think it would be
    unwise to release an implementation of the TR libraries just now. I would
    expect that you will be able to purchase or download a version relatively
    soon after the TR is finalized. I'm always confusing the data but I think
    the plan is to try and essentially finalize the TR at the next meeting ie.
    in October in Redmont.

    BTW, does anybody have a good open source implementation of the special
    functions in the lib TR? Well, not necessarily in C or C++ but at least
    the same functionality - or an idea how this stuff can be implemented?
    Some people apparently know how to do such stuff but I considered numerics
    a waste of time while at the university and in any case they didn't talk
    about computing these functions anyway (as far as I can remember...).
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Apr 7, 2004
    #15
  16. Severin Ecker

    P.J. Plauger Guest

    "Dietmar Kuehl" <> wrote in message
    news:...

    > tom_usenet <> wrote:
    > > How long till Dinkumware starts to track TR1 extensions? Will you wait
    > > until its almost finalised or even finished (the conservative,
    > > possibly sensible approach)?

    >
    > I cannot speak for Dinkumware, of course, but I know that library writers
    > are already implementing what is currently in the TR. Actually, quite a
    > few of the defects we processed two weeks ago seem to come from people
    > implementing the TR.
    >
    > Of course, this is no indication when there will be a release of the TR
    > components, even if they closely track what is going on: since there are
    > probably still some changes which will be applied, I think it would be
    > unwise to release an implementation of the TR libraries just now. I would
    > expect that you will be able to purchase or download a version relatively
    > soon after the TR is finalized. I'm always confusing the data but I think
    > the plan is to try and essentially finalize the TR at the next meeting ie.
    > in October in Redmont.


    Correct, and as Pete Becker indicated, Dinkumware has been implementing all
    of
    the pieces of TR1 for over a year now. We hope to have a *full* version soon
    after the document freezes, which we still hope will be this October. Note
    that it's a *very big* addition, including all of the functions added to C
    with C99.

    > BTW, does anybody have a good open source implementation of the special
    > functions in the lib TR? Well, not necessarily in C or C++ but at least
    > the same functionality - or an idea how this stuff can be implemented?
    > Some people apparently know how to do such stuff but I considered numerics
    > a waste of time while at the university and in any case they didn't talk
    > about computing these functions anyway (as far as I can remember...).


    The C committee has asked for an appendix to their special functions TR
    to indicate at least some way to implement each of these functions. Our
    work to date has unearthed a few free functions that are excellent, quite
    a few that are barely adequate to float precision, and numerous approaches
    that are mediocre but make a reasonable starting point. If there's a
    complete, high quality set out there we haven't found it yet. They're
    pretty tough, in general.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
     
    P.J. Plauger, Apr 7, 2004
    #16
  17. Severin Ecker

    Harald Nowak Guest

    > maybe even better, use a container that takes ownership of the pointers.
    >
    > checkout the ptr_container lib in the boost sandbox.
    >
    > br
    >
    > Thorsten


    Now THIS is finally what I've been waiting for for the last 5 years -
    a crucial missing piece - I do certainly hope that the ptr_container
    will make it into the official boost branch and from there as quickly
    as possible into the standard (or the tr).
    In the last years I've continuously pointed out that omission and
    tried to provide workarounds that deal with STL containers of pointers
    - most of the time people seemed just happy with containers of
    shared_ptr's but the main point is and was, that it is dangerous and
    yet at the same time possible to use normal pointers in STL
    containers: dangerous because algorithms can be innocently applied (as
    long as the functors are written appropriately) and yet have
    devastating effects (leaks and crashes - see my Short Tip in C++ Users
    Journal: "A remove_if for vector", C/C++ Users Journal, July 2001. ).
    If finally a dedicated version of the STL containers exist (like
    ptr_container delivers) users will be guided the correct way - thats
    why I appreciate this library so much.
     
    Harald Nowak, Apr 8, 2004
    #17
    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. Vivi Orunitia
    Replies:
    11
    Views:
    4,508
    Martijn Lievaart
    Feb 4, 2004
  2. Maitre Bart
    Replies:
    2
    Views:
    536
    Maitre Bart
    Feb 11, 2004
  3. Replies:
    4
    Views:
    816
    Daniel T.
    Feb 16, 2006
  4. wolverine
    Replies:
    2
    Views:
    462
    Marcus Kwok
    Jul 24, 2006
  5. Rui Maciel
    Replies:
    3
    Views:
    1,572
Loading...

Share This Page