Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Google

Members: 0
Guests: 2
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » Game_loop
Forum Rules | Mark all | Recent Posts

Game_loop
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2 next >>
Post is unread #21 Feb 12, 2010, 1:29 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

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. :P And well, you don't even need to now since you seem to have found this out yourself.
       
Post is unread #22 Feb 12, 2010, 1:58 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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. :tongue:
       
Post is unread #23 Feb 13, 2010, 10:21 am   Last edited Feb 13, 2010, 10:24 am by Andril
Go to the top of the page
Go to the bottom of the page

Andril
Magician
GroupMembers
Posts147
JoinedJun 9, 2009

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.
       
Post is unread #24 Feb 13, 2010, 7:49 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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.
       
Post is unread #25 Feb 14, 2010, 9:30 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

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).
       
Post is unread #26 Feb 14, 2010, 2:02 pm   Last edited Feb 14, 2010, 2:04 pm by Andril
Go to the top of the page
Go to the bottom of the page

Andril
Magician
GroupMembers
Posts147
JoinedJun 9, 2009

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!
       
Post is unread #27 Feb 14, 2010, 6:40 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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.
       
Post is unread #28 Mar 26, 2010, 11:39 am
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

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?
       
Post is unread #29 Mar 26, 2010, 7:57 pm
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

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.
       
Post is unread #30 Mar 27, 2010, 6:43 am
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

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.
       
Post is unread #31 Mar 27, 2010, 3:38 pm
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

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.
       
Post is unread #32 Mar 27, 2010, 7:00 pm
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

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
       
Pages:<< prev 1, 2 next >>