Thread: Ban pointers or references on classes?

Originally Posted by brewbuck

I can imagine no way to prevent creation of references in C++. To prevent creation of instances, use a private constructor.

I'm talking about creating new instances on the heap, not on the stack. Making the constructor private will make it impossible to create the object at all.

If the language makes it so difficult to achieve X, perhaps achieving X is not a good idea.

Perhaps. If there's no easy, achievable way, it's not the end of the world.

Originally Posted by iMalc

Unfortunately there are a number of things that simply become necessary when dealing with anything that is shared amoung threads. For example, altering the refcount of the smart pointer can no longer be done with a simple refCount++. You have to use InterlockedIncrement, a CriticalSection, or something like that. You also start needing to use the 'volatile' keyword.
For refcounting you perhaps already need to use the 'mutable' keyword if you write const-correct code.

Yes indeed to thread safety. I've guarded all public functions with a critical section if thread class safety is enabled.

Originally Posted by iMalc

Yes if you've made AddRef and Release (or whatever you called them) private, which is fine, then you would quite possibly need some other way of dealing with passing to a thread.

There is no AddRef for a obvious reason and you can Delete (say you don't need the memory any longer) which decrements the ref count, which is public. Only the copy constructor increments the ref count. That is, when a new copy of the variable is created.
Of course, you can always assign another pointer (wrapper by the class of course) to another, in which case it will copy the reference counter over, as well (plus increasing by one).

Originally Posted by iMalc

You'll find that most smart pointer classes allow some way of transferring ownerhip through calls to or from functions that can't take a smart pointer, such as by having a Attach and Detach functions. External functions such as CreateThread that do not let you pass the type of object you want by value are precisely when you need such things. Using Attach and Detach instead of direct calls to the objects AddRef and Release methods tends to mean cleaner and exception-safe code.
btw AddRef, Release, Attach and Detach are just the names of functions used with COM objects and CComPtr, which I use on a daily basis.

This actually gave me an idea. Perhaps it's possible to create a static map within the memory manager (so it's shared between all copies of the class) to keep track of the address of the reference counter. That way, it can lookup a pointer and thus find the reference counter and increase it.
Wow, that will even make it possible to assign a raw pointer directly.

Originally Posted by iMalc

So, what owns the instance of that class in the smart pointer? The best answer I can give is that its ownership is shared amoung all things that are responsible for decrementing the refcount when they're done with it, and have not yet done so.
Ownership = Responsibility to delete.

Indeed. Only all functions can only tell the class they no longer want the memory, so no function really has the responsibility to delete the memory. As long as the reference counter is correct, you can call Delete() anywhere you want, whenever you want, and it will be safe to do so.

Well the thing you've been asking all along (thread title) is simply not possible in any way. The only way to ban using the things you mention with your smart pointer class, is to ban your smart pointer class and start using ones already written by the experts instead!

Banning references is not possible, you say, but banning pointers is possible.

Originally Posted by iMalc

Not quite...
A static member function of that class can be used as a factory method for creating and returning instances of the class. Or of course, adding another class as a friend will work.
It's not what you want to do though I imagine.

I'll think about that... That would make it impossible to create an object that isn't exposed through methods.

I'm tired of discussing the pitfalls and bad ins or outs of this matter.
If there is any way someone can think of, then I'm interested. I want to try and see what happens.

Originally Posted by Elysia

I'm tired of discussing the pitfalls and bad ins or outs of this matter.
If there is any way someone can think of, then I'm interested. I want to try and see what happens.

It doesn't look like there is any way to block references the way you can with pointers.
The only way I could imagine doing it would be by overloading the object reference operator, but as you'll see from this code (if you compile & run it), it doesn't work:

Code:

#include <iostream>

using namespace std;

class NoRefs
{
public:
	NoRefs() { cout << "NoRefs constructor called." << endl; }
	~NoRefs() { cout << "NoRefs destructor called." << endl; }
	void Print( const char* str ) const { cout << str << endl; }

private:
	operator NoRefs&();
	operator const NoRefs&() const;
};


void CRefFunc( const NoRefs& ref )
{
	ref.Print( "In CRefFunc()" );
}

void RefFunc( NoRefs& ref )
{
	ref.Print( "In RefFunc()" );
}

void ValFunc( NoRefs val )
{
	val.Print( "In ValFunc()" );
}

int main()
{
	NoRefs obj;

	ValFunc( obj );
	RefFunc( obj );
	CRefFunc( obj );

	return 0;
}

Yeah, I believe I've already tried that.

Originally Posted by CornedBee

You can't block creating pointers either. You can just make it more difficult. But even if you hide operator &, I can use the addressof macro (in Boost) to obtain a valid pointer, and then safely cast it back to your type:

Code:

weird_type wt;
weird_type *pwt = static_cast<weird_type *>(addressof(wt));

Well, at least I can make it hard for people without using asm or workarounds.

Originally Posted by Elysia

Well, at least I can make it hard for people without using asm or workarounds.

Now, there's a difference between preventing the user from hurting himself accidentally, and deliberately getting in the way. Trying to absolutely forbid the taking of a pointer is ultimately impossible and is basically a pointless arms-race with the user programmer. Put some orange traffic cones around the hole in the road -- no need to guard the area with a robot army.

Yes, it is. I might as well try it for myself, and if anyone else might want it, I could just block the most important things that can make things go wrong and put warnings lights saying the behaviour is not intended or might produce undefined behaviour.

Originally Posted by CornedBee

Still, in the end, your example use case comes down to trying to use a thread-affine object from multiple threads.

Unless there are more examples.

Originally Posted by CornedBee

Forbidding references and pointers is not the way to make thread-affine objects safe.

Already been mentioned several times.

Originally Posted by CornedBee

What it achieves is preventing the (useful) use of references and pointers. (One example: if your smart pointer is thread-safe, then copying has the thread-safe reference counting overhead. If you want to avoid that, you could pass the smart pointer by reference within any single thread, which is perfectly safe and faster than copying it.)

You have a point, but I designed the class to be thread safe or not. User choice. If no thread security is done, it's faster and not needed on multiple threads.
You might have a point in passing by reference if it's thread safe and multiple threads, of course, but I don't like the idea that another function will be using the memory without increasing the ref counter.

Originally Posted by CornedBee

To enforce thread affinity, you need to check thread affinity. Basically, in the debug version of your program, the smart pointer should grab the executing thread's ID on construction and assert() on every dereference that the executing thread's ID is the same as the one taken on construction. That is (assuming N2320 C++ threading):

That's another excellent idea! I will add checks if the class is put to not be thread safe is the creating thread is actually trying to access the object.

UPDATE:
I actually thought of something else that might put references at risk.
One is calling Delete() from a function:

Code:

void foo(pp<int>& pTest)
{
	// ...
	pTest.Delete(); // Oops, decrements the reference count and destroys the memory.
	// ...
}

int main()
{
	ppnew<int> pTest;
	foo(pTest);
	int n = *pTest; // Oops, access violation, pTest == NULL
	// ...
}

Another reason why passing by reference might not always be such a good idea. I know this is stupid and you should probably (or maybe) assign cost, but anyway, here goes:

Code:

void foo(pp<int>& pTest)
{
	pTest = newpp(new int, false); // newpp(T* p, bool bArray); // NOT INTENTIONAL! Supposed to be used locally, but isn't due to being passed by reference.
	*pTest = 1;
}

int main()
{
	ppnew<int> pTest(0);
	int n = *pTest; // n == 0
	foo(pTest);
	int n = *pTest; // n == 1
}