If I have 2 variables, A and B, referencing the same object and then do a
A.Dispose(), what happens to B?

Hi y'all.

After looking in to this, I better elaborate.

I have a control object. It operates it 2 modes:

A. It can display itself. The display handled by a control display
manager.

B. It can be utilized without being displayed.

Now, the situation I am confused about is as follows:

A. I instantiate such a object.
B. I give it to the control manager to display.
C. When the user is done, the control manager (which keeps a reference to
the control in a stack) disposes of its copy.
D. However, the class that instantiated the control in the first place
wants to keep the object present for additional reference.

What happens to the original object after the control manager disposes of
its version?

Thanx,
Bill

Another add on.

When the control manager pops a control from its stack, it does a dispose on
that reference.

Now, if instead, it simply popped the reference without doing the dispose
and then over wrote the stack entry with another control, does the over
written entry get dereferenced.

ie

Stack control A at index 0
Stack control B at index 1
Stack control C at index 2
Pop index 2 - actually, do nothing, hust decrement to top of stack pointer.
Stack control D at index 2

Is C recognized as no longer being referenced or is a dispose manditory?

web1110 wrote:
> Hi y'all.
>
> After looking in to this, I better elaborate.
>
> I have a control object. It operates it 2 modes:
>
> A. It can display itself. The display handled by a control display
> manager.
>
> B. It can be utilized without being displayed.
>
> Now, the situation I am confused about is as follows:
>
> A. I instantiate such a object.
> B. I give it to the control manager to display.

This would seem to be the critical point.

Are you giving it a reference (handle) to the object or the object itself?


> C. When the user is done, the control manager (which keeps a reference to
> the control in a stack) disposes of its copy.
> D. However, the class that instantiated the control in the first place
> wants to keep the object present for additional reference.
>
> What happens to the original object after the control manager disposes of
> its version?
>
> Thanx,
> Bill
>
>

re your question, I am assigning the object itself.

I call the control manager with

CLControlManager.vdDisplayControl(theControl);

In CLControlManager, I save the control with

ControlStack[ix]=thePassedCotrol;

"John Bailo" <(E-Mail Removed)> wrote in message
news:Mlp%d.17103$(E-Mail Removed)...
> web1110 wrote:
> > Hi y'all.
> >
> > After looking in to this, I better elaborate.
> >
> > I have a control object. It operates it 2 modes:
> >
> > A. It can display itself. The display handled by a control display
> > manager.
> >
> > B. It can be utilized without being displayed.
> >
> > Now, the situation I am confused about is as follows:
> >
> > A. I instantiate such a object.
> > B. I give it to the control manager to display.
>
> This would seem to be the critical point.
>
> Are you giving it a reference (handle) to the object or the object itself?
>
>
> > C. When the user is done, the control manager (which keeps a reference
to
> > the control in a stack) disposes of its copy.
> > D. However, the class that instantiated the control in the first place
> > wants to keep the object present for additional reference.
> >
> > What happens to the original object after the control manager disposes
of
> > its version?
> >
> > Thanx,
> > Bill
> >
> >

You question makes no sense.

You always pass around references to objects - you cannot pass an object by value.

As far as the OP's question is concerned you have entered a world of pain that IDisposable does not cope with. For IDisposable to work correcctly there has to be a strong notion of ownership of the object. You only have four options really:

1. Decide who is going to take responsibility for calling Dispose and stick to that architecturally
2. Let the finalizer talke care of releasing resources and don't call Dispose at all
3. Implement some form of reference counting architecture where everone "releases" their reference (calling a method) and then the object Disposes itself when the refcount goes to zero.
4. Clone the object before its passed to the controller so they each have an independent copy they can Dispose

As you can see, none of these is enormously attractive and some may be unsuitable for you architecture

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

web1110 wrote:
> Hi y'all.
>
> After looking in to this, I better elaborate.
>
> I have a control object. It operates it 2 modes:
>
> A. It can display itself. The display handled by a control display
> manager.
>
> B. It can be utilized without being displayed.
>
> Now, the situation I am confused about is as follows:
>
> A. I instantiate such a object.
> B. I give it to the control manager to display.

This would seem to be the critical point.

Are you giving it a reference (handle) to the object or the object itself?


> C. When the user is done, the control manager (which keeps a reference to
> the control in a stack) disposes of its copy.
> D. However, the class that instantiated the control in the first place
> wants to keep the object present for additional reference.
>
> What happens to the original object after the control manager disposes of
> its version?
>
> Thanx,
> Bill
>
>

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 18/03/2005



[microsoft.public.dotnet.languages.csharp]

"Richard Blewett [DevelopMentor]" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
> You question makes no sense.
>
> You always pass around references to objects - you cannot pass an object
> by value.
>
> As far as the OP's question is concerned you have entered a world of pain
> that IDisposable does not cope with. For IDisposable to work correcctly
> there has to be a strong notion of ownership of the object. You only have
> four options really:
>
> 1. Decide who is going to take responsibility for calling Dispose and
> stick to that architecturally

Doable but very error prone.

> 2. Let the finalizer talke care of releasing resources and don't call
> Dispose at all

The object may not get cleaned up for a long time, which may cause
unanticipated side effects.


> 3. Implement some form of reference counting architecture where everone
> "releases" their reference (calling a method) and then the object Disposes
> itself when the refcount goes to zero.

You can use a wrapper class that implements the reference counting (isn't
that what an rcw does?).

> 4. Clone the object before its passed to the controller so they each have
> an independent copy they can Dispose

That might be enormously expensive and may not even work (depends on what
the classes contain).

As a general approach I prefer option 3 - hide the object behind a wrapper
class. It all depends on the object itself and the application around it. I
don't think a single approach will solve all problems.

Agreed, thats why I said he has entered a world of pain.

and 3) is the best approach if you can guarantee not to get circular references. Although I do think 2) has merit if there really is no strong notion of ownership - granted all the issues about finalizers - but sometimes only the CLR has a real idea of when something can be cleaned up.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk


"Richard Blewett [DevelopMentor]" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
> You question makes no sense.
>
> You always pass around references to objects - you cannot pass an object
> by value.
>
> As far as the OP's question is concerned you have entered a world of pain
> that IDisposable does not cope with. For IDisposable to work correcctly
> there has to be a strong notion of ownership of the object. You only have
> four options really:
>
> 1. Decide who is going to take responsibility for calling Dispose and
> stick to that architecturally

Doable but very error prone.

> 2. Let the finalizer talke care of releasing resources and don't call
> Dispose at all

The object may not get cleaned up for a long time, which may cause
unanticipated side effects.


> 3. Implement some form of reference counting architecture where everone
> "releases" their reference (calling a method) and then the object Disposes
> itself when the refcount goes to zero.

You can use a wrapper class that implements the reference counting (isn't
that what an rcw does?).

> 4. Clone the object before its passed to the controller so they each have
> an independent copy they can Dispose

That might be enormously expensive and may not even work (depends on what
the classes contain).

As a general approach I prefer option 3 - hide the object behind a wrapper
class. It all depends on the object itself and the application around it. I
don't think a single approach will solve all problems.

"Richard Blewett [DevelopMentor]" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
> Agreed, thats why I said he has entered a world of pain.

Agreed in spades. I avoid sharing managed objects for that reason - one
class "owns" a resource and serializes or otherwise manages access to it.

>
> and 3) is the best approach if you can guarantee not to get circular
> references. Although I do think 2) has merit if there really is no strong
> notion of ownership - granted all the issues about finalizers - but
> sometimes only the CLR has a real idea of when something can be cleaned
> up.
>

Very true.

I use a pattern where if there is either a Dispose or a finalizer I use both
unless. The only deviation is when there are thousands of objects and using
a finalizer would swamp the finalization queue (i.e. performance would
suck). I treat the Dispose interface as a contract, and if the client does
not call Dispose before the finalizer gets called I treat that as a program
error. Of course, this requires a strong degree of ownership, which brings
me back to my first principle - one object owns the resource.

regards,
Dave

Richard Blewett [DevelopMentor] wrote:
> You question makes no sense.
>
> You always pass around references to objects - you cannot pass an object by value.


void test (object o)
{
object = Int32(5);
}


void test2()
{
object o = Int32(7);
test(o);

//so what is the value of o at this point? 7 or 5 ?

}

http://www.c-sharpcorner.com/Code/20...llswapwork.asp

"C# does manipulate objects by reference, and all object variables are
references. On the other hand, C# does not pass method arguments by
reference; it passes them by value, (even if the method arguments are of
reference type)."