possibility to forbid use of "this"?

[Ernst Murnleitner]

Dear Readers,

Is it possible to forbid conversion from this or use of this in general
except where it is explicitly wanted?

Reason:

I changed my program from using normal pointers to classes A, ...

typedef A * APtr;

to a shared pointer

typedef boost::shared_p tr<A> APtr;

Now, it crashes because of statements like this

// call
DoSomething(thi s);

.....
// implementation
void DoSomething(APt r a)
{
// do nothing with a
}

Obviously, "this" is converted to a shared ptr locally. Outside the function
DoSomething() the shared ptr is destroyed and hence it tries to delete the
class where "this" points, too. This is clearly not wanted.

Greetings,
Many thanks in advance

Ernst

[tom_usenet]

On Wed, 7 Jan 2004 14:53:45 +0100, "Ernst Murnleitner"
<mu******@awite .de> wrote:

Dear Readers,

Is it possible to forbid conversion from this or use of this in general
except where it is explicitly wanted?

Reason:

I changed my program from using normal pointers to classes A, ...

typedef A * APtr;

to a shared pointer

typedef boost::shared_p tr<A> APtr;

Now, it crashes because of statements like this

// call
DoSomething(th is);

....
// implementation
void DoSomething(APt r a)
{
// do nothing with a
}
That shouldn't compile - the constructor of shared_ptr taking a T* is
explicit, so a pointer can't implicitly convert to a shared_ptr.
Obviously, "this" is converted to a shared ptr locally. Outside the function
DoSomething( ) the shared ptr is destroyed and hence it tries to delete the
class where "this" points, too. This is clearly not wanted.

You have a few choices, depending on what DoSomething does. If
DoSomething doesn't hold onto a reference to a, then you can change it
to:

void DoSomething(A& aref)
{
}

If it does hold onto a reference to a, but you know it will release
that reference before a is destroyed (which you probably can't
guarantee), then you could do:

struct null_deleter
{
void operator()(void const *) const
{
}
};

//...

DoSomething(APt r(this, null_deleter()) );

The safe approach is to make a shared_ptr from the this pointer. This
is only possible if the A object was created as a shared_ptr in the
first place. Follow the instructions here:
http://www.boost.org/libs/smart_ptr/...html#from_this

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Ron Natalie]

"Ernst Murnleitner" <mu******@awite .de> wrote in message news:bt******** ****@ID-130107.news.uni-berlin.de...

Obviously, "this" is converted to a shared ptr locally. Outside the function

DoSomething() the shared ptr is destroyed and hence it tries to delete the
class where "this" points, too. This is clearly not wanted.

shared_pointer( T*) isn't declared explicit? Seems like it ought to be.

[Ernst Murnleitner]

> That shouldn't compile - the constructor of shared_ptr taking a T* is

explicit, so a pointer can't implicitly convert to a shared_ptr.

With gcc 2.95 it compiles:

// -------------------------------------
#include <iostream.h>

#include <stdlib.h>

#include <boost/shared_ptr.hpp>

class A;

typedef boost::shared_p tr<A> APtr;

class A {

public:

A(){};

virtual ~A(){};

virtual void f(){func(this); };

void func(APtr p) {cout << "func(APtr) " << std::endl;};

};

int main(int argc, char *argv[])

{

A a;

a.f();

return EXIT_SUCCESS;

}

// -------------------------------------

[Ernst Murnleitner]

"Ron Natalie" <ro*@sensor.com > schrieb im Newsbeitrag
news:3f******** *************** @news.newshosti ng.com...

"Ernst Murnleitner" <mu******@awite .de> wrote in message

news:bt******** ****@ID-130107.news.uni-berlin.de...

Obviously, "this" is converted to a shared ptr locally. Outside the

function DoSomething() the shared ptr is destroyed and hence it tries to delete the class where "this" points, too. This is clearly not wanted.

shared_pointer( T*) isn't declared explicit? Seems like it ought to be.

At least with the old gcc 2.95 it need not! But I tried it with gcc 3.3 also
and at least there was the expected error.

(I still use the gcc 2.95 as the gcc 3.3 needs 20times longer for certain
source files).

Greetings
Ernst

[tom_usenet]

On Wed, 7 Jan 2004 16:46:03 +0100, "Ernst Murnleitner"
<mu******@awite .de> wrote:

That shouldn't compile - the constructor of shared_ptr taking a T* is
explicit, so a pointer can't implicitly convert to a shared_ptr.

With gcc 2.95 it compiles:

That's a shame - you should upgrade. It suspect it fails with all of
the compilers I have (GCC 3.2, Comeau C++ 4.3, VC 7.1, VC 6?), since
it is non-standard.

With this change:
#include <iostream.h>
to
#include <iostream>
using namespace std;

Comeau gives this error:

"main.cpp", line 22: error: no suitable constructor exists to convert
from
"A *" to "boost::shared_ ptr<A>"
virtual void f(){func(this); };

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Chris Theis]

"Ernst Murnleitner" <mu******@awite .de> wrote in message
news:bt******** ****@ID-130107.news.uni-berlin.de...

"Ron Natalie" <ro*@sensor.com > schrieb im Newsbeitrag
news:3f******** *************** @news.newshosti ng.com...

"Ernst Murnleitner" <mu******@awite .de> wrote in message news:bt******** ****@ID-130107.news.uni-berlin.de...

> Obviously, "this" is converted to a shared ptr locally. Outside the function DoSomething() the shared ptr is destroyed and hence it tries to delete the class where "this" points, too. This is clearly not wanted.

shared_pointer( T*) isn't declared explicit? Seems like it ought to be.

At least with the old gcc 2.95 it need not! But I tried it with gcc 3.3

also and at least there was the expected error.
The library now contains a enable_shared_f rom_this<>() function. You might
look up http://www.boost.org/libs/smart_ptr/sp_techniques.html

(I still use the gcc 2.95 as the gcc 3.3 needs 20times longer for certain
source files).

However, I´d recommend using gcc 3.3 and you probably might want to go
through your code for unnecessary compile time dependencies.

Regards
Chris

[Ernst Murnleitner]

>

The library now contains a enable_shared_f rom_this<>() function. You might
look up http://www.boost.org/libs/smart_ptr/sp_techniques.html

I found this just before. Now I wonder if it is possible to use

shared_from_thi s();

during construction of an object. I want to use it in the base class and
only store it in a std::vector. It would be used only after complete
construction but is needed during construction, as childs are constructed
from withing the constructor of the parent. The childs eventually get a
pointer to the parent for later use.

Greetings

Ernst

[Chris Theis]

"Ernst Murnleitner" <mu******@awite .de> wrote in message
news:bt******** ****@ID-130107.news.uni-berlin.de...

The library now contains a enable_shared_f rom_this<>() function. You might look up http://www.boost.org/libs/smart_ptr/sp_techniques.html

I found this just before. Now I wonder if it is possible to use

shared_from_thi s();

during construction of an object. I want to use it in the base class and
only store it in a std::vector. It would be used only after complete
construction but is needed during construction, as childs are constructed
from withing the constructor of the parent. The childs eventually get a
pointer to the parent for later use.

Greetings

Ernst

Could you give an explicit code example of what you want to do, please
because creating childs within the ctor of a base sounds very much like
flawed design to me. But I would need to see some code. Anyway, if I
understand your description correctly then there should be no problem.
Still, you should test it as I´ve not used shared_from_thi s() so far.

Regards
Chris

[Daniel T.]

"Ernst Murnleitner" <mu******@awite .de> wrote:

Dear Readers,

Is it possible to forbid conversion from this or use of this in general
except where it is explicitly wanted?

Reason:

I changed my program from using normal pointers to classes A, ...

typedef A * APtr;

to a shared pointer

typedef boost::shared_p tr<A> APtr;

I would call the above a bad idea. Not just because of the problem
cited, but because there is no way, in general to guarantee that all
APtr's in the original code actually point to things that must be
deleted at some point in the future. For example:

typedef A* APtr;

void foo( APtr a ) { }

int main() {
A myA;
foo( &myA );
}

is quite valid until you change the typedef...

Now if you can guarantee that all of the things held by an APtr have
actually been newed, then using a SmartPointer class that has some sort
of global way of knowing the number of references would be OK.

Of course, you still have the problem that some places in the code may
be using an A* rather than an APtr. :-(