If it's a list, use std::list. I don't know why you would use std::vector for a list... Especially when std::list is made of so much win.

Anyway, Take things in steps. Make it a class. Get the constructor/destructor. Trying to just do it all in one swoop is a Bad Idea. Take it from me. And well, you don't even need to now since you seem to have found this out yourself.

Vectors and lists differ in their implementation but both represent sequences of elements. A std::vector is implemented under the hood as an array (that std::vector resizes as necessary). A std::list is implemented as a linked list. Therefore, between std::vector and std::list, you get all the usual tradeoffs between arrays and linked lists. Some examples: it's expensive to add/remove from anywhere in an array other than the end; linked lists have more memory overhead; you cannot directly index into linked lists but you can into arrays.

Kayle's advice of taking things slowly and only convert what you're working on is very sound. But I suppose it might be somewhat self-serving for me to say that.

One thing I've noticed for myself is that another problem with trying to convert stuff from a struct to a class is just trying to figure out what should go into it as a member of the class, especially with functions.

For instance with characters and object usage, when a character gets or losses an object, should the class for characters do something to drop the object, like ch->drop( obj ) where drop( &obj ) is a function in the character class that handles all the movement stuff, or should it maybe call a function, from_char() ( and probably to_room() as well ), from the object class?

Thinking about it right now, based off some stuff I've read, specifically in Effective C++ Third Edition by Scott Meyers, that particular issue would probably be best handled the second way by "chaining" calls between the objects. Or better yet, a bit of a combination of the two, where the character adjusts internally the things that are changed by losing the object then tells the object to go ahead and move itself to its new location.

That somewhat rambling bit above is I guess just me pointing out that, as Kayle has already stressed, you should really think about what the class needs to do for itself before going in and changing stuff off the cuff.

@Kayle:
Was just looking over your Socket class stuff and I noticed that you don't have the default constructor, Socket::Socket(), tucked away in the class as private like you do the copy constructor and the one for taking another instance of a Socket as a reference. Was kind of curious as to why not.

Andril said:

Was just looking over your Socket class stuff and I noticed that you don't have the default constructor, Socket::Socket(), tucked away in the class as private like you do the copy constructor and the one for taking another instance of a Socket as a reference. Was kind of curious as to why not.

He probably wants to allow everybody to construct Sockets, but wants to prevent people from copying them. This is a generally good thing because it would be kind of weird to have separate objects for the same socket; you could easily get inconsistent state.

Andril said:

For instance with characters and object usage, when a character gets or losses an object, should the class for characters do something to drop the object, like ch->drop( obj ) where drop( &obj ) is a function in the character class that handles all the movement stuff, or should it maybe call a function, from_char() ( and probably to_room() as well ), from the object class?

This is a very difficult problem and there are many philosophical differences on when something should be a member or when it should be a separate function. I tend to think that if a function operates on the internals of an object, it should be a member. If the function operates only on the external interface, it could be a separate function but perhaps should (for a weak value of "should") be a member function -- if it makes sense to stick things in the same place.

David's absolutely right. the constructor is public so that anything can create a socket. But if you look at the code, the copy constructor is defined, but never implemented. It's defined and private so that I get an error on compile if something is trying to call it. Because the way I've done the work so far, copying a Socket would lead to Bad Things(tm).

I understand about the copy constructor. I can just see all sorts of fun stuff happening if you accidentally give something a copy of another Socket object. And you have a constructor that takes an int to initialize the m_Control member and set up the net stuff and I totally understand why that's public and not private.

I was referring specifically to the default Socket::Socket() constructor that doesn't take any arguments. There's nothing to stop you from accidentally calling something like "Socket mySock = new Socket;" right now, other than knowing in your head not to do it. That would probably also lead to Bad Things(tm) based on my, admittedly limited, knowledge because I didn't see anything to initialize stuff except inside the constructor you have that takes an int.

Like I said before, I was just curious because it seemed to me to be something that could become an issue. *shrug*

Edit:
I have two stars! Sweet!

Andril said:

There's nothing to stop you from accidentally calling something like "Socket mySock = new Socket;" right now, other than knowing in your head not to do it. That would probably also lead to Bad Things(tm) based on my, admittedly limited, knowledge because I didn't see anything to initialize stuff except inside the constructor you have that takes an int.

It would be "bad" but not really as bad.

Consider what would happen if you have a Socket object that you pass as a copy to some function. This function would then start reading stuff, which would be consuming data off of a copied input buffer. When your original function goes to read the socket, it would be reading the same data again because the other function read it from a copy of the input buffer. And things get even worse for output; since the copy of the Socket isn't the one whose output is read, then anything that the called function writes is silently discarded!

In other words, by duplicating the Socket object, you are duplicating all of its buffers, and therefore reading things twice as input and discarding things entirely for output. Both of these are really quite bad. By contrast, creating a socket by accident isn't really too terrible, because it won't be reading from a file descriptor.

Basically it's always possible to shoot yourself in the foot. But some mistakes are quite easy to make by accident -- like passing a copy of a Socket -- whereas you wouldn't really randomly create Socket objects and give them descriptors.

Blah, bump I know, but I've been working on this a bit lately.

Can I drop a constructor and a destructor right into a struct? Or do I need to convert the struct to a class?

You can add any member functions to a struct, including constructors and a destructor. The only difference between a class and a struct is that in a class all the members are private by default while in a struct all members are public by default.

Ah perfect, that's what i needed to know.

I've worked std::list into descriptor_data, time to write the constructors and destructor, and make everything new and delete.

Make sure you use new and delete before you add constructors and/or destructors. The reason is that new will cause a constructor to be called, but malloc() and similar C functions will not. The same goes for destructor. delete will call it, but free() will not.

Ah ok, I was doing that anyways, good to know about why that is. Just now learning C++ - I'm a very hands on learner