Pointers and Vectors

Discussion in 'C++' started by enki, Dec 5, 2005.

  1. enki

    enki Guest

    What I want to do is create sprites and put them in a vector. I know
    that this specific example dosn't realy fit in this group but my sprite
    are ponters.


    vector<*sprite>spvec;
    sprite * mysprite new sprite(....);

    when I create a sprite \:

    spvec.push_back(mysprite);

    basically I want to do somthing like this:

    switch(val){
    case 1:
    sprite * mysprite new sprite(...);
    case2....

    basically I want to create and destroy an unknown number of sprites
    stored and controlled in a vector, is this a good way to go.

    I understand that a pointer hods a memory location but I am a but
    confused with how dynamic memory works.

    int x;
    int px;

    x =10;
    px = &x;

    With int * p = new int;
    p points to the data but where is the original data stored much like in
    t x and px just points to x?
    enki, Dec 5, 2005
    #1
    1. Advertising

  2. enki

    Rolf Magnus Guest

    enki wrote:

    > What I want to do is create sprites and put them in a vector. I know
    > that this specific example dosn't realy fit in this group but my sprite
    > are ponters.
    >
    >
    > vector<*sprite>spvec;


    vector<sprite*>spvec;

    > sprite * mysprite new sprite(....);


    sprite * mysprite = new sprite(....);

    > when I create a sprite \:
    >
    > spvec.push_back(mysprite);
    >
    > basically I want to do somthing like this:
    >
    > switch(val){
    > case 1:
    > sprite * mysprite new sprite(...);
    > case2....
    >
    > basically I want to create and destroy an unknown number of sprites
    > stored and controlled in a vector, is this a good way to go.


    Something like:

    for (int x = 0; x < val; ++x)
    {
    spvec.push_back(new sprite(...));
    }

    ?

    > I understand that a pointer hods a memory location but I am a but
    > confused with how dynamic memory works.


    Why are you dynamically allocating your spites?

    > int x;
    > int px;
    >
    > x =10;
    > px = &x;
    >
    > With int * p = new int;
    > p points to the data but where is the original data stored much like in
    > t x and px just points to x?


    C++ separates the memory into three regions:
    - automatic storage. This is where local variables go
    - static storage. This is where namespace-scope and static local and member
    variables go.
    - free storage. This is where 'new' takes memory from.

    So the data that p points to is located in free storage. new automatically
    searches for a free block of memory big enough to hold the type you want to
    allocate and gives you a pointer to that location.
    As soon as you don't need the value anymore, you need to delete it to give
    the allocated memory back to the system.
    Rolf Magnus, Dec 5, 2005
    #2
    1. Advertising

  3. On 5 Dec 2005 07:10:12 -0800, "enki" <> wrote:

    >What I want to do is create sprites and put them in a vector. I know
    >that this specific example dosn't realy fit in this group but my sprite
    >are ponters.


    First of all, I would highly recommend starting out here (the C++
    FAQ):
    http://www.parashift.com/c -faq-lite/

    >vector<*sprite>spvec;
    >sprite * mysprite new sprite(....);


    You need to write:
    sprite * mysprite = new sprite(....);

    When you are done with the sprite, you must destroy the object,
    otherwise you will have a memory leak:
    delete mysprite;

    Also, it is a good idea to set the pointer to 0 in order to avoid a
    double deletion bug:
    mysprite = 0;

    >when I create a sprite \:
    >
    >spvec.push_back(mysprite);
    >
    >basically I want to do somthing like this:
    >
    >switch(val){
    > case 1:
    > sprite * mysprite new sprite(...);
    > case2....
    >
    >basically I want to create and destroy an unknown number of sprites
    >stored and controlled in a vector, is this a good way to go.


    If you can copy your sprite objects, and the overhead of copying
    resources isn't too large, it would be better to keep them in a vector
    of objects. That way, you won't need to manage the lifetimes with new
    and delete.

    However, if you have polymorphic sprites and need to keep sprites of
    the different inherited types in one container, you must use pointers
    of the common base class. This also means making sure that your base
    class has a virtual destructor because you will have to call delete on
    the base class pointer, and that would cause undefined behavior
    otherwise.

    >I understand that a pointer holds a memory location but I am a but
    >confused with how dynamic memory works.
    >
    >int x;
    >int px;
    >
    >x =10;
    >px = &x;
    >
    >With int * p = new int;
    >p points to the data but where is the original data stored much like in
    >t x and px just points to x?


    You really need to read the FAQ and a good text book.

    Creating an int (or anything else) with new allocates a region of
    memory on the free store, or process heap (assuming that new and
    delete haven't been overloaded to do something else). This is called
    "dynamic memory allocation". Any of your other declarations above will
    allocate the memory either in some unspecified segment of RAM decided
    by the compiler and the operating system, if it is a global or static
    variable, or else the variable is allocated locally on the stack. The
    C++ standard, however, doesn't specify what a stack is or that local
    variables must be allocated exactly that way. It is implementation
    defined how the compiler does it. At any rate, the moment you leave
    the block where the local variable is declared, it goes out of scope
    (i.e. ceases to exist) and the memory it occupied is freed by the
    compiler automatically -- that's why they are also called "automatic"
    variables. With dynamic allocation, the object continues to live
    beyond the local scope. However, if the pointer to that object was
    declared locally, the pointer goes out of scope, and if you didn't
    delete the memory before that happens, you would have a memory leak --
    unless you had copied the pointer into your vector, of course, in
    which case you delete it later, and there is no leak.

    If your program allocates objects dynamically, it is also responsible
    for destroying the objects in an orderly fashion. For that reason,
    it's best to avoid using new and delete if you can. That's why it
    might be a very good idea to keep objects instead of pointers in your
    vector.

    Good luck -- you have lots to learn, but it will hopefully be fun in
    the process!

    --
    Bob Hairgrove
    Bob Hairgrove, Dec 5, 2005
    #3
  4. enki

    Guest

    Bob Hairgrove wrote:

    > If you can copy your sprite objects, and the overhead of copying
    > resources isn't too large, it would be better to keep them in a vector
    > of objects. That way, you won't need to manage the lifetimes with new
    > and delete.
    >
    > However, if you have polymorphic sprites and need to keep sprites of
    > the different inherited types in one container, you must use pointers
    > of the common base class. This also means making sure that your base
    > class has a virtual destructor because you will have to call delete on
    > the base class pointer, and that would cause undefined behavior
    > otherwise.


    On top of that, if you are going to be sharing these pointers with any
    other object I would recommend using a smart pointer of some sort
    either from boost or home brew.
    , Dec 5, 2005
    #4
  5. On 5 Dec 2005 08:03:38 -0800, wrote:

    >
    >Bob Hairgrove wrote:
    >
    >> If you can copy your sprite objects, and the overhead of copying
    >> resources isn't too large, it would be better to keep them in a vector
    >> of objects. That way, you won't need to manage the lifetimes with new
    >> and delete.
    >>
    >> However, if you have polymorphic sprites and need to keep sprites of
    >> the different inherited types in one container, you must use pointers
    >> of the common base class. This also means making sure that your base
    >> class has a virtual destructor because you will have to call delete on
    >> the base class pointer, and that would cause undefined behavior
    >> otherwise.

    >
    >On top of that, if you are going to be sharing these pointers with any
    >other object I would recommend using a smart pointer of some sort
    >either from boost or home brew.


    Yes, of course ...
    but I thought I wouldn't get into that just yet. ;)

    --
    Bob Hairgrove
    Bob Hairgrove, Dec 5, 2005
    #5
  6. enki

    JoeC Guest

    Thanks for pointers, oops no pun.


    Why are you dynamically allocating your spites?

    That is what my book shows. And it seems to work better.
    JoeC, Dec 5, 2005
    #6
  7. enki

    JoeC Guest

    Thaks all... I will see how it all works in my progaram.
    JoeC, Dec 5, 2005
    #7
  8. enki

    Howard Guest

    "JoeC" <> wrote in message
    news:...

    To what/who are you responding? You don't include any of the text of the
    message above...

    > Thanks for pointers, oops no pun.
    >
    >
    > Why are you dynamically allocating your spites?


    (Assuming you're the original poster...)
    You started it! :) Your code was:

    sprite * mysprite new sprite(....);

    All that was done was to correct the syntax by adding the = sign before the
    keyword new. If you didn't want dynamic allocation, then what's the "new"
    doing there, and why is it a pointer?

    >
    > That is what my book shows. And it seems to work better.


    _What_ is what your book shows? And what works better than what? Please
    quote what you're responding to, and don't just assume we know what you're
    talking about.

    -Howard
    Howard, Dec 5, 2005
    #8
    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. Replies:
    10
    Views:
    675
    Ron Natalie
    Dec 10, 2004
  2. Replies:
    2
    Views:
    413
  3. Replies:
    3
    Views:
    694
    Shadowman
    Mar 26, 2008
  4. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    672
  5. Guest
    Replies:
    0
    Views:
    439
    Guest
    Sep 14, 2005
Loading...

Share This Page