Always create the object in heap?

[Karthik]

In a recent techincal interview on C++, I came across this strange
question....

How to ensure that your class object is always created in heap (by a
new operator)? The compiler should throw error, if the object is
created in stack.

Note:- Dont hide the construtor.

Is it possible?

 

[Alf P. Steinbach]

* Karthik:

In a recent techincal interview on C++, I came across this strange
question....

How to ensure that your class object is always created in heap (by a
new operator)? The compiler should throw error, if the object is
created in stack.

Note:- Dont hide the construtor.

Is it possible?

A short answer is to make the destructor inaccessible.

But there are details, e.g. how to allow to 'delete', and then how to
ensure the client code uses smart pointers (if that is desirable).

See section 1.1.3 and following sections of <url:
http://home.no.net/dubjai/win32cpptut/special/pointers/ch_01.pdf>.

 

[Frederick Gotham]

Karthik posted:

In a recent techincal interview on C++, I came across this strange
question....

How to ensure that your class object is always created in heap (by a
new operator)? The compiler should throw error, if the object is
created in stack.

Note:- Dont hide the construtor.

Is it possible?

I think they do something like the following. (I don't know how to get it
to compile...):

class MyClass {
private:

~MyClass() {}

public:

void operator delete(void *const parg)
{
::delete static_cast<MyClass*>(parg);
}
};

int main()
{
MyClass *const p = new MyClass;

delete p;
}

 

[Alf P. Steinbach]

* Frederick Gotham:

Karthik posted:



I think they do something like the following. (I don't know how to get it
to compile...):

class MyClass {
private:

~MyClass() {}

public:

void operator delete(void *const parg)
{
::delete static_cast<MyClass*>(parg);
}
};

int main()
{
MyClass *const p = new MyClass;

delete p;
}

No, 'operator delete' is a deallocation function, not an override of the
keyword 'delete'. See the reference I gave elsethread. Even if it was
written by myself... ;-)

 

[mlimber]

In a recent techincal interview on C++, I came across this strange
question....

How to ensure that your class object is always created in heap (by a
new operator)? The compiler should throw error, if the object is
created in stack.

Note:- Dont hide the construtor.

Is it possible?

See this FAQ:

http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.21

It hides the constructor, but that is the most common way to do it.
It's silly to leave the constructor public but have it throw a run-time
error. Always prefer compile-time errors when you can get them.

Cheers! --M

 

[fungus]

class MyClass {
private:

~MyClass() {}

public:

void operator delete(void *const parg)
{
::delete static_cast<MyClass*>(parg);
}
};

It would be good if you called the destructor
inside operator delete.


--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again. They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful. But it happens
every day. I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

 

[Howard]

* Karthik:

A short answer is to make the destructor inaccessible.

But there are details, e.g. how to allow to 'delete', and then how to
ensure the client code uses smart pointers (if that is desirable).

See section 1.1.3 and following sections of <url:
http://home.no.net/dubjai/win32cpptut/special/pointers/ch_01.pdf>.

I take it you mean section 1.3.3?

-Howard

 

[Howard]

See this FAQ:

http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.21

It hides the constructor, but that is the most common way to do it.
It's silly to leave the constructor public but have it throw a run-time
error. Always prefer compile-time errors when you can get them.

I don't see your point. The requirement was that the "compiler should throw
error, if the object is created in stack", which means a compile-time error.

-Howard

 

[Frederick Gotham]

fungus posted:

It would be good if you called the destructor
inside operator delete.

Does the global operator delete not do that?

(I don't know much about overloading "new" and "delete"... I don't think I've
ever overloaded them.)

 

[Victor Bazarov]

fungus posted:



Does the global operator delete not do that?

It should. Any overloaded operator delete is the *deallocation* function,
not the "delete operator" that is supposed to destroy the object and
then deallocate. It's a case of bad naming, but "delete operator" calls
"operator delete". What we are allowed to overload is the latter, not
the former.

(I don't know much about overloading "new" and "delete"... I don't
think I've ever overloaded them.)

Nothing to it, really.

V

 

[Frederick Gotham]

Victor Bazarov posted:

Nothing to it, really.

Any decent tutorials on the net?

Any time I look for a programming tutorial on the net, I get some programming
magazine article written by a pretentious, poor programmer. It can hard to
sort the good stuff from the bad stuff if you don't know the subject
material.

 

[fungus]

It should.

My bad.


--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again. They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful. But it happens
every day. I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

 

[Alf P. Steinbach]

* Frederick Gotham:

Victor Bazarov posted:



Any decent tutorials on the net?

See the reference I gave elsethread.

More generally, see the FAQ item "What other "newbie" guides are there
for me?", currently at <url:
http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.21>.

 

[mlimber]

I don't see your point. The requirement was that the "compiler should throw
error, if the object is created in stack", which means a compile-time error.

Mea culpa. I missed the word "compiler" in concentrating too much on
the word "throw."

In any case, I think the factory function approach is preferable over
the private destructor approach since there are fewer things to
remember and more forward compatibility (e.g., what if auto_ptr is
deprecated and replaced with unique_ptr as Howard Hinnant has
proposed?).

Cheers! --M