[openbeos] Re: [OT] Re: Pointer or reference?

  • From: "Scott MacMaster" <scott@xxxxxxxxxxxxxxxxxx>
  • To: <openbeos@xxxxxxxxxxxxx>
  • Date: Thu, 1 Apr 2004 21:54:25 -0500

----- Original Message ----- 
From: "Steve Folta" <steve@xxxxxxxxx>
To: <openbeos@xxxxxxxxxxxxx>
Sent: Thursday, April 01, 2004 3:12 AM
Subject: [openbeos] Re: [OT] Re: Pointer or reference?

> "Scott MacMaster" <scott@xxxxxxxxxxxxxxxxxx> wrote:
> > If an object deletes itself then that applies [sic: implies?] that the
> > object is the owner of itself.  In c++ programs this is never.  Thus an
> > object in c++ should never delete itself.
> This is wrong.  The concept of ownership is not even expressible in C++.
> So there are no constraints on who can own whom.  Certainly an object can
> own itself.  As someone else pointed out, a reference-counted object can
> be considered self-owning -- and that's a well-known idiom that can even
> be found in Stroustrop.

It is true that c++ doesn't have syntax for specifying ownership.  However,
every object has an owner.  A reference-counting object is not a c++
construct.  It, of course, can be similated and withen the simulation there
is ownership.  Also, even a reference-counting object, I feel, must be owned
by something else and is not truely self-owning.

> I created a language where ownership *was* expressed, and was the basis of
> all memory management.  But I never got it fully working well, and in the
> end I ripped it out and put in a garbage collector.
> >> This is also why creating objects on
> >> the stack is incorrect. An automatic (stack) variable can only be
> >> accessed from the thread that created it.
> >
> > That's definitely wrong.  I'm certain I've accessed the stack from a
> > seperate thread.  In any case, I decided to run a test program.  I
> > initialized a int to 10 in one thread, later I displayed and changed the
> > value in another thread, the back in the first thread I displayed the
> > value again.  Everything worked perfectly and as expected.
> It can be done, but it requires very careful synchronization of the
> threads.  I'd consider it a bad practice.

Right, that is a bad practice.

Scott MacMaster

Other related posts: