ownership of memory in stl containers??

Discussion in 'C++' started by Khalid, Mar 2, 2004.

  1. Khalid

    Khalid Guest

    II am allocating alot of memory for my problem model which uses stl containers
    for these pointers,
    will stl free the memory?

    by other words what is the semantics of memory ownership in stl?

    thanks a lot

    kh
     
    Khalid, Mar 2, 2004
    #1
    1. Advertising

  2. "Khalid" <> wrote in message
    news:c22nvb$...
    > II am allocating alot of memory for my problem model which uses stl

    containers
    > for these pointers,
    > will stl free the memory?


    No.

    >
    > by other words what is the semantics of memory ownership in stl?


    You allocated it, you free it.

    STL always operates on a copy of whatever you give to it. However a copy of
    a pointer is just a pointer.

    It actually much better to avoid raw pointers and the STL. Maybe you should
    conisder using a smart pointer instead?

    >
    > thanks a lot
    >
    > kh


    john
     
    John Harrison, Mar 2, 2004
    #2
    1. Advertising

  3. Khalid

    Dave Guest

    STL will free the memory *it* allocates to store your pointers. However,
    you are responsible for deallocating the memory your pointers point to. STL
    can't possibly know to free that memory because, for all STL knows, your
    pointers could be pointing to memory that was not dynamically allocated.

    If you want the deallocation of your memory to happen automatically, you
    might consider using a smart pointer rather than a pointer. STL *will* call
    the destructor of the elements it holds if those elements are of class type.
    In the case of a smart pointer, that destructor call would result in the
    deallocation of your memory (though, again, STL is not doing it directly).

    HTH,
    Dave


    "Khalid" <> wrote in message
    news:c22nvb$...
    > II am allocating alot of memory for my problem model which uses stl

    containers
    > for these pointers,
    > will stl free the memory?
    >
    > by other words what is the semantics of memory ownership in stl?
    >
    > thanks a lot
    >
    > kh
     
    Dave, Mar 2, 2004
    #3
  4. Thorsten Ottosen, Mar 3, 2004
    #4
  5. Khalid

    David Rubin Guest

    John Harrison wrote:

    > STL always operates on a copy of whatever you give to it. However a copy of
    > a pointer is just a pointer.
    >
    > It actually much better to avoid raw pointers and the STL. Maybe you should
    > conisder using a smart pointer instead?


    I've seen this suggested many times, but I've never read enough to
    understand the benefits. My impression is that a "shared pointer" is an
    object which encapsulates a pointer to the "real data." A copy of this
    object is stored in the STL container. Since the container holds an
    object (versus a pointer), the object destructor is called when the
    container element is erase()d, and hence the real object is delete'd.
    This is superior to storing raw pointers for which the caller must a)
    hold a reference and coordinate object cleanup, or b) leak memory. Is
    this at all accurate?

    /david

    --
    "As a scientist, Throckmorton knew that if he were ever to break wind in
    the echo chamber, he would never hear the end of it."
     
    David Rubin, Mar 3, 2004
    #5
  6. "David Rubin" <> wrote in message
    news:VF91c.756$...
    > John Harrison wrote:
    >
    > > STL always operates on a copy of whatever you give to it. However a copy

    of
    > > a pointer is just a pointer.
    > >
    > > It actually much better to avoid raw pointers and the STL. Maybe you

    should
    > > conisder using a smart pointer instead?

    >
    > I've seen this suggested many times, but I've never read enough to
    > understand the benefits. My impression is that a "shared pointer" is an
    > object which encapsulates a pointer to the "real data." A copy of this
    > object is stored in the STL container. Since the container holds an
    > object (versus a pointer), the object destructor is called when the
    > container element is erase()d, and hence the real object is delete'd.


    Different smart pointers have different benefits. But for this situation
    reference counting would be used which means that the real object would only
    be deleted when the destructor for the last copy of the smart pointer is
    invoked. This has many benefits whether or not those smart pointers happen
    to be in STL container. Boost's shared pointer works like this (I guess
    that's what makes it a _shared_ pointer).

    > This is superior to storing raw pointers for which the caller must a)
    > hold a reference and coordinate object cleanup, or b) leak memory. Is
    > this at all accurate?


    Not quite sure what you mean by hold a reference, but the rest seems
    accurate enough. For me the big problem in holding raw pointer in STL
    containers is that you can manage it easily enough if you have only a single
    copy of the container but a soon as you start to want to make copies of the
    container things rapidly get too complex and messy.

    john
     
    John Harrison, Mar 3, 2004
    #6
    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. Eric Sasser
    Replies:
    2
    Views:
    1,097
    jlchereau
    Nov 16, 2008
  2. Tomasz Grobelny
    Replies:
    4
    Views:
    2,212
    Mike Wahler
    Jan 1, 2005
  3. Replies:
    14
    Views:
    3,135
    Gianni Mariani
    May 23, 2005
  4. Alex Vinokur
    Replies:
    10
    Views:
    546
    Alex Vinokur
    Apr 1, 2006
  5. Andrey Vul
    Replies:
    6
    Views:
    575
    James Kanze
    Oct 22, 2009
Loading...

Share This Page