Our new Indie Games subforum is now open for business in G&T. Go and check it out, you might land a code for a free game. If you're developing an indie game and want to post about it,
follow these directions. If you don't, he'll break your legs! Hahaha! Seriously though.
Our rules have been updated and given
their own forum. Go and look at them! They are nice, and there may be new ones that you didn't know about! Hooray for rules! Hooray for The System! Hooray for Conforming!
Pointers and Classes, arg (C++)
Posts
Because of default parameters? They are part of .Net 4.0. Not to mention the vast majority of the time overloading will accomplish the same result (and could easily work for his need as well).
Consider this (I think more common) approach:
Declare a *Player pointer (let's call it pcPlayer) that always points to the player character (the head of the list).
Allocate the PC's Player using "new Player", then fill it with his player's property; point pcPlayer here.
Allocate an NPC Player using "new player", then fill it however you want (using an RNG...); point pcPlayer->next here.
Keep allocating NPC Players, adding to the end of the linked list as you go (keep a separate pointer to track the end of the linked list).
Now you have a pointer pcPlayer to the start of your list, and a neat linked list holding your characters.
If you want to keep a list of inactive/benched Players (William and Terry?), keep them in a separate list. If someone in the main list dies, and you want to replace them using a benched player, just remove them from the bench, and add them to the active list. Etc.
Yeah, that would actually be better, too, since I wouldn't have to search the list for it.
Is -> used when you're dealing with a pointer?
Yes.
Yes, you use -> when you are trying to access a member of a class that your pointer is pointing too. It's basically a shorthand for dereferencing the pointer then doing the member access. So, assuming that PC is a pointer to an object with a member function getName(), the following two expressions have the same results if there is no operator overloading going on:
To quote a (more than likely) great man, "It only ends once. Everything else is just progress."
Player *people[5] = {ptr1, ptr2, ptr3, ptr4, pt5};
That declares an array of five pointers. So to retrieve the first player in the array you simply type *people[0]. people[0] for the pointer, * to dereference it. You're not actually storing the data "in" anything, just references to it.
class ListNode { public: Player value; ListNode *next; }The list nodes reference eachother to form the list structure, and each node has a player as its value. Not only is this much more flexible but it also means that you are using an actual list object in your code when you want a list, and not using the Player class for multiple purposes. To use the list you store a pointer to the head ListNode and iterate through that when you want to find something.
Uh, yeah. That's what I said.
And putting the list stuff in the class you want to link is kinda how I learned. I understand the utility of a node class, but this works for me since I only add it to classes I plan on linking.
And yeah it works but it doesn't really make sense - it's important to write clear and logical code, otherwise it'll start confusing even you when you try to wrap your head around it all, and you'll get more bugs and mistakes.
While it might be easier in the short term to do it your way, in the long run it will be easier to have done it the correct way from the beginning. For instance: you decide you want to put a player into two separate lists instead of a list and an array.
Dude, the way I'm doing it isn't incorrect, it's just a different method of doing it. When I say that's how I was introduced to linked lists, it was in a college C++ course, not from fumbling around a website or something. Yes, we also learned how to write a Node class. And yes, that's a good example of needing to separate it, but I won't need 2 separate lists of the same players with what I'm doing. I appreciate the advice, but a little less condescension please.
And I think maybe you guys are misunderstanding me. As of my latest design, I have one list (well, two, but I need two separate ones) with a head pointer, a single PC pointer to the first element in the list, and an NPC pointer array to the next four people in the list, at the beginning of the game. The array data will change as houses are killed off or replaced. I stopped copying data to two different places. I need to be able to reference NPC1, who is in column 1 in the opponent data screen, etc. Yeah, I guess I could have a 4 person list, but replacing NPC[2] with a pointer is much easier for me than reordering a list with a new member.
I think that works a lot better than simply following internet advice as some kind of axiom. The best we can do is tell him how to do what he wants, and suggest what we might do given the incomplete picture we have.
Maybe it's my "inexperience" talking, but to me, passing the head of a list to a function that returns the number of items in the list makes perfect sense.
That's just it, it's not the head of a list. It's a Player. Nobody would suspect that it also contains list functionality by looking at its name. The "next" pointer has no inherent meaning in the definition of a Player, it's something that belongs in outside logic.
I seem to recall seeing the same sort of thing in academic examples, too. But that's not generally how people actually do it in the real world, which in my experience is more similar to Zek's way.
Your way is good enough though, so carry on. I did a whole load of crazy things when I was learning. You can worry all day whether it is correct or not. It's better to plough on and do it.
Stop it. Plenty of real world applications do in-object linked lists. It's a preference, with neither way being right or wrong. Make your suggestions, but don't call something out as wrong when it isn't. A big plus for keeping list management inside of the class itself is that you have a single spot for a memory footprint, rather than splitting it into a couple of places.
Plenty of real-world programmers write crazy unreadable code too. I think the vast majority of applications don't have such strict performance requirements that it's worth micromanaging stuff like that at the expense of readability.
I've never seen a programmer hold good standards 100% of the time. Ever. Well, at least not one that ever accomplished much more than "Hi there, this is what's in my file:".