Why implement DB connection pointer object as a reference counting pointer? (C++)

Question

At our company one of the core C++ classes (Database connection pointer) is implemented as a reference counting pointer. To be clear, the objects are NOT DB connections themselves, but pointers to a DB connection object.

The library is very old, and nobody who designed is around anymore.

So far, nether I, nor any C++ experts in the company that I asked have come up with a good reason for why this particular design was chosen. Any ideas?

It is introducing some problems (partially due to awful reference pointer implementation used), and I'm trying to understand if this design actually has some deep underlying reasons?

The usage pattern these days seems to be that the DB connection pointer object is returned by a DB connection manager class, and it's somewhat unclear whether DB connection pointers were designed to be able to be used independently of DB connection manager.

Answer 1

Probably it's a mistake. Without looking at the code it's impossible to know for sure, but the quality of the reference-counted pointer implementation is suggestive. Poor design, especially around resource management, is not unheard of in the C++ community</bitter sarcasm>.

With that said, reference-counted pointers are useful when you have objects of indeterminate lifetime which are very expensive to create, or whose state needs to be shared among several users. Depending on the underlying architecture, database connections could fit this definition: if each database connection needs to authenticate over the global internet, say, it could easily be worth your trouble to save a single connection and reuse it, rather than making new connections and disposing of them as you go.

But if I've understood you correctly, you don't have a single database connection object with a collection of refcounted pointers pointing to it. Rather, you have a database connection object, a collection of ordinary pointers to it, and a collection of refcounted pointers to those pointers. This is insanity, and almost certainly the result of confused thinking by the original developers. The alternative is that it was an act of deliberate evil, e.g. to ensure job security. If so they must have failed, as none of the perpetrators still work for your company.