«

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?

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

The question is next: can I write
dim A as Type
and A is not value of something but reference on someting. So I can write
dim B as Type
B=A
and then B and A are addresses of the same value. This was essential part of
old languages like PL/1, C++, pascal. If VB is to substitude C++ it also
need something like this.
"Göran Andersson" <> wrote in message
news:...
> 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

Aleks Kleyn wrote:
> The question is next: can I write
> dim A as Type
> and A is not value of something but reference on someting.

It's a reference, but as you haven't created any object using the New
keyword, it doesn't reference anything.

> So I can write
> dim B as Type
> B=A

Yes.

> and then B and A are addresses of the same value. This was essential
> part of old languages like PL/1, C++, pascal. If VB is to substitude C++
> it also need something like this.

Who says VB is to substitute C++?


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

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.

Then I have other qusetion. This means that objC2.objC1a has the same amount
of memory does not matter how much memory gets objC1. 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?

"Göran Andersson" wrote:

> Aleks Kleyn wrote:
> > The question is next: can I write
> > dim A as Type
> > and A is not value of something but reference on someting.
>
> It's a reference, but as you haven't created any object using the New
> keyword, it doesn't reference anything.
>
> > So I can write
> > dim B as Type
> > B=A
>
> Yes.
>
> > and then B and A are addresses of the same value. This was essential
> > part of old languages like PL/1, C++, pascal. If VB is to substitude C++
> > it also need something like this.
>
> Who says VB is to substitute C++?
>
>
> --
> Göran Andersson
> _____
> http://www.guffa.com
>

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

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" <> wrote in message
news:...
> 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 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