468,491 Members | 2,009 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,491 developers. It's quick & easy.

Always create the object in heap?



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?

Aug 8 '06 #1
13 6954
* 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>.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Aug 8 '06 #2
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;
}

--

Frederick Gotham
Aug 8 '06 #3
* 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;
}
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... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Aug 8 '06 #4
Karthik wrote:
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-lit...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

Aug 8 '06 #5
Frederick Gotham wrote:
>
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

Aug 8 '06 #6

"Alf P. Steinbach" <al***@start.nowrote in message
news:4j************@individual.net...
>* 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>.
I take it you mean section 1.3.3?

-Howard
Aug 8 '06 #7

"mlimber" <ml*****@gmail.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
Karthik wrote:
>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-lit...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


Aug 8 '06 #8
fungus posted:
Frederick Gotham wrote:
>>
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.

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.)

--

Frederick Gotham
Aug 8 '06 #9
Frederick Gotham wrote:
fungus posted:
>Frederick Gotham wrote:
>>>
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.


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[s] 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Aug 8 '06 #10
Victor Bazarov posted:
>(I don't know much about overloading "new" and "delete"... I don't
think I've ever overloaded them.)

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.

--

Frederick Gotham
Aug 8 '06 #11
Victor Bazarov wrote:
>>It would be good if you called the destructor
inside operator delete.

Does the global operator delete not do that?

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

Aug 8 '06 #12
* Frederick Gotham:
Victor Bazarov posted:
>>(I don't know much about overloading "new" and "delete"... I don't
think I've ever overloaded them.)
Nothing to it, really.


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>.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Aug 8 '06 #13
Howard wrote:
"mlimber" <ml*****@gmail.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
Karthik wrote:
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-lit...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.
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

Aug 8 '06 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by sonu | last post: by
2 posts views Thread by Susan Bricker | last post: by
4 posts views Thread by sandeep | last post: by
5 posts views Thread by Atmapuri | last post: by
3 posts views Thread by Michael | last post: by
reply views Thread by NPC403 | last post: by
3 posts views Thread by gieforce | last post: by
reply views Thread by theflame83 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.