Jump to content
  • Advertisement
Sign in to follow this  
SteveHatcher

Can someone please explain + example of 'ownership'

This topic is 1135 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

I am trying to understand 'ownership' in c++. This term keeps coming up when I google around trying to understand smart pointers, the explanations I mostly come across stress 'ownership'. Mostly the examples say something like "A owns B" use ... pointer, or if you need to share ownership, use ... pointer. I never understand what are A and B.. are they objects? if so what does it mean A owns B? Like some code example? Why would you ever 'share' ownership? etc etc...

 

In my self-learning of C++ (a book and learning game dev stuff using source code and hacking together my own 2d space shooting game)... I never really came across ownership (or maybe I do but just don't realize it). What it is? why its important?, what the rules are?, and most importantly why it matters for me when I am doing hobbiest game programming.

 

So can someone really break it down to an ultimate noob such as myself? And what of this do we need to take into considerations for 'Game Dev'.. e.g. a List of items? Player positions? Map loading..?

 

Thanks all

 

 

Share this post


Link to post
Share on other sites
Advertisement

A simple explanation of ownership can be seen like a cup class and liquid class : the cup owns the liquid.

That could be like that :

class Cup;

class Liquid
{
public:
  Liquid( Cup* Owner ) :
  m_Owner( Owner )
  {
  }

  Cup* GetOwner() const
  {
    return m_Owner;
  }

private:
  Cup* m_Owner;
}

Now you can get the owner from liquid to know what cup owns this liquid.

Edited by Alundra

Share this post


Link to post
Share on other sites
A and B could be anything. They could be objects. They could be a handle to an operating system resource. They could be an opaque type you need for interaction with a library.

Ownership and the proper definition of it is pretty much a core issue in software development. If you get ownership right a lot of problem sources are just gone.

You always have to deal with ownership (at least for non-trivial programs). In the simplest case whenever you 'new' something the immediate question you need to ask it: "and who does the 'delete' now?" (the 'when?' is also an interesting problem but usually just another facet of the same core issue).

Common problems if you don't get ownership right include:
  • memory leaks
  • freeing resources more than once
  • accessing resources after they have already already been freed
Finding the right ownership semantics for a problem is part of being an experienced developer. There is no 'The Solution', you need to look at your situation and weigh pros and cons of possible solution to arrive at ownership semantics.

For example if several models you are rendering use the same texture "rusty_metal_grate.png" it would be a waste to upload it for each model which needs it. They could all share it. So, instead of each model loading the texture from disk and uploading it to video memory they ask the AssetCache for it. The AssetCache either loads the texture from disk and instantiates it or returns an already existing instance. When a model is done with it, it does not destroy the texture (that would mean every other model using the texture is broken, most likely crashing the application when they next try to use it), it informs the AssetManager they no longer need it. In most cases the AssetManager will then just note down that the resource is used by one less user. Only if the last user releases the resource it could consider freeing it.

In other situations you explicitly don't want to share, for example because each owner wants to make modifications to a resource which could be contradictory. Or liable to race conditions because each owner lives in a different thread and you cannot/don't want to enforce some kind of synchronization.

You can fill whole topics of a book with discussions about the concept without exhausting it. In the context of C++ RAII is an important related subject as is the Rule of Three. It might also be a good idea to take a look at the standard library's std::shared_ptr and std::unique_ptr. Edited by BitMaster

Share this post


Link to post
Share on other sites

A simple explanation of ownership can be seen like a cup class and liquid class : the cup owns the liquid.
That could be like that :


class Cup;

class Liquid
{
public:
  Liquid( Cup* Owner ) :
  m_Owner( Owner )
  {
  }

  Cup* GetOwner() const
  {
    return m_Owner;
  }

private:
  Cup* m_Owner;
}
Now you can get the owner from liquid to know what cup owns this liquid.


That is not a useful example at all. None of the important bits can be gleaned from it. For the core concept of ownership the interesting part would be the definition of Cup. When is a liquid created? When is it destroyed? What happens when you copy a Cup? Are you allowed to copy a Cup? Can two Cup instances share the same Liquid?

Share this post


Link to post
Share on other sites
What you wrote was just an example of a relation between two classes you chose to call ownership (you could as well have called them 'holder' and lose even the extremely superficial relationship to the question). It has nothing to do with the questions asked by the OP which were about the core concept of software development. In most cases resources being owned by someone will not know who owns them (and not care about it at all).

Share this post


Link to post
Share on other sites

As I said, it was just a simple explanation to show the concept of ownership, I didn't go in details.

There are two types of ownership being answers here. You're describing ownership as in a parent/child relationship in an object hierarchy while BitMaster and Olof are describing ownership as in object lifetime management.

 

Object lifetime management has nothing to do with parent/child relationships but about when and how dynamic resources are released to avoid, for example, memory leaks when you forget to free on an allocated object.

Edited by Brother Bob

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!