If I have 2 variables, A and B, referencing the same object and then do a
A.Dispose(), what happens to B?
29  2263 
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" <ja*****@earthlink.net> wrote in message
news:Ml*******************@newsread1.news.pas.eart hlink.net... 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]" <ri******@NOSPAMdevelop.com> wrote in
message news:u7*************@TK2MSFTNGP12.phx.gbl... 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]" <ri******@NOSPAMdevelop.com> wrote in
message news:u7*************@TK2MSFTNGP12.phx.gbl... 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]" <ri******@NOSPAMdevelop.com> wrote in
message news:OT**************@TK2MSFTNGP10.phx.gbl... 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)."
Thank you all for your insight. I had a bad feeling 'bout this.
The object that invokes the control manager has the responsibility of
instantiationg the control and using it. One option is displaying it.
Hence, the control manager will never be the sole owner of the control.
Also, when the CLControlmanager is told to close the control window, the
instantiating object will still be in possession of the control and can
continue operating on the control. .
I think that the best solution would be NOT dispose of the control in the
CLContolManager class at all and leave that up to the instantiating class.
The thought process that led me down this disposing route was the references
to the control maintained in the CLControlmanager stack. I was thinking
that the CLR would consider the stack entry another independent reference.
It really isn't. At the time the instantiating class is finished with the
control, the CLControlManager will have closed the display according to the
rules of the game.
If, and this is not the situation, the instantiating objects control were go
go out of scope, the CLR would not know about the reference to the control
on the CLControlManager stack and this would cause problems when
CLControlManager tried to play with it.
A general question comes to mind.
A. I instantiate a control
B. CLControlManager displays it and puts it on its stack.
C. Things happen
D. The CLControlManager overwrites the stack entry to the control.
E. The instantiating object finishes with the control.
Step D will not have any effect on the control. It is still the
responsibility of the instantinating object. Is this correct?
Your example used pass by value Int32's. The situation is more like this:
public class mgr
{
private System.Windows.Forms.Button[] stk=new
System.Windows.Forms.Button[10];
public void getref(System.Windows.Forms.Button i)
{
stk[0]=i;
}
public void print()
{
MessageBox.Show("stk[0]="+stk[0].Text);
}
}
private void button1_Click(object sender, System.EventArgs e)
{
mgr theMgr=new mgr();
System.Windows.Forms.Button theBtn=new System.Windows.Forms.Button();
theMgr.getref(theBtn);
theBtn.Text="Hello";
MessageBox.Show("theBtn="+theBtn.Text); // Displays 'Hello'
theMgr.print(); // Displays
'Hello'
theBtn.Text="Goodbye";
MessageBox.Show("theBtn="+theBtn.Text); // Displays 'Goodbye'
theMgr.print(); // Displays
'Goodbye'
}
Yes that is correct. The CLR only cares about outstanding reachable references when it does a GC so overwriting a reference is unimportant. If you can be consistent with the control manager not Disposing (i.e. the creator always outlives the control manager) then making sure the creator is the one to dispose us the correct design IMO
Regards
Richard Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk
Thank you all for your insight. I had a bad feeling 'bout this.
The object that invokes the control manager has the responsibility of
instantiationg the control and using it. One option is displaying it.
Hence, the control manager will never be the sole owner of the control.
Also, when the CLControlmanager is told to close the control window, the
instantiating object will still be in possession of the control and can
continue operating on the control. .
I think that the best solution would be NOT dispose of the control in the
CLContolManager class at all and leave that up to the instantiating class.
The thought process that led me down this disposing route was the references
to the control maintained in the CLControlmanager stack. I was thinking
that the CLR would consider the stack entry another independent reference.
It really isn't. At the time the instantiating class is finished with the
control, the CLControlManager will have closed the display according to the
rules of the game.
If, and this is not the situation, the instantiating objects control were go
go out of scope, the CLR would not know about the reference to the control
on the CLControlManager stack and this would cause problems when
CLControlManager tried to play with it.
A general question comes to mind.
A. I instantiate a control
B. CLControlManager displays it and puts it on its stack.
C. Things happen
D. The CLControlManager overwrites the stack entry to the control.
E. The instantiating object finishes with the control.
Step D will not have any effect on the control. It is still the
responsibility of the instantinating object. Is this correct?
--
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]" <ri******@NOSPAMdevelop.com> wrote in message news:u7*************@TK2MSFTNGP12.phx.gbl... You always pass around references to objects - you cannot pass an object by value.
This leads me to a question.
Since .NET objects are reference types (and are therefore always passed by reference), is there any advantage to explicitly declaring and passing objects as "ref"?
In other words, is there any advantage to writing
void SomeMethod(ref object o) { /* ... */ }
// ...
SomeMethod(ref someObject);
versus:
void SomeMethod(object o) { /* ... */ }
// ...
SomeMethod(someObject);
?
Thanks,
Alex.
--
Please replace myrealbox with alexoren to reply by email.
"John Bailo" <ja*****@earthlink.net> wrote in message
news:42**************@earthlink.net... 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 ?
}
After making the necessary changes:
static void test (object o)
{
o = 5;
}
....
object o = 7;
the value should be 7, but what does it prove?
You are passing a reference by value, that is the callee gets a copy of the
value of the reference NOT a copy the actual object value.
The callee creates a new instance (boxed value 5) and assigns the reference
to the reference passed in as argument.
On return the callers object reference and the value are never touched, so
the value is unchanged.
Schematically:
Caller:
object o = 7;
stack location 0x127568 contains 0xba1208 which ----> object
- object contains value 7
on call test(object o)
stack location 0x127568 contains 0xba1208 which ----> object
- object contains value 7
and (argument) 0x127564 contains 0xba1208 which ----> same object
Callee:
on o = 5;
stack location 0x127564 contains 0xba1224 which -----> object o
(new) - new object has value 5.
On return;
Stack unwinds and 0x127564 goes out of scope which makes the object it
points to eligible for GC.
stack location 0x127568 contains 0xba1208 which ----> object
- object contains value 7
Willy.
"Alex" <re******@myrealbox.com> a écrit dans le message de news: 3a*************@individual.net...
Since .NET objects are reference types (and are therefore always passed by
reference), is there any advantage to explicitly declaring and passing
objects as "ref"?
No, objects are reference types that are always passed by value unless you
declare a ref parameter.
The difference is that the ref parameter allows you to change the actual
object that is passed in, rather than just being able to change the
properties of the object with a non-ref parameter.
Joanna
--
Joanna Carter
Consultant Software Engineer
John Bailo <ja*****@earthlink.net> wrote: 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 ?
}
7, because passing a reference by value isn't the same as passing a
value by reference.
See http://www.pobox.com/~skeet/csharp/parameters.html
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)."
Exactly. That doesn't disagree with what Richard was saying at all.
Note that he *didn't* say that objects were passed *by* reference, he
said that references to objects were passed. Big difference.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Alex <re******@myrealbox.com> wrote: This leads me to a question.
Since .NET objects are reference types (and are therefore always
passed by reference), is there any advantage to explicitly declaring
and passing objects as "ref"?
Your reasoning is flawed - there's a big difference between passing a
reference by value and passing a value by reference.
See http://www.pobox.com/~skeet/csharp/parameters.html
And yes, sometimes it is worth passing reference-type parameters by
reference.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I looked over your link and found it informative.
There is one refeence example in the link:
StringBuilder first = new StringBuilder();
StringBuilder second = first;
first.Append ("hello");
first = null;
Console.WriteLine (second);
How does GC know when the object is eligable for disposal? The instaniating
variable has dereferenced the object and another variable now exists. If
second dereferences the object so it is no longer in use, how is this
condition detected?
Thanx,
Bill
Hello Joanna,
"Joanna Carter (TeamB)" <jo*****@nospamforme.com> wrote in message news:%2****************@TK2MSFTNGP15.phx.gbl... "Alex" <re******@myrealbox.com> a écrit dans le message de news:
3a*************@individual.net...
Since .NET objects are reference types (and are therefore always passed by
reference), is there any advantage to explicitly declaring and passing
objects as "ref"?
No, objects are reference types that are always passed by value unless you
declare a ref parameter.
That's what I meant.
Saying that the reference to the object is passed by value is the same as saying that the object itself is passed by reference.
What I did not know is whether there are benefits to passing the reference by reference (apart from being able to change it so it references another object).
The difference is that the ref parameter allows you to change the actual
object that is passed in, rather than just being able to change the
properties of the object with a non-ref parameter.
Is that the only benefit?
The reason that I'm asking is that I see a lot of C# code on the net that passes object references by reference to functions that do not change the reference (but may change the objects themselves). I thought that I may be missing something...
Thanks,
Alex.
--
Please replace myrealbox with alexoren to reply by email.
Jon Skeet [C# MVP] wrote: Alex <re******@myrealbox.com> wrote:
This leads me to a question.
Since .NET objects are reference types (and are therefore always
passed by reference), is there any advantage to explicitly declaring
and passing objects as "ref"?
Your reasoning is flawed - there's a big difference between passing a
reference by value and passing a value by reference.
See http://www.pobox.com/~skeet/csharp/parameters.html
And yes, sometimes it is worth passing reference-type parameters by
reference.
I do this in a web service I wrote where I pass in a SqlDataReader to
another method, by reference, because I want to close the data reader in
the called method.
You don't need to pass it by reference to close it in the other method. Both the caller reference and the received parameter reference will refer to the same object anyway.
Regards
Richard Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk
Jon Skeet [C# MVP] wrote: Alex <re******@myrealbox.com> wrote:
This leads me to a question.
Since .NET objects are reference types (and are therefore always
passed by reference), is there any advantage to explicitly declaring
and passing objects as "ref"?
Your reasoning is flawed - there's a big difference between passing a
reference by value and passing a value by reference.
See http://www.pobox.com/~skeet/csharp/parameters.html
And yes, sometimes it is worth passing reference-type parameters by
reference.
I do this in a web service I wrote where I pass in a SqlDataReader to
another method, by reference, because I want to close the data reader in
the called method.
web1110 <we***@comcast.net> wrote: I looked over your link and found it informative.
There is one refeence example in the link:
StringBuilder first = new StringBuilder();
StringBuilder second = first;
first.Append ("hello");
first = null;
Console.WriteLine (second);
How does GC know when the object is eligable for disposal? The instaniating
variable has dereferenced the object and another variable now exists. If
second dereferences the object so it is no longer in use, how is this
condition detected?
The GC is able to tell when it runs what the "root" references are -
static variables, locals in all stack frames etc. It then walks down
the variables that the objects those variables refer to contain, etc.
See http://msdn.microsoft.com/msdnmag/is...I/default.aspx
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
John Bailo <jabailo___jabailo@earthlink______.net> wrote: I do this in a web service I wrote where I pass in a SqlDataReader to
another method, by reference, because I want to close the data reader in
the called method.
That suggests that you don't really understand the difference between
pass-by-reference and passing a reference by value then, I'm afraid...
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Alex <re******@myrealbox.com> wrote: That's what I meant.
Saying that the reference to the object is passed by value is the
same as saying that the object itself is passed by reference.
No it's *not*. See http://www.pobox.com/~skeet/csharp/parameters.html
What I did not know is whether there are benefits to passing the
reference by reference (apart from being able to change it so it
references another object).
That's the whole *purpose* of passing a parameter by reference (unless
it's a large value type). The difference is that the ref parameter allows you to change the actual
object that is passed in, rather than just being able to change the
properties of the object with a non-ref parameter.
Is that the only benefit?
The reason that I'm asking is that I see a lot of C# code on the net
that passes object references by reference to functions that do not
change the reference (but may change the objects themselves). I
thought that I may be missing something...
That's likely to just be bad code.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om... Alex <re******@myrealbox.com> wrote: That's what I meant.
Saying that the reference to the object is passed by value is the
same as saying that the object itself is passed by reference.
No it's *not*. See http://www.pobox.com/~skeet/csharp/parameters.html
Yes it *is*.
Pointing to a web site without understanding what it says does not prove anything. Nor does using asterisks.
Jon's sidenote talks about : "what is the difference between passing a value object by reference and a reference object by value?"
Which is distinctly different from what I said. The reason that I'm asking is that I see a lot of C# code on the net
that passes object references by reference to functions that do not
change the reference (but may change the objects themselves). I
thought that I may be missing something...
That's likely to just be bad code.
Thank you for confirming that.
Best wishes,
Alex.
--
Please replace myrealbox with alexoren to reply by email.
Alex <re******@myrealbox.com> wrote: Alex <re******@myrealbox.com> wrote: That's what I meant.
Saying that the reference to the object is passed by value is the
same as saying that the object itself is passed by reference.
No it's *not*. See http://www.pobox.com/~skeet/csharp/parameters.html
Yes it *is*.
Pointing to a web site without understanding what it says does not
prove anything. Nor does using asterisks.
Um, I wrote that article. I definitely do understand what it says. If
you're claiming to agree with the article and still maintain that C#'s
behaviour is "the same as saying that the object itself is passed by
reference" then you're the one who doesn't understand the article, I'm
afraid.
Jon's sidenote talks about: "what is the difference between passing a
value object by reference and a reference object by value?" Which is
distinctly different from what I said.
Not really. If you think it is, maybe I should change the article to
make it clearer. Passing an object itself by any means isn't possible
in .NET, as no expression has a type which is the object itself.
Pass by reference has a very specific meaning in terms of formal and
actual parameters, and is different to passing a reference by value -
in the same way as C doesn't have pass-by-reference at all, but that
doesn't stop you from passing pointers (by value).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om... Alex <re******@myrealbox.com> wrote: Alex <re******@myrealbox.com> wrote:
> That's what I meant.
> Saying that the reference to the object is passed by value is the
> same as saying that the object itself is passed by reference.
No it's *not*. See http://www.pobox.com/~skeet/csharp/parameters.html
Yes it *is*.
Pointing to a web site without understanding what it says does not
prove anything. Nor does using asterisks.
Um, I wrote that article. I definitely do understand what it says. If
you're claiming to agree with the article and still maintain that C#'s
behaviour is "the same as saying that the object itself is passed by
reference" then you're the one who doesn't understand the article, I'm
afraid.
Maybe I don't.
Would you be so kind to explain the difference between the following statements:
1) Object X is passed to function F by reference.
2) A reference to Object X is passed to function F by value.
I claim that the statements are equivalent, as they both describe putting a reference to object X on the stack (or a register, whatever) before calling function F. The difference is semantic but it can help visualize what is going on.
If you think that I am mistaken, please show me how.
Your article, as I understand it, talks about two different types of objects - a value object that is passed by reference and a reference object that is passed by value. In that case the behaviour that you are trying to show is indeed different but that is something different altogether.
Not really. If you think it is, maybe I should change the article to
make it clearer. Passing an object itself by any means isn't possible
in .NET, as no expression has a type which is the object itself.
My mistake. I was using generic English terms and not specific .NET terminology.
If I replace "object" with "entity" will you agree with my statement then?
Pass by reference has a very specific meaning in terms of formal and
actual parameters, and is different to passing a reference by value -
in the same way as C doesn't have pass-by-reference at all, but that
doesn't stop you from passing pointers (by value).
Actually, passing a pointer in C is equivalent to "pass by reference".
And the actual behaviour is pretty close to your example:
Passing a pointer to a data type (I'm being careful not to say "object") allows you to change the value if that data type from inside the function, but *not* to "re-seat" the pointer (make it point to a different instance of that data type.
The same principle holds with C++ references.
C# (and, if I recall correctly, Java) confuses matters a bit by only allowing "reference types" to reside on the heap and "value types" on the stack but there is no fundamental difference in behaviour.
Best wishes,
Alex.
--
Please replace myrealbox with alexoren to reply by email.
Alex <re******@myrealbox.com> wrote: Um, I wrote that article. I definitely do understand what it says. If
you're claiming to agree with the article and still maintain that C#'s
behaviour is "the same as saying that the object itself is passed by
reference" then you're the one who doesn't understand the article, I'm
afraid.
Maybe I don't.
Would you be so kind to explain the difference between the following statements:
1) Object X is passed to function F by reference.
2) A reference to Object X is passed to function F by value.
Sure. Changing the value of the actual parameter in the function F has
no effect (as far as the caller sees) in the second case, but changes
the value of the formal parameter in the first case.
I claim that the statements are equivalent, as they both describe
putting a reference to object X on the stack (or a register,
whatever) before calling function F. The difference is semantic but
it can help visualize what is going on.
If you think that I am mistaken, please show me how.
See above.
Your article, as I understand it, talks about two different types of
objects - a value object that is passed by reference and a reference
object that is passed by value. In that case the behaviour that you
are trying to show is indeed different but that is something
different altogether.
While there are value types and reference types in .NET, it doesn't
really alter anything. If you pass something by value, then changing
the value which is passed doesn't affect the caller's value. If you
pass something by reference, the variable used by the called method is
the same variable (or l-value, whatever) as the caller is using -
changing one changes the other.
Not really. If you think it is, maybe I should change the article to
make it clearer. Passing an object itself by any means isn't possible
in .NET, as no expression has a type which is the object itself.
My mistake. I was using generic English terms and not specific .NET terminology.
If I replace "object" with "entity" will you agree with my statement then?
Nope, because it's the "pass by reference" which has a very specific
meaning. By claiming that objects are passed by reference, you're
implying semantics which just don't occur in .NET.
Pass by reference has a very specific meaning in terms of formal and
actual parameters, and is different to passing a reference by value -
in the same way as C doesn't have pass-by-reference at all, but that
doesn't stop you from passing pointers (by value).
Actually, passing a pointer in C is equivalent to "pass by reference".
No it's not - that's the point. It's not the same thing in the strict
sense of the terminology, which means that if you tell people who *do*
know the strict sense of the terminology that objects are passed by
reference, they'll expect behaviour other than what they get.
Many of the uses of pass by reference can be simulated by passing an
address/reference/pointer/whatever by value, but it's not the same as
pass by reference in itself.
And the actual behaviour is pretty close to your example:
Passing a pointer to a data type (I'm being careful not to say
"object") allows you to change the value if that data type from
inside the function, but *not* to "re-seat" the pointer (make it
point to a different instance of that data type.
Changing the value of the pointer (the parameter) doesn't change the
caller's value though - it's only changing the value of what the
pointer points at that makes the change visible. The parameter here is
the pointer, not the value of the variable whose address is passed as a
pointer.
The same principle holds with C++ references.
I don't like to use C++ terminology as I don't know it well enough to
be confident of being strictly correct.
C# (and, if I recall correctly, Java) confuses matters a bit by only
allowing "reference types" to reside on the heap and "value types" on
the stack but there is no fundamental difference in behaviour.
Even that's not true, as value types also reside on the heap within
reference type objects. Anyway...
See http://www.yoda.arachsys.com/java/passing.html for another way of
putting things.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Alex" <re******@myrealbox.com> wrote in message
news:3a*************@individual.net... 1) Object X is passed to function F by reference.
The actual reference is passed in - not possible in C
Thus the external reference CAN be modified2) A reference to Object X is passed to function F by value.
A COPY of the reference is passed in - this is similar to "pass by
reference" in C
Thus the external reference CANNOT be modified
Try this Example:
void ByValue(X x)
{
x = null;
}
void ByRef(ref X x)
{
x = null;
}
void Test()
{
X x = new X();
ByValue(x);
Console.WriteLine("X is {0}", (x == null)? "null" : "assigned");
ByRef(ref x);
Console.WriteLine("X is {0}", (x == null)? "null" : "assigned");
}
*****OUTPUT******
X is assigned
X is null
This was explained on Jon's page
Hope this helps
Bill This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: faktujaa |
last post by:
Hi All,
A small confusion. I have defined a connection class that has
System.Data.IDbConnection as a member variable and implements IDisposable
interface. I have implemented Dispose method to call...
|
by: RiteshDotNet |
last post by:
..net Frame work
1. Dispose Method what it does ?
A. who its call / when it calls ?
B. Is it fire automatically ?
c. When dispose method is call what it does ?
D. Release a Object from memory or...
|
by: Daniel Mori |
last post by:
If an object implements the IDisposable interface (regardless if its a
framework object or a user object), should I always dispose of that
object out of principle?
|
by: Maxim |
last post by:
Hi!
According to documenation, if we need to release some umanaged
resources manually, we need to implement IDisposable interface with
single Dispose method. I am just wondering, what will...
|
by: Billy |
last post by:
Hello...
I'm trying to make a database access class for an asp.net
application. When I run my application, the Garbage
Collecter doesn't seems to unload the memory attributed
to my...
|
by: Scott M. |
last post by:
In a typical class, do I need to indicate that it implements the IDisposable
interface and then create a Dispose method that implements the Dispose
required by the IDisposable interface or can I...
|
by: Teresa |
last post by:
1) If I do want to keep an object alive throughout the live of an
application, how can I ensure that the GC doesn't clean it up?
2a) How do I determine if an object is a managed or an unmanged...
|
by: Dennis |
last post by:
Ok, I'm trying to dispose of every object that I create that has a dispose
method based on advice from this newsgroup. However, I'm not sure how to
dispose of the following object that was created...
|
by: Markus Stoeger |
last post by:
Hi,
I have a class similar to that:
class MyClass : IDisposable {
IDisposable obj1;
IDisposable obj2;
IDisposable obj3;
MyClass() {
|
by: active |
last post by:
In the main program I check to see if a certain form has been disposed.
Does it make sense in that form's FormClosed event to do:
Me.Dispose to make sure it is disposed the next time I check.
Or...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
