C++ Q: Constructor Hiding

[Tower]

My Google-fu is failing me, or (more likely) I'm not asking the question correctly.

You can get pretty specific with Constructor hiding; one thing I'm curious about is forcing the user to instantiate your object on the heap (as a pointer) rather than the stack.

I'm comfortable with hiding the default Constructor, and Copy Constructor, and even overloading operators (such as equals, '=') to block (as a Copy Constructor). Now I'd like to learn more.

Beyond this, any other tips/tricks anyone would like to share about Constructors and hiding?

 

[Tawnos]

Sounds like you're asking about a form of the Factory or Singleton pattern - rather than an outside class being able to construct directly, require them to call a public static method which returns a pointer to the created object.

Is there something else you need help with/do you have a more specific question?

 

[mikeblas]

Right -- you want a factory with a wrapper class. It's a bit of a dodge; since the caller needs access to the created class, you've either got to do a lot of rapping (even more than Jay Z) or you'll "leak" access to the class you're trying to protect.

Why is it that your class must be instantiated on the heap? You don't instantiate objects as pointers; you access objects with pointers, BTW.

You can get started with something like this:

class COnlyHeap
{
	int m_nPayload;
	COnlyHeap( int n ) : m_nPayload( n )
	{
	}
	
	
	COnlyHeap( const COnlyHeap &ref )
	: m_nPayload ( ref.m_nPayload )
	{
	}

	COnlyHeap & operator = (const COnlyHeap &)
	{
		assert( false );
	}
public:

	static COnlyHeap *CreateOne( int n )
	{
		return new COnlyHeap( n );
	}
	
	COnlyHeap *CreateFromThis()
	{
		return new COnlyHeap( *this );
	}
};

 

[Tower]

Thanks to you both for the answers.

Triple Edit: The purpose of this question was to determine how I could force users to place large objects on the heap rather than the stack, when I believe that the object will be huge and could lead to stack-related problems (like blowing it.) So a factory/wrapper pattern is the only way to do so? I'm rather surprised by that. I would've thought the language facilitated a more simple way of saying, "Hey, this is gonna be a big object, and you aren't allowed to stick it on the stack for that reason."

 

[mikeblas]

There's no explicit way to demand a particular allocation class. C++ doesn't force any mechanism about the object's usage -- any class could be instantiated as a temporary object or an object that lives the whole length of the program.

The issue falls back to your design of the object; why is it so large? Instead of having many members (or many small members, or whatever), why isn't it getting its allocation from the heap, internally?

 

[Tower]

You raise a good point, in that while my class might be huge, internally it could allocate memory on the heap, and thus solve it's own problem.

There is no specific problem, it's hypothetical for my own understanding. You've cleared that up for me. Even in cases where an object has a lot of internal data structures, by default, most of them (that are of any size) will be on the heap (strings, arrays, etc.) and rather than forcing a user to place your object on the heap, you can internally handle it.

Good point, and thanks for that.