[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.
Later,
Scott MacMaster
Other related posts:
