By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,389 Members | 1,878 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,389 IT Pros & Developers. It's quick & easy.

Preventing delete on a SmartPointer

P: n/a
Hi,

I have implemented a SmartPointer class following the implementation
proposed by Bill Hubauer(*). But I also override the operator * ()

template<class ObjectType>
class SmartPointer
{
public:
operator ObjectType * () const
{ return Pointer; }
....
private:
ObjectType* Pointer;
};

Now my compiler can compile:

SmartPointer<Object> s = new Object;
delete s;

Is there a way to prevent that ?

Thanks,
Mathieu

(*)
http://groups.google.com/group/comp....3ddc38a827a930

Full source code is at:
http://svn.sourceforge.net/viewcvs.c...ter.h?view=log

Jun 17 '06 #1
Share this Question
Share on Google+
15 Replies


P: n/a
In article <11**********************@h76g2000cwa.googlegroups .com>,
"mathieu" <ma***************@gmail.com> wrote:
Hi,

I have implemented a SmartPointer class following the implementation
proposed by Bill Hubauer(*). But I also override the operator * ()

template<class ObjectType>
class SmartPointer
{
public:
operator ObjectType * () const
{ return Pointer; }
...
private:
ObjectType* Pointer;
};

Now my compiler can compile:

SmartPointer<Object> s = new Object;
delete s;

Is there a way to prevent that ?


Yes. If you don't explicitly tell the compiler that this is allowed, it
won't allow it. That means remove the operator ObjectType*().
Jun 17 '06 #2

P: n/a
Daniel T. wrote:
SmartPointer<Object> s = new Object;
delete s;

Is there a way to prevent that ?


Yes. If you don't explicitly tell the compiler that this is allowed, it
won't allow it. That means remove the operator ObjectType*().


Of course that fix is the best style. (It's why the C++ Standard Library has
few if no conversion operators.)

But can't the templated class also provide an operator delete? Then it could
correctly zilch its owning pointer.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 17 '06 #3

P: n/a

Daniel T. wrote:
Yes. If you don't explicitly tell the compiler that this is allowed, it
won't allow it. That means remove the operator ObjectType*().


Well there is -at least- another way like defining the ~Object in the
protected section, but doing so would prevent me to define an Object on
the stack.
I thought there could be another way...

-M

Jun 17 '06 #4

P: n/a
* Phlip:
Daniel T. wrote:
SmartPointer<Object> s = new Object;
delete s;

Is there a way to prevent that ?

Yes. If you don't explicitly tell the compiler that this is allowed, it
won't allow it. That means remove the operator ObjectType*().


Of course that fix is the best style. (It's why the C++ Standard Library has
few if no conversion operators.)

But can't the templated class also provide an operator delete? Then it could
correctly zilch its owning pointer.


An 'operator delete' in SmartPointer would be used in an expression like

delete &s;

not in

delete s;
--
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?
Jun 17 '06 #5

P: n/a
On 16 Jun 2006 17:56:44 -0700, "mathieu" <ma***************@gmail.com>
wrote:
Daniel T. wrote:
Yes. If you don't explicitly tell the compiler that this is allowed, it
won't allow it. That means remove the operator ObjectType*().


Well there is -at least- another way like defining the ~Object in the
protected section, but doing so would prevent me to define an Object on
the stack. I thought there could be another way...


It's yet another "smart" pointers pitfall. Just don't use "smart"
pointers and the 'problems' are gone.

Best wishes,
Roland Pibinger
Jun 17 '06 #6

P: n/a
mathieu wrote:
Daniel T. wrote:
Yes. If you don't explicitly tell the compiler that this is allowed, it
won't allow it. That means remove the operator ObjectType*().


Well there is -at least- another way like defining the ~Object in the
protected section, but doing so would prevent me to define an Object on
the stack.
I thought there could be another way...

-M


Unfortunately you can't make your smart pointer completely fool-proof.
At the very least one can still do the following:

SmartPointer<int> sp(new int(1));
delete sp.operator->();

Ben
Jun 17 '06 #7

P: n/a
benben wrote:
mathieu wrote:
Daniel T. wrote:
Yes. If you don't explicitly tell the compiler that this is allowed, it
won't allow it. That means remove the operator ObjectType*().


