Improve exception safety with smart pointers about typesense HOT 4 CLOSED

@elfring I'm generally a fan of smart pointers as raw pointers can become hard to manage. In this case, however I refrained from wrapping for a couple of reasons:

1. Parts of Typesense initially began as a C project, and still uses some C-style code so those parts just used raw pointers.
2. To a lesser extent, I was worried about the performance overhead introduced (admittedly this is more of a case for shared_ptr than unique_ptr) in hot loops. I did do some initial benchmarks where I saw some serious degradation.

In the end, instead of adopting a mixed style, just ended up not using it anywhere. To detect and prevent leaks, we have an integration test suite (which is not part of this repo) that's run under Valgrind.

from typesense.

How do you think about to improve the implementation of the member function “array::remove_index” (for example)?

from typesense.

@elfring I'm sorry for going silent on this thread. We're comfortable with using raw pointers as of today, given the heavy interoperability with the C libraries we're using. We might relook this at future. Thanks for bringing this up though!

from typesense.

The interoperability concerns do not matter for affected C++ classes.
Under which circumstances will you start to care for exception safety?

from typesense.