On Friday, July 25, 2025, Julien Villemure-Fréchette wrote:

>
> To prevent double deletes, refrain from using dynamic allocation and
> create objects directly with value or move semantics, otherwise use
> unique_ptr for ownership of polymorphic types. Otherwise, use raw pointer
> to express "access to" an object from an outer scope without owning it (raw
> pointers should never be deleted if used for this purpose, see
> CppCoreGuidelines).
>



I first used unique_ptr around about the year 2002. We spelt it differently
back then though, something like "auto_ptr" if I remember. I remember
waiting aaagggeeesss for C++11 to come out.

The company I work for, purchased another company a few months ago. All of
the other company's products are now ours.

We have our own Software Development Kit (SDK) going back to the 1990's,
it's very C-ish but it works and it's fast. The guy who wrote it died a
year or two ago. The other company has an SDK too, but theirs is much more
C++-ish.

A handle returned by our SDK can be used simultaneously by multiple
threads. A handle returned from their SDK is restricted to just one thread.

So I'm now tasked with writing an adapter library to put our interface on
their library. Some of our SDK features don't map well at all to their SDK,
and the mismatch in multi-threading has to be accommodated, but hey I need
to get the job done.

I told my boss that the adapter library is going to be an inefficient mess
since the SDK's are so different, but I promised to make the nicest, most
performative mess I could.

So I've got raw pointers being passed around, mutexes being dynamically
allocated in constructors, and destructors locking mutexes before deleting
a pointer and then unlocking and deleting the mutex. (Although I might go
find/write an implementation of std::map that allows T to be
uncopyable-and-unmovable, meaning the mutex doesn't need to be dynamically
allocated -- but I'll cross that bridge when I come to it).

I can use "unique_ptr" for the dynamically-allocated mutex but not for the
handle returned from the other SDK because the former must out-live the
latter, and both are member variables in a struct called "MappedHandle".
(Yes I 'move' from the unique_ptr perimortem).

With all this madness going on, I want as much help as possible from the
debugger and from the compiler to spot when something's wrong. I've got
0xdeadbeefdeadbeef written a few places in my code, because I want a
segfault instead of a "delete nullptr" which will go unnoticed.

You're right though, sometimes my 'deadbeef' will be overwritten in places.

The best thing in the world though, even better than zero-calorie
caffeine-free Coca Cola, is Address Sanitizer. My programs tend to be
pretty bullet-proof and I owe it primarily to using Address Sanitizer when
debugging (and the DEBUG macroes for libc and libstdc++).

When I think I have this adaptor library working, I'm going to use a cross
compiler to build it for 32-Bit Big Endian ARM, and then I'm going to run
it in a chroot jail using Qemu. If it's still works then I'm probably good.

But yeah in a perfect world where ice cream is always whipped and children
are always laughing and none of the old people have arthritis, I'd go with
unique_ptr and forget about all this 0xdeadbeef stuff.

I think C++ could do with std::badptr_t and badptr though.