• 9
• 16
• 15
• 12
• 9

# Keeping Ptr/Reference Differences Clean

This topic is 2520 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello!

In my game engine design, I'm trying to figure out the best way to deal with the differences between pointers and references. For example, I write many functions that take some object as a reference, and oftentimes it is convenient to pass in just a reference. But then, sometimes I have a resource that is dynamically-constructed, so I have a pointer and end up having to pass in a dereferenced pointer, which is annoying. So I often end up creating a second version of the function that takes a ptr and just does the dereferenced-pointer-call automatically.

As you can imagine, it looks rather nasty to have two versions of every function that must take something by reference. So I considered a different technique: allow certain objects to automatically cast themselves to pointers to themselves. That way, the compiler would automatically do the cast when it saw that the function takes an Object* and I'm handing it just an Object. Of course, there's no doubt in my mind that this is bad practice. It just sounds like bad practice.

Any advice on how to cleanly solve this problem?

##### Share on other sites
Posted · Hidden
Hidden
Hmm looks like the implicit cast isn't even an option; I thought I could do it by writing an operator Type*(){return this;}, but the linker complains.

So I'm stumped on how to solve this

I have a pointer and end up having to pass in a dereferenced pointer, which is annoying.

Any advice on how to cleanly solve this problem?
It's not a problem. Dereferencing a pointer to use it as a reference is normal.

You're auto type-conversion definitely is bad practice and will come back to bite you in the arse later.

Also your two-overload solution rubs me the wrong way too --- when I use an API that has some functions that take references, and other functions that take pointers, then I assume the pointer-taking functions will accept NULL as a valid argument. If you're going to dereference a user-supplied pointer, you should at least assert that it's not NULL first.
If a NULL isn't a valid input for a function I'm writing, then I choose to use a reference type as the input so that the user has to perform the (dangerous, potentially crash-causing) dereference operation themselves.

Some suggestions to make it less 'annoying' though -- (A) try using a 'p' prefix on pointer variables so there's an obvious difference between them and references, and also (B) try dereferencing in advance to a local reference variable.Widget* m_pDynamicallyAllocated; ..... void DoStuff() { //A assert( m_pDynamicallyAllocated ); Frobnicate( *m_pDynamicallyAllocated ); //B assert( m_pDynamicallyAllocated ); Widget& dynamicallyAllocated = *m_pDynamicallyAllocated; Frobnicate( dynamicallyAllocated ); }

##### Share on other sites

But then, sometimes I have a resource that is dynamically-constructed, so I have a pointer and end up having to pass in a dereferenced pointer, which is annoying.

This is quite normal (the technique, not the annoyance).