Preventing stack instances

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

I know that making new protected or private will (generally) prevent
instances from being created on the heap, but I was wondering about
preventing them on the stack.

I saw in another post a hint about protecting the destructor. As the
objects in question are all managed through a single smart pointer type
I suspect that something like the following should work:

class MyObjectPtr;

class MyObject { // There are manu sub-classes of this type
protected:
virtual ~MyObject();
friend MyObjectPtr;
};

class MyObjectPtr {
public:
~MyObjectPtr() {
delete object;
}
private:
MyObject *object;
};

[Example is really pseudo-code with anything not relevant just skipped]

Is this sufficient? Are there any 'gotchas' associated with this?

TIA


Kirit

 

[Alf P. Steinbach]

* Kirit Sælensminde:

I know that making new protected or private will (generally) prevent
instances from being created on the heap, but I was wondering about
preventing them on the stack.

I saw in another post a hint about protecting the destructor. As the
objects in question are all managed through a single smart pointer type
I suspect that something like the following should work:

class MyObjectPtr;

class MyObject { // There are manu sub-classes of this type
protected:
virtual ~MyObject();
friend MyObjectPtr;
};

class MyObjectPtr {
public:
~MyObjectPtr() {
delete object;
}
private:
MyObject *object;
};

[Example is really pseudo-code with anything not relevant just skipped]

Is this sufficient?

For the purpose of ensuring dynamic allocation, yes.

Are there any 'gotchas' associated with this?

Yes. A restriction to dynamic allocation is not very meaningful unless
it's exploited some way, which typically means that the objects will
participate in some linked data structure. When you restrict a class to
dynamic allocation you should therefore in general also take charge of
(or prevent) copying.

 

[Roland Pibinger]

I know that making new protected or private will (generally) prevent
instances from being created on the heap, but I was wondering about
preventing them on the stack.

I saw in another post a hint about protecting the destructor.

.... and the constructor(s)

As the
objects in question are all managed through a single smart pointer type
I suspect that something like the following should work:

class MyObjectPtr;

class MyObject { // There are manu sub-classes of this type
protected:
virtual ~MyObject();
friend MyObjectPtr;
};

you can create derived objects on the stack, e.g.
class MyObjectEx : public MyObject {};

class MyObjectPtr {
public:
~MyObjectPtr() {
delete object;
}
private:
MyObject *object;
};

[Example is really pseudo-code with anything not relevant just skipped]
Is this sufficient? Are there any 'gotchas' associated with this?

In contrast to Java, which is a heap-oriented language, C++ works best
as stack-oriented language. Even in your example the heap allocated
objects are managed by a stack-based "smart" pointer. You should avoid
heap objects as much as possible. They produce management and
performance overhead.

Best wishes,
Roland Pibinger

 

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

Yes. A restriction to dynamic allocation is not very meaningful unless
it's exploited some way, which typically means that the objects will
participate in some linked data structure. When you restrict a class to
dynamic allocation you should therefore in general also take charge of
(or prevent) copying.

Of course. Thanks. The class already derives from boost::noncopyable so
that's covered.

you can create derived objects on the stack, e.g.
class MyObjectEx : public MyObject {};

Thanks. It means that the person doing it is specifically circumventing
the protection though. As such I guess they will get everything they
deserve

In contrast to Java, which is a heap-oriented language, C++ works best
as stack-oriented language. Even in your example the heap allocated
objects are managed by a stack-based "smart" pointer. You should avoid
heap objects as much as possible. They produce management and
performance overhead.

C++ is not heap oriented? Ummm, Ok. That seems a peculiar view to take.

Of course on the matter of performance you cannot say, in general, that
stack or heap will be faster without measuring each. For some classes
heap will be faster, for others it will be faster on the stack. It all
depends on what the class is doing; how it is managing whatever
ancilliary memory/objects it controls; its own access pattern and its
create/destroy pattern.

Of course the 'management overhead' is exactly what I was asking about.


K