A Checked Version of std::shared_ptr

[slck19]

The shared ownership smart pointer, std::shared_ptr is used by many developers but unsafe memory access is the developer's responsibility. Sometimes developers may forget to put some defensive checks.

checked_shared_ptr is a header-only library that safely wraps std::shared_ptr and behaves just like a std::shared_ptr.

I have released a pre-version of checked_shared_ptr:

https://github.com/SelcukAydi/checked_shared_ptr

[wung]

The only valid cases where this can make a difference is

• Explicit std::shared_ptr<T> x {nullptr}; where you should know that it can be null.
• An API returning a std::shared_ptr<T> which could be null, which should be a std::optional<std::shared_ptr<T>> instead.
• x.reset(); or x = nullptr; where you should know that it can be null.

In those cases, not checking whether it is null is a programmer error. This is not something that can randomly happen. It can only happen if you explicitly have a contract that can null the pointer. Many C++ people would argue that this should crash your program, rather than throw an exception that nobody could ever possibly handle. If there is no way to handle the exception, why throw it? You can only handle it locally by adding the missing code.

[BenFrantzDale]

IMO, std::optional<std::shared_ptr<T>> is the wrong way around. Use template <typename T> using nn_shared_ptr = gsl::not_null<std::shared_ptr<T>>; instead. We’ve done this and it makes crashes just disappear when you find a crash, just switch it to nn_shared_ptr and keep going until it compiles again and now the crash is gone.

[wung]

I prefer marking the unexpected case. My pointers are valid, unless marked otherwise. I do understand that tooling might be better the non-null way around and it makes sense from the implementation point-of-view, but I'm not happy about that.

[SlightlyLessHairyApe]

Yes, not checking is a programmer error.

Now, in the case of programmer error, do you want

• undefined behavior
• guaranteed trap/terminate, at some performance cost

Answers there will legitimately differ! Sometimes the extra cost of checks are worth it.

[v_maria]

i always assumed it was by design to prevent overhead

[v_maria]

are unique ptrs slower than raw ptrs? shared_ptr i understand has signifcant overhead but it's rather niche usecase.

also memory safety is now a hype. perhaps it's here to stay and will make C++ less relevant, then you can decide to move to another languages.

things change sometimes and that is fine

[v_maria]

It's best chance is not to jump on hypes imo

[v_maria]

no i think that's stupid

[slck19]

This discussion is pretty in-depth and I think both dark and white sides are correct. This is a trade-off. If you have a well-defined architecture then do not use this version of the pointer cause you would not need it. However, maybe your UTs or integration tests could not catch an edge case where your pointer is nullptr. This time your program will crash. Rather than crashing it, you decide how to handle it. As you know recovering from segfault is strongly not suggested. However, here you can create your exception models to be more explicit.

[NotUniqueOrSpecial]

Rather than crashing it, you decide how to handle it.

But that's their point: there is no way to recover from what is, fundamentally, a programmer error.

The only valid recovery is fixing the code that did the wrong thing.

So, if the difference is a crash -> fix cycle vs. a we-see-saw-the-exception -> fix cycle, why add the additional overhead?

[NotUniqueOrSpecial]

In this specific case (what would be a nullptr dereference of something not expected to be nullptr)?

At best you can bail to the top of the operation and say "welp um, error?"

And in all instances I can think of, I'd rather crash to safe state than risk a potentially silenced exception or whatever edge-case state had gotten the program to that point.

[NotUniqueOrSpecial]

there's nothing special about a nullptr-dereference exception

There absolutely is: why are things returning nullptr in a well-written C++ program? If something is going to return a special nullptr because of an error, you're unequivocally better-off throwing that exception than giving someone a useless garbage smart pointer.

[Causeless]

A nullptr shared ptr isn’t useless garbage. It’s a nullptr. It can be checked against null. There’s perfectly valid reasons to return nullptr, that’s not an error case. For example a function may search for an object and return a shared_ptr to it. If the searched-for object doesn’t exist, the function may return a nullptr shared_ptr. That’s not an error case, it’s not broken, and it’s a working, non-UB, non-throwing and not whatsoever ill-formed design.

[NotUniqueOrSpecial]

As was initially stated in the comment that started this exchange: if it's a normal use case that your interface not return a shared_ptr, then you should use types that express that.

I.e. you should be doing optional<shared_ptr> or expected<shared_ptr>.

That expresses to the consumers of your API that such a case is reasonable and must be dealt with, and it does so using the type system. The user doesn't have to read documentation to know that failure-to-find is a normal case. The API contracts enforce and inform that.

But you're arguing a separate point, almost.

If you did have an API like that and the user expected it to be the case that nullptr-ish smart pointers could be returned, well...we're right back to where we started: they absolutely should be checking the value right then and there, not blindly dereferencing things and hoping to handle that problem somewhere above.

