Sign in to follow this  

Objects vs Structs in a C++ Linked List

This topic is 4712 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi again I have another theoretical question about OO in C++. Those of you who remember, I had some issues with OO design about a month back and the replies here really sorted out a few things. I have moved to C++ now and i can see benefits when it comes to code organization, so thanks for that. Now I have another question which is also a little bit related to engine design. I have a situation where I have a list linked list of objects (lets say monsters). They can be dynamically created and destroyed whilst the engine is running, which means inserting and deleting from the linked list, and they can also have properties modifed which means finding them in the list and altering their internal data values. In C I would have created a linked list with a head node that contains a head and tail pointer which pointed to the first and last node in the linked list. Each node would be a dynamically created "typedef struct monster_t" for example. Functions would exist in the code to navigate the linked list to find, create and destroy nodes and alter the values inside the monsters structs (like x,y,z position). Now here is the C++ part. Rather than make each node in the linked list an instance of a struct, I could make it an object, and have all of the function code for modifying the properties (getters and seters for example) of the monsters and even their behavior in the object. The head node of the linked list could contain the code for removing and adding nodes to the linked list. This would be good OO design. Now my question is: wouldnt the OO method of using classes rather than structs be wasteful of memory resources? If there were 25 monsters in the level that were identical and each had a object node in the linked list, wouldnt there be 25 copies of the exact same functions existing in memory at the same time? With a struct, you only store data, which can be unique to each monster (like x,y,z position), even if the monsters are the same species for example. But by using a class you are including the same identical functions for each one. Does there exist a way for several objects of the same class to "point" to single instances of functions that are common between them (a function equivalent of a class variable i think)? Maybe this is just another example of a tradeoff and something that the programmer has to use judgement about at the time of designing the engine. I was considering storing brushes in my editor as objects in a linked list each with getters and setters and such relevant functionality, but i am not sure this would be the best way in the engine itself where geometry needs to be memory efficient and so i might just use structs for data and keep functions seperate. Any ideas or thoughts? Thanks for the help.

Share this post


Link to post
Share on other sites
Methods of an objects are stored only once too.

Internally object methods are "normal" functions with an implicit (=nonvisible) this pointer.

For example:


class CDog
{
public:

void Bark( const std::string& strText = "Woof" );
};


For the programmer it looks like


void Bark( const std::string& strText );



Internally it looks like


void Bark( CDog* pDog, const std::string& strText );



That enables the linker/compiler to only store one instance of a function, regardsless how many objects of that class actually exist. So there is no extra memory consumption in a list by using objects.

Share this post


Link to post
Share on other sites
Personally, I don't know about the waste of memory resources, we'll have to wait for someone who knows more to answer that question.

But, I will give you a couple of things: First off just so you know, the keywords 'struct' and 'class' are practically interchangable in C++. So, you can have functions in a struct, although, personally, because of C, I'm used to them being data containers, so, for me its just usually a constructor.

Second, I recommend that you use the STL template list, instead of having your own linked list. I tried this and when I started using the STL list, I was kicking myself for not starting with it earlier.

No, I don't think that there is a way where multiple objects of a type can point to a single instance of a member (inside the class) function for that object.

I know that you can declare a member function as 'static', but that means that you can't call it from an object.




class A
{
void func1();
static void func2();
};

int main()
{
A obj1;

obj1.func1();

A::func2();

return 0;
}




Because func2 was declared 'static', it can't be called from an object, it must be called like this: "A::func2()".

If anyone thinks that I'm wrong, please correct me, because I'm not definite on some of these things.

Share this post


Link to post
Share on other sites
Endurion answered your main question, but I thought I might add that although your description is sufficient, even better design would be to make a linked list class that could be reused for all sorts of data or object types. Plus, instead of having a head node, and a bunch of nodes after it, the link list as a whole could be represented as one object, and the nodes inside it as a different type of (sub)object.

For an example of this, or for everyday use for just about anything other than learning and experimentation, look at the STL's list, found in <list> (no ".h"). You declare a linked list as so: "std::list<CMonster> m_Monsters;" And then you go through the elements of the list by using iterators. An iterator basically indicates a node.
std::list<CMonster>::iterator iMonster;
for (iMonster = m_Monsters.begin(); iMonster != m_Monsters.end(); ++iMonster)
std::cout << iMonster->Name();

Iterators are in effect like pointers, but support the ++ operator, sometimes the -- operator, and in some cases general addition and subtraction, for containers such as std::vector<>.

Share this post


Link to post
Share on other sites
Haha its that simple, C++ already does store just one instance of the functions (well I guess the original designers were clever so I should not be surprized). That gets rid of alot of my concerns about using OO in parts of my program. Thanks Endurion!

I have to say I am starting to like OO over proceedual more and more. I am going to stay away from the STL for the time being, but i will probably end up regretting it as people have said...still its good practice!

Again thanks for the responces...its time to do some designing of my data structures.

Share this post


Link to post
Share on other sites
Quote:
Original post by Agony
Endurion answered your main question, but I thought I might add that although your description is sufficient, even better design would be to make a linked list class that could be reused for all sorts of data or object types. Plus, instead of having a head node, and a bunch of nodes after it, the link list as a whole could be represented as one object, and the nodes inside it as a different type of (sub)object.
Thats probably a good idea actually. I tend to be terrible with code reuse and my previous terrain/mesh engine was full of link lists, but they were all created in seperate parts of the code. THis is something i should work on.

Share this post


Link to post
Share on other sites
Quote:
Because func2 was declared 'static', it can't be called from an object, it must be called like this: "A::func2()".

If anyone thinks that I'm wrong, please correct me, because I'm not definite on some of these things.


You are correct in that the static method can be called by using " classname::func()", but it can still be called from an object, all it means is that you do not have to access that method via an object.

Share this post


Link to post
Share on other sites

This topic is 4712 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this