Well there is -at least- another way like defining the ~Object in the
protected section, but doing so would prevent me to define an Object on
the stack.
I thought there could be another way...

-M


Unfortunately you can't make your smart pointer completely fool-proof.
At the very least one can still do the following:

SmartPointer<int> sp(new int(1));
delete sp.operator->();


Yes, and will all know how easily that accidentally happens :)

To shoot yourself in the foot with less typing do

delete &*sp;

Jun 17 '06 #8

P: n/a

override delete operatpr in your class and make it private .

Regards
Mangesh

Jun 19 '06 #9

P: n/a

override delete operatpr in your class and make it private .

Regards
Mangesh

Jun 19 '06 #10

P: n/a
mathieu wrote:
Hi,

I have implemented a SmartPointer class following the implementation
proposed by Bill Hubauer(*). But I also override the operator * ()

template<class ObjectType>
class SmartPointer
{
public:
operator ObjectType * () const
{ return Pointer; }
...
private:
ObjectType* Pointer;
};

Now my compiler can compile:

SmartPointer<Object> s = new Object;
delete s;

Is there a way to prevent that ?


IIRC, the reason it can delete that is because there is exactly one
operator that
returns a pointer-to-object. If you had a private operator void*, the
compiler couldn't
determine which pointer type to cast to. This is good; the only case in
which you
want operator ObjectType* to work is the case where you need an
ObjectType*.
If the conversion context is ambiguous, like 'delete s', the compiler
should tell
you about the ambiguity.

HTH,
Michiel Salters

Jun 19 '06 #11

P: n/a
mathieu wrote:
Hi,

I have implemented a SmartPointer class following the implementation
proposed by Bill Hubauer(*). But I also override the operator * ()

template<class ObjectType>
class SmartPointer ....
Now my compiler can compile:

SmartPointer<Object> s = new Object;
delete s;

Is there a way to prevent that ?


I may have missed something here. If you haven't overridden
delete then it won't do anything since s is just an object,
not a pointer to a dynamically allocated object, as far as
C++ is concerned. The object your smart pointer "refers" to
won't get deallocated unless your smart pointer implementation
decides to do so.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Jun 19 '06 #12

P: n/a
Roland Pibinger wrote:
It's yet another "smart" pointers pitfall. Just don't use "smart"
pointers and the 'problems' are gone.


Better yet, go back to assembly, and then all the manifold problems
with high level languages disappear!

JK

Cheers! --M

Jun 19 '06 #13

P: n/a

mathieu wrote:
template<class ObjectType>
class SmartPointer
{
public:
operator ObjectType * () const
{ return Pointer; }
...
private:
ObjectType* Pointer;
};

Now my compiler can compile:

SmartPointer<Object> s = new Object;
delete s;


1)
your object class should have only private constructors and one or more
public static methods returning a smartPtr.
2)
Or instead of the static method you could define a factory class which
creates instances of your class (by returning a smartptr).
3)
You could make the destructor of Object private so nobody can call
delete on your object pointer.
I assume that your smartPtr is calling Addref() and Release() or
something similar on your object to increase/decrease the reference
count of your object.

Jun 19 '06 #14

P: n/a

mathieu wrote:
Daniel T. wrote:
Yes. If you don't explicitly tell the compiler that this is allowed, it
won't allow it. That means remove the operator ObjectType*().


Well there is -at least- another way like defining the ~Object in the
protected section, but doing so would prevent me to define an Object on
the stack.
I thought there could be another way...

-M

But your are allowed to create an instance of smartPtr<Object> on the
stack.
I think your object should have only one lifetime philosophy --
reference counted with smart pointers or not.

Jun 19 '06 #15

P: n/a

mathieu wrote:
Daniel T. wrote:
Yes. If you don't explicitly tell the compiler that this is allowed, it
won't allow it. That means remove the operator ObjectType*().


Well there is -at least- another way like defining the ~Object in the
protected section, but doing so would prevent me to define an Object on
the stack.
I thought there could be another way...

-M

But your are allowed to create an instance of smartPtr<Object> on the
stack.
I think your object should have only one lifetime philosophy --
reference counted with smart pointers or not.

Jun 19 '06 #16

This discussion thread is closed

Replies have been disabled for this discussion.