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!

You could use a reference:

Code:

---

std::vector<player> &v = mngr.plr_vec;

v.push_back(new *player);

---

--
Mats

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.

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...

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.

Yes, when I use the "mngr.plr_vec" it gets clumsy and confusing xP
but thanks for clearing this up!

Quote:

---

Originally Posted by tabstop

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

Quote:

---

Originally Posted by Akkernight

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

>> 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?

Quote:

---

Originally Posted by Akkernight

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.

Quote:

---

Originally Posted by Akkernight

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?

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.

Also, this code:

Quote:

---

Originally Posted by Akkernight

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.