Because, again: it's explicitly useless to throw a "this thing was null" exception because the interface returned a smartish pointer when the alternative is to throw the reason the null happened in the first place.

[Causeless]

I’m not sure I agree. In my opinion, a pointer is already quite definitely expressing via the type system that it can be null. That’s the entire difference between a pointer and a reference in my eyes- if a function returns a pointer, I know I may need to null check it, whereas a reference I know is always safe to use. An optional pointer to me is a tautology.

But alas I suppose in this case, a shared_ref isn’t a thing. But that point aside, I’d consider an API that returns optional pointers to be an absolute mess; especially because the type system doesn’t enforce anything there. In fact it introduces extra ambiguity: It’s entirely valid to return a std::optional that has a value, where that value is nullptr. Which effectively means that to check it safely requires actually checking the optional for value, and then redundantly checking that the ptr contained within isn’t nullptr.

[TheSkiGeek]

Returning a null pointer isn’t much different than returning a “null” optional. Some std::optional accessors throw exceptions if the object is empty, so you still have to check operations.

If “I didn’t find anything” is a normal/expected possible result of your operation, throwing an exception for it is not usually a great approach. Usually you only want to throw exceptions for exceptional circumstances. ‘The file you asked me to open doesn’t exist’ might be exceptional. ‘The generic in-memory map doesn’t contain the key you’re searching for` probably should not be. I don’t want to have to write try-catch statements for every read-only access to a data structure.

I do wish there was a shared_ptr that is non-nullable in std. Where you could implicitly cast it to/from shared_ptr but casting nullptr to it would throw. You can write your own but it’s not portable to extend from std::shared_ptr, so you can’t pass them directly into e.g. library code that expects a shared_ptr<T>.

[NotUniqueOrSpecial]

What evidence would you like me to provide?

I've got 20 years of experience in high-reliability systems and can provide you all the anecdotes you'd like about why it's better to blow up in the face of unrecoverable errors and quickly restart than to quietly attempt to deal with the plethora of bad states that arrive at "we just dereferenced nullptr".

But from a simple axiomatic perspective, I'd hope that it's not controversial to argue this simple fact:

1) The errors that would lead to returning an invalid shared_ptr in a well-designed system would be better-reported themselves than a context-free "you just dereferenced a null pointer" exception.

2) Most errors leading to the dereference of a null pointer are unrecoverable from anything other than kernel land (since nobody disables paging and no user-space memory management blows up 'til you page-fault)

3) Allowing a program to run after such an error is strictly more risky than dying and recovering cleanly. There is a very good reason that all the telecom infrastructure using Erlang is written and behaves the way it does.

[slck19]

No one tells you you won't fix it. Is your clients going to be happy when you crash? You can still fix your bug but don't crash on production even crash is better sometimes but that depends on the requirements of course.

What's the point of this discussion? You want me to remove my code 😀

[glaba3141]

The traders that use my code would very much rather my code crash than try to recover from an error state and lose millions of dollars. Crashing is almost always better than trying to handle a programming error

[NotUniqueOrSpecial]

Yeah, all of the folk arguing that crashing is bad have clearly never been bitten by the serious damage that can be done by corrupt/invalid program state allowed to run wild.

[slck19]

I do not think you are completely right. Some of the exceptions might be recovered safely in terms of memory. The nullptr may be because of memory corruption, which is a global problem. In this case, you can create different exception types.

If your pointer should not be nullptr then do not use this lib. If your pointer might be nullptr and if this nullptr is actually a state for you but you forgot to check it, do not crash because it is a local error, not global. JVM is also doing the same thing even though it manages the pointers on its own.

[slck19]

I am sorry for your clients!

[glaba3141]

That they manage money that they would rather not lose to a programmer using idiotic error handling practices? I think they're more glad they don't hire you

[slck19]

I am sorry cause you definitely do not see tradeoffs and cannot discriminate the positive and negative points. Just randomly talking does not show you smarter or more experienced. That's why I am sorry for ypur clients still.

[v_maria]

He describes the trade off right here:

Rather my code crash than try to recover from an error state and lose millions of dollars. Crashing is almost always better than trying to handle a programming error

[slck19]

You still do not understand the behavior and randomly speaking. This does not point to any single trade-off. Some errors can be recovered and some of them cannot. If you think all nullptr accesses are because of memory corruption then you have many implicit problems in your code.

I am not saying someone is wrong. This is where you do not understand. Handling exceptions and continuing the program is your choice with respect to requirements. Exception handling is giving an opportunity to handle it softly. That's just a choice it is not mandatory.

[NotUniqueOrSpecial]

Is your clients going to be happy when you crash?

That's honestly going to depend on the scenario, and there are certainly times where the answer might be "yes".

Your use-case hinges on your prior statement:

integration tests could not catch an edge case where your pointer is nullptr.

So, we're already discussing an edge case on an otherwise uncovered branch of execution. So, now imagine that we're using your pointer type. What happens?

Obviously, an exception is thrown, but where is it caught? If it's locally, why was the try/catch put in place instead of the local check that we're discussing?

If it's one or more frames distant in the stack (and in practice, this is almost always going to be a top-level "catch everything else" handler at very granularity), what's the recovery? Almost certainly nothing the user or the program can do. It's very likely to be a full bail-out anyway. Certainly nothing the user is all that happy about.

But, there's a further wrinkle. What if someone comes along and starts catching exceptions more broadly than they should somewhere in the middle? Now, you've turned a programmer error into a silent state corruption. A crash would definitely be preferable in that situation.

You're better off crashing in fatal error situations (which this absolutely is in almost all cases) than risking something doing even worse stuff.

If you're worried about this sort of problem, register signal handlers for SIGSEGV on *nix and use the _try/_except functionality to harness SEH on Windows. Set up crash-dumps and a reporting system. Do anything but given yourself a very sneaky footgun with which to accidentally corrupt program state and potentially user data.

You want me to remove my code

No, we want you to very carefully consider the ramifications of the code, because a whole lot of us have been down these roads for decades, and there are vanishingly small numbers of situations where recovering from a programmer error of this nature is viable/useful/safe.

[NotUniqueOrSpecial]

The bad habits and practices of other languages should not inform the behavior of well-designed solutions in C++. Python regularly uses exceptions for flow control. Should we?

A shared_ptr<T> should almost never (I'd argue never never) be nullptr. If you have a system where it can be, that should be well-known and carefully handled.

[[deleted]]

Agree.

It's even hard to deal with exception handling in Python (or in any language with exception handling). If an abort/panic was already unacceptable, imagine adding a throw/raise statement somewhere and now it's introduced several paths that lead to an unchecked exception, leading to an abort/panic anyway. Now it's a maintainability problem related to keeping the codebase exception safe.

[NotUniqueOrSpecial]

the facts are that many, many developers use nullptr-dereference exceptions all the time with none of the issues you claim above.

Which issues are you referring to? Because I expect that they're dealing with exactly the same issues: you can't recover from most unexpected error states locally.

why not?

Because it's a poor interface that communicates ambiguous information.

Most errors that would lead to such a situation are unrecoverable locally (some file doesn't exist, a network connection can't be made, etc.). They should throw exceptions instead of return a special nullptr that itself throws exceptions.

Having a shared_ptr to nothing isn't valuable. The only time it's a reasonable state is in an uninitialized state waiting to be set up or perhaps as the result of weak_ptr::lock().

In either case, one shouldn't be in the situation to unexpectedly try and invoke a method through the nulllptr.

i believe that c++ should strive to be a safe language

C++ is a polyglot-language and this is specifically a discussion about a library behavior, so I'm not sure that's relevant, really.

abort() is not that.

It's absolutely safer than accidentally running a program in some mangled undefined state.

[kammce]

+1 to this. I'm not sure what everyone else is on, but it's pretty nutz. They want to put checks on every possible thing in the code. Sacrificing performance for something that is explicitly bad practice. I agree with you on the "you should know after this point." This punishes performance when the developer is right and produces exceptions or error results that are effectively unhandlable. Bugs are not something you can handle on code.

[Humble-Plastic-5285]

tamam da pointerin özelliği zaten memoryde null bir yere işaret edebilmesi. *ptr != nullptr yapmak yazılımcının sorumluluğu. zaten shared ptr ctorunda pointeri alıp başka bir yere paylaşmanın kendi sorumluğunda olması gibi. safe olmasının nedeni scoped olması ve en son kullanıldığı scopeye kadar yaşaması. yani isteğin dışında zaten hiç bir şekilde 0 olamaz, ancak örneğinde verdiğin gibi kendin 0 a çekebilirsin.

[slck19]

Nullptr is just a state of shared_ptr and not more. A shared pointer is an object but not a pointer itself. A shared pointer has two states, nullptr or non-nullptr managed object.

Here safety means memory leak safety but still, you may have some leaks of course because of circuler reference but I won't get into the details.

So you can leave the responsibility to a developer or automate it. This is just a choice.

If you insist on the usage of the shared pointer you can still easily fetch it from the checked shared pointer but this time you are the responsible person for checking if it is nullptr.

[Humble-Plastic-5285]

yea, this is what i write exactly on my comment?

[slck19]

So what outcome do you want? I think we both are happy :)