Jump to content
  • Advertisement
Sign in to follow this  
Angelic Ice

I doubt I understand RAII just yet

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

Hello dear forum! I have a question concerning RAII.

 

First let me try to word it myself: RAII is the concept of wrapping up resources that shall be deleted once they go out of scope.

This "wrapper" then deletes the resource when it goes out of scope.

Especially because I cannot guarantee that I delete it myself, the risk of screwing this seems quite big.

Though I'm a bit sceptical about this. I should know what object exists and should know how to clean it up - even RAII seems to have flaws, this gives me quite a headache.

 

Is the resource management this hard? For now, I never ran into severe issues nor can I prove that there never were any dead memory entries.

 

However the way I clean up is probably not the idomatic way and less reliable than the RAII-concept.

 

Now taking a look at the implementation, which gets quite a bit difficult for me. Mainly looked at the Wikipedia article:

https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Resource_Acquisition_Is_Initialization

 

I would need one object that auto deletes my other resource. Let's say I have a class which contains multiple objects and quite some pointers.

 

I would avoid everything but smart pointers, is this already a part of the RAII concept?

Would I need to wrap an autodelete class around every object that the object owns (including itself)? Or should I simply put the object that is owning the other objects into the autodelete?

As the owner might live way longer than their owned objects, I probably want to free the memory earlier (when the destructor of the owned objects is being called). Which would let me tend to my first idea.

These all might be a wrong perception of mine. Is that even the right way of handling RAII?

 

When the first example in the wiki writes:

lock.acquire();
lock.release();

I totally have no idea what this does in that place. What does it mean? It probably has to do with freeing the memory but I hardly can grasp around its functionality.

Though I know about the release() of pointers, I see no pointer being used here which stands in a relationship to this.

 

Another question that jumps into my head is the scopedLock part. Is this another idiom?

 

My last question is about when to use RAII and when not. Whenever I browse through other C++ code, I doubt I ever saw it being explictly used as in the Wikipedia article.

Does this mean there are better or different implementations?

 

I would be really happy if someone could explain this to me, because I want to know how I can implement RAII myself.

It gets quite frustrating on how many idioms there are, it feels like bad practise to program C++ in the first place unless I know all idioms and design patterns..

Edited by Angelic Ice

Share this post


Link to post
Share on other sites
Advertisement
Like always, I wouldn't implement it for the idea. If you have good resource management and no issues, it's good to know it's possible but not necessary to implement.

Share this post


Link to post
Share on other sites
While I did not downvote you nor do I know the mind of the person who did, I kinda agree with the vote.

Your advise feels like bad advise. RAII is so fundamental to working in C++, if you do not have a solid grasp on it you should strive to remedy that situation as soon as possible. The reason for not using RAII should be <well-reasoned rationale> not 'nah, never had to use it before'.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!