Programming

21023 readers

290 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

[email protected]

Modern C++ — RAII (green7ea.github.io)

submitted 3 weeks ago by [email protected] to c/[email protected]

7 comments fedilink hide all child comments

top 7 comments

sorted by: hot top controversial new old

[–] [email protected] 4 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

What I find interesting is that move semantics silently add something to C++ that did not exist before: invalid objects.

Before, if you created an object, you could design it so that it kept all invariants until it was destroyed. I'd even argue that it is the true core of OOP that you get data structures with guaranteed invariants - a vector or hash map or binary heap never ceases to guarantee its invariants.

But now, you can construct complex objects and then move their data away with std::move() .

What happens with the invariants of these objects?

[–] [email protected] 3 points 2 weeks ago (1 children)

Depends on the object what happens when they are moved from. Some objects are put into a valid moved from state (usually depends on if doing so is free or required anyway. For example to satisfy the invariant of the moved to unique pointer the moved from pointer needs to be set to nullptr in order to prevent the moved tos unique pointer being deleted from underneath it)

[–] [email protected] 1 points 2 weeks ago (1 children)

So what do you do with a file object?

[–] [email protected] 1 points 2 weeks ago

Douno off the top of my head. To take a wild guess they might just wrap a file handle and give it s nice api? If that's what they do then moving from the file zeros out he handle for basically the same reason smart pointers set their internal pointer to nullptr, so they don't delete it (or close the file in this case) underneath the new object.

[–] [email protected] 1 points 2 weeks ago

According to cppreference:

Unless otherwise specified, all standard library objects that have been moved from are placed in a "valid but unspecified state", meaning the object's class invariants hold (so functions without preconditions, such as the assignment operator, can be safely used on the object after it was moved from)

I would expect this to be true of all types. An easy way to do this is to null an internal pointer, set an internal fd to a sentinel, etc and check for that when needed, but this could be an easy source of errors if someone's not paying attention.

Ideally it would be statically checked if a value is used after being moved, but that's just my Rust brain speaking.

[–] [email protected] 4 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

This is 14 years old by now - hardly "modern". RAII itself is even older.

[–] [email protected] 2 points 2 weeks ago

100% agree. But I like posting articles like these because it brings me back to how I learned programming, and Linux specifically - namely by reading a bunch of articles from similar link aggregators and sharing sites.

My hope is that sharing articles like these is a form of planting the seeds for another cycle for people to learn the way that I did.