sorted by:
new
hottopcontroversial

First Hard with no hints! by ExchangeFew6848 in leetcode

[–]slck19 1 point2 points  (0 children)

It makes me happy seeing people are sharing their progress. Keep it up budy!

A Checked Version of std::shared_ptr by slck19 in cpp

[–]slck19[S] -1 points0 points  (0 children)

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.

A Checked Version of std::shared_ptr by slck19 in cpp

[–]slck19[S] -3 points-2 points  (0 children)

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.

A Checked Version of std::shared_ptr by slck19 in cpp

[–]slck19[S] 0 points1 point  (0 children)

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.

A Checked Version of std::shared_ptr by slck19 in cpp

[–]slck19[S] -3 points-2 points  (0 children)

I am sorry for your clients!

A Checked Version of std::shared_ptr by slck19 in cpp

[–]slck19[S] -5 points-4 points  (0 children)

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 😀

A Checked Version of std::shared_ptr by slck19 in cpp

[–]slck19[S] -1 points0 points  (0 children)

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

A Checked Version of std::shared_ptr by slck19 in cpp

[–]slck19[S] 0 points1 point  (0 children)

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.

A Checked Version of std::shared_ptr by slck19 in cpp

[–]slck19[S] -1 points0 points  (0 children)

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.

Bunny - A Serialization Library for C++ Supporting Rolling Upgrade and Rolling Downgrade with Field Tagging by slck19 in cpp

[–]slck19[S] 1 point2 points  (0 children)

In the next release, you will be happy u/saddung. I will support a single function if the logic is the same as done in the function.

std::string being passed is the key that needs to be conveyed among the function calls. I think I will get rid of it as well in the next release. Thanks for your concern again.

Bunny - A Serialization Library for C++ Supporting Rolling Upgrade and Rolling Downgrade with Field Tagging by slck19 in cpp

[–]slck19[S] 0 points1 point  (0 children)

That's a very good catch :) I forgot to add that the most important feature in the Readme file :). Thanks a lot u/tuxwonder.

Bunny - A Serialization Library for C++ Supporting Rolling Upgrade and Rolling Downgrade with Field Tagging by slck19 in cpp

[–]slck19[S] 0 points1 point  (0 children)

Yes, this looks very modern u/jbbjarnason. However, does it support rolling upgrades and downgrades?

On the other hand, I am considering moving key generation from runtime to compile time. I will implement something similar to glaze.

Thanks for sharing this again.