Thread: A question again, this one should be fast!

  1. #1
    Hail to the king, baby. Akkernight's Avatar
    Join Date
    Oct 2008
    Location
    Faroe Islands
    Posts
    717

    A question again, this one should be fast!

    You peeps are awsome, so I'm almost addicted at asking questions here D:

    Anyways, I have this vector in a class

    Code:
    mngr.plr_vec.push_back(*new player);
    well, you should see that that's kinda long to type each time xP
    So I wanted to use a pointer (my arch-enemy for some reason D: ), now is it possible to point to the vector? I've tried loads, but none work, and since I'm always so unsure about pointers, I decided to ask here
    Thanks in advance!
    Last edited by Akkernight; 02-22-2009 at 04:18 PM.
    Currently research OpenGL

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    You could use a reference:
    Code:
    std::vector<player> &v = mngr.plr_vec;
    
    v.push_back(new *player);
    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    You can use a pointer to the vector, sure. It will add more characters to the line, so irregardless of whether its a good idea on the merits, it doesn't seem to meet your immediate needs.

  4. #4
    Hail to the king, baby. Akkernight's Avatar
    Join Date
    Oct 2008
    Location
    Faroe Islands
    Posts
    717
    What do you mean by, it'll add more characters o.O? If I make the vector "mngr.plr_vec" into "players" that shortens it...
    Currently research OpenGL

  5. #5
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    I sillily thought you meant a pointer in place of the original vector, not pointing to the original vector. "Because it's less typing" is still not much of a reason to do such a thing though.

  6. #6
    Hail to the king, baby. Akkernight's Avatar
    Join Date
    Oct 2008
    Location
    Faroe Islands
    Posts
    717
    Yes, when I use the "mngr.plr_vec" it gets clumsy and confusing xP
    but thanks for clearing this up!
    Currently research OpenGL

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by tabstop View Post
    I sillily thought you meant a pointer in place of the original vector, not pointing to the original vector. "Because it's less typing" is still not much of a reason to do such a thing though.
    I do agree.

    I have worked on code that uses references/pointer to various blocks, but it's only really meaningful if there is more to it than "not having to type a few letters".

    If, for example, we had some sort of indirection, which would potentially cause the compiler to generate extra code, then that's a different story, e.g.
    Code:
    void func(vector<...> &bigObjectVariableVector, int index)
    {
        int otherIndex;
        ... 
        if (bigObjectVariableVector[index].someObjectList[otherIndex].x == somethingelse.x)
        {
           .. several lines using bigObjectVariableVector[index].someObjectList[otherIndex].*
        }
    }
    In this code, it may be worth replacing the bigObjectVariableVector[index].someObjectList[otherIndex] with a reference to the what represents someObjectList[otherIndex], not only because it is less to type, but also becasue it may shorten the access if the compiler knows that we are always referring to the same object.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Akkernight View Post
    Yes, when I use the "mngr.plr_vec" it gets clumsy and confusing xP
    but thanks for clearing this up!
    You'd better get used to that sort of thing. That is definitely NOT long.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    >> mngr.plr_vec.push_back(*new player);

    This does not seem right at all, why are you dereferencing a pointer to a new player before adding it to the vector?

  10. #10
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Akkernight View Post
    Code:
    mngr.plr_vec.push_back(*new player);
    That's a memory leak. You dynamically allocate a player, dereference and push a COPY of this player onto the vector, then lose the pointer, leaking the original object.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #11
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by Akkernight View Post
    Code:
    mngr.plr_vec.push_back(*new player);
    That's what you call an instant leak. Unless of course, your player constructor is funky in that it adds its own address to some global container somewhere.

    What do you mean by "point to the vector"? Are you wanting to put pointers into the vector?
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  12. #12
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    While I'm at it, I'd also like to mention that you should simply title your threads according to what the question is about.
    Respectfully, nobody cares whether you think your question will be answered (or asked) quickly or not. Labelling a question as "quick" is more of a disincentive to even read the thread, than anything else.
    Something as simple as "pointers and vectors" would be fine.

    Have you read the "How to ask questions the smart way" article? Hell I even brushed up on it recently.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  13. #13
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Also, this code:

    Quote Originally Posted by Akkernight View Post
    Code:
    mngr.plr_vec.push_back(...);
    Is a sign of improper abstraction. Some other piece of code is reaching into the manager object, getting a member from it (the plr_vec), then manipulating it. That's totally against object oriented design. What I would expect to see is:

    Code:
    mngr.AddPlayer(...)
    Or something close to that. Also, classes which are called "managers" tend to be extremely hard to understand, because "manager" doesn't mean very much. The existence of such a class is often a sign of a design problem in and of itself.

    If the manager simply serves as a container which holds all the players, items, or whatever else, then this thing is more like a "World" or "Universe" than a manager. And it's certainly NOT managing anything when other code is grabbing its private parts like that.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Question about pointers #2
    By maxhavoc in forum C++ Programming
    Replies: 28
    Last Post: 06-21-2004, 12:52 PM
  2. Question...
    By TechWins in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 07-28-2003, 09:47 PM
  3. opengl DC question
    By SAMSAM in forum Game Programming
    Replies: 6
    Last Post: 02-26-2003, 09:22 PM
  4. Question about linked lists.
    By cheeisme123 in forum C++ Programming
    Replies: 6
    Last Post: 02-25-2003, 01:36 PM
  5. Question, question!
    By oskilian in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 12-24-2001, 01:47 AM

Tags for this Thread