reference and value

[=?Utf-8?B?QWxla3MgS2xleW4=?=]

When I call sub in VB I can sent value of variable or reference to this
value. The question is. Suppose I have class
public class AA
....
end class
and declare object of this class
dim objAA as AA

Does objAA is value or it refers to memory where I keep appropriate value.
If objAA is value how I can declare it as reference?

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

Aleks Kleyn wrote:

When I call sub in VB I can sent value of variable or reference to this
value.

I suppose that you mean the ByVal and ByRef keywords?

The ByRef keyword sends a variable _by_ reference. Don't confuse this
with sending _a_ reference, it's not the same thing at all.

When you send a variable by reference, the method can change the value
of that variable. When you send a variable by value, the method gets a
copy of the value, so that it can not change the variable itself.

The default for arguments is ByVal, and this is what you should normally
use. For a value type, sending by value means that a copy of the value
is sent to the method. For a reference type, it means that a copy of the
reference is sent to the method. The method can change the object that
the reference points to, but it can not change the reference variable
itself.

The question is. Suppose I have class
public class AA
...
end class
and declare object of this class
dim objAA as AA

Does objAA is value or it refers to memory where I keep appropriate value.
If objAA is value how I can declare it as reference?

A class is a reference type, so the variable objAA is a reference.

--
Göran Andersson
_____
http://www.guffa.com

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

Aleks Kleyn wrote:

So suppose I write code

class C1
...
end class
class C2
...
public objC1a as C1
...
end class
class myCode
dim objC1 as C1
dim objC2 as C2
public sub new
objC1=new C1
objC2=new C2
objC2.objC1a=objC1
end sub
end class

Then objC2.objC1a is just refference to objC1.

No, it's not a "refference", it's a reference. ;)

Then I have other qusetion. This means that objC2.objC1a has the same amount
of memory does not matter how much memory gets objC1.

Yes, a reference is always the same size.

Recently I posted
problem in thread asp 2.0 and memory leak. Eliyahu Goldin responded me on
8/1/07

Almost certainly the problem is in storing large amount of data in session
variables.

However this statement contradicts initial statement. And the question is:
where is the answer?

What's stored in the session variable is always a reference, so strictly
speaking what you store in a session variable is always the same size.

However, one does not usually speak that strictly about reference
variables. If you have a string variable, for example, you say that you
store a string in it, although what you actually do is store a reference
to a string in it.

When Eliyahu is talking about storing large objects in session
variables, he means putting references to large objects in session
variables. This is implied, as it obviously is impossible to store a
large object in a reference.

--
Göran Andersson
_____
http://www.guffa.com

[Aleks Kleyn]

I try to sumaris what I understand. If I store in session reference to large
object this object is allocated in address space of aspnet.exe. It does not
matter do I refer to this object from session collection, from application
collection or if I put this object in web service. Because size of this
object may vary in time it eventualy leads to memory leak when a lot of
people work with web site. So it better to make step back and simplify
design. It is good that I did this only on few pages.
Probably it would be better if separate process run for different session.
However it may be not proper solution. I am not sure if communication of web
site with desktop application can help to solve this problem.

Very close question. What will happens with LINQ. Should I expect there
similar problem?
"Göran Andersson" <gu***@guffa.comwrote in message
news:eR**************@TK2MSFTNGP03.phx.gbl...

Aleks Kleyn wrote:

>So suppose I write code

class C1
...
end class
class C2
...
public objC1a as C1
...
end class
class myCode
dim objC1 as C1
dim objC2 as C2
public sub new
objC1=new C1
objC2=new C2
objC2.objC1a=objC1
end sub
end class

Then objC2.objC1a is just refference to objC1.

No, it's not a "refference", it's a reference. ;)

>Then I have other qusetion. This means that objC2.objC1a has the same
amount of memory does not matter how much memory gets objC1.

Yes, a reference is always the same size.

>Recently I posted problem in thread asp 2.0 and memory leak. Eliyahu
Goldin responded me on 8/1/07

Almost certainly the problem is in storing large amount of data in
session variables. However this statement contradicts initial statement.
And the question is: where is the answer?

What's stored in the session variable is always a reference, so strictly
speaking what you store in a session variable is always the same size.

However, one does not usually speak that strictly about reference
variables. If you have a string variable, for example, you say that you
store a string in it, although what you actually do is store a reference
to a string in it.

When Eliyahu is talking about storing large objects in session variables,
he means putting references to large objects in session variables. This is
implied, as it obviously is impossible to store a large object in a
reference.

--
Göran Andersson
_____
http://www.guffa.com

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

Aleks Kleyn wrote:

I try to sumaris what I understand. If I store in session reference to
large object this object is allocated in address space of aspnet.exe.

Well, nothing is allocated when you store the reference in the session
variable. The memory was allocated when you created the object.

It
does not matter do I refer to this object from session collection, from
application collection or if I put this object in web service. Because
size of this object may vary in time it eventualy leads to memory leak
when a lot of people work with web site.

The size of a specific object doesn't vary, it's always the same.

It's not a memory leak, it's memory that you lost control over. You
leave it in the hands of session objects that aren't used any more. The
memory will be collected when the sessions ends, but you have no control
over when that happens.

So it better to make step back
and simplify design.

Correct.

It is good that I did this only on few pages.
Probably it would be better if separate process run for different
session. However it may be not proper solution. I am not sure if
communication of web site with desktop application can help to solve
this problem.

You just have to take control over the objects that you handle. If you
really need to keep that much information available, you should not
store all of it in memory.

Very close question. What will happens with LINQ. Should I expect there
similar problem?

That's not close at all. LINQ is just a new way of writing things that
already exist. It will not change the fact that you have to keep track
of your objects.

--
Göran Andersson
_____
http://www.guffa.com