Avoiding redundant storage. Share keyword?

[Gregory Gadow]

In a VB.Net 2.0 project, I have a WizardClass that contains a List (of
RuleClass). Each rule needs access to variables within it's parent
wizard, so the constructor for RuleClass is New (ByVal Wizard as
WizardClass). Each rule then has a property Private Wiz as WizardClass,
which is set in Sub New with Wiz = Wizard. Currently there is only one
Wizard in the project but there might be more in the future to handle
different rulesets.

My understanding is that, with this, each instance of RuleClass has its
own isolated and independent copy of WizardClass, which would take up a
huge amount of memory if there are a lot of rules. This is part of a
service, so the memory would be permanently used. Is this actually the
case? If so, any suggestions on how to prevent this memory use?

I am thinking that I can declare each instance of WizardClass to be
Shared, so in the service module:

Private Shared Wizzie1 as WizardClass
Private Shared Wizzie2 as WizardClass

would create independent instances of WizardClass and each time Wizzie1
or Wizzie2 appear on the right of an = a pointer to the instance would
be generated rather than a copy. So in the LoadRuleset method of
WizardClass

mRulesList.Add( New RuleClass(Me))

would create only a pointer to the shared parent wizard rather than a
complete copy of the wizard object. Will this do what I think it will?
Will this happen automatically when the project is compiled and
(hopefully) optimized? Or am I barking up the wrong tree entirely?

Thanks in advance for any help.
--
Gregory Gadow
te******@serv.n et
http://www.serv.net/~techbear

"[W]e have never held that moral disapproval, without any other asserted

state interest, is a sufficient rationale under the Equal Protection
Clause to justify a law that discriminates among groups of persons."
- Sandra Day O`Conner, _Lawrence v Texas_
http://caselaw.lp.findlaw.com/script...0&invol=02-102

[Herfried K. Wagner [MVP]]

"Gregory Gadow" <te******@serv. net> schrieb:

In a VB.Net 2.0 project, I have a WizardClass that contains a List (of
RuleClass). Each rule needs access to variables within it's parent
wizard, so the constructor for RuleClass is New (ByVal Wizard as
WizardClass). Each rule then has a property Private Wiz as WizardClass,
which is set in Sub New with Wiz = Wizard. Currently there is only one
Wizard in the project but there might be more in the future to handle
different rulesets.

My understanding is that, with this, each instance of RuleClass has its
own isolated and independent copy of WizardClass
If you are passing the reference to an existing 'WizardClass' object to the
new object and store the reference to this object there, only an additional
reference is created. Both instances will reference the same 'WizardClass'
object afterwards.
, which would take up a
huge amount of memory if there are a lot of rules. This is part of a
service, so the memory would be permanently used. Is this actually the
case? If so, any suggestions on how to prevent this memory use?
No, it isn't the case if 'WizardClass' is a reference type, e.g. a class.
I am thinking that I can declare each instance of WizardClass to be
Shared, so in the service module:

Private Shared Wizzie1 as WizardClass
Private Shared Wizzie2 as WizardClass

would create independent instances of WizardClass

The code above doesn't create instance of /classes/ at all. It only
declares variables which reference 'Nothing' by default. If you assign the
same reference to both variables later, only a single instance of
'WizardClass' exists.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Gregory Gadow]

"Herfried K. Wagner [MVP]" wrote:

"Gregory Gadow" <te******@serv. net> schrieb:

In a VB.Net 2.0 project, I have a WizardClass that contains a List (of
RuleClass). Each rule needs access to variables within it's parent
wizard, so the constructor for RuleClass is New (ByVal Wizard as
WizardClass). Each rule then has a property Private Wiz as WizardClass,
which is set in Sub New with Wiz = Wizard. Currently there is only one
Wizard in the project but there might be more in the future to handle
different rulesets.

My understanding is that, with this, each instance of RuleClass has its
own isolated and independent copy of WizardClass

If you are passing the reference to an existing 'WizardClass' object to the
new object and store the reference to this object there, only an additional
reference is created. Both instances will reference the same 'WizardClass'
object afterwards.

I can make the whole issue go away by using ByRef in the constructor of
RuleClass?

In that case, this code in RuleClass will store only a reference and not a
complete instance

Private Wiz as WizardClass

Public Sub New(ByRef MyWizard as WizardClass)
Wiz = MyWizard
....
End Sub

and latter calls of

Wiz.DefaultPrin ter

will all reference the same block of memory?

/slaps forehead

Some things in .NET are too bloody obvious to be seen. Thanks.

, which would take up a
huge amount of memory if there are a lot of rules. This is part of a
service, so the memory would be permanently used. Is this actually the
case? If so, any suggestions on how to prevent this memory use?

No, it isn't the case if 'WizardClass' is a reference type, e.g. a class.

I am thinking that I can declare each instance of WizardClass to be
Shared, so in the service module:

Private Shared Wizzie1 as WizardClass
Private Shared Wizzie2 as WizardClass

would create independent instances of WizardClass

The code above doesn't create instance of /classes/ at all. It only
declares variables which reference 'Nothing' by default. If you assign the
same reference to both variables later, only a single instance of
'WizardClass' exists.

Correct, I should have written

Private Shared Wizzie1 as New WizardClass(<va rious parameters>)
Private Shared Wizzie2 as New WizardClass(<di fferent parameters>)

Not that it matters now.
--
Gregory Gadow
te******@serv.n et
http://www.serv.net/~techbear

"[W]e have never held that moral disapproval, without any other asserted
state interest, is a sufficient rationale under the Equal Protection
Clause to justify a law that discriminates among groups of persons."
- Sandra Day O`Conner, _Lawrence v Texas_
http://caselaw.lp.findlaw.com/script...0&invol=02-102

[Herfried K. Wagner [MVP]]

"Gregory Gadow" <te******@serv. net> schrieb:

> In a VB.Net 2.0 project, I have a WizardClass that contains a List (of
> RuleClass). Each rule needs access to variables within it's parent
> wizard, so the constructor for RuleClass is New (ByVal Wizard as
> WizardClass). Each rule then has a property Private Wiz as WizardClass,
> which is set in Sub New with Wiz = Wizard. Currently there is only one
> Wizard in the project but there might be more in the future to handle
> different rulesets.
>
> My understanding is that, with this, each instance of RuleClass has its
> own isolated and independent copy of WizardClass
If you are passing the reference to an existing 'WizardClass' object to
the
new object and store the reference to this object there, only an
additional
reference is created. Both instances will reference the same
'WizardClass'
object afterwards.

I can make the whole issue go away by using ByRef in the constructor of
RuleClass?

No, you do not need a 'ByRef' here as 'WizardClass' is already a reference
type. Even with 'ByRef', which I recommend in this sitation, no copy of the
'WizardClass' /object/ is created.
In that case, this code in RuleClass will store only a reference and not a
complete instance

Private Wiz as WizardClass

Public Sub New(ByRef MyWizard as WizardClass)
Wiz = MyWizard
...
End Sub
Even with 'ByVal' instead of 'ByRef' it will only store a reference.
and latter calls of

Wiz.DefaultPrin ter

will all reference the same block of memory?

Yes, they reference the same object (class instance).

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Jon Skeet [C# MVP]]

Herfried K. Wagner [MVP] <hi************ ***@gmx.at> wrote:

I can make the whole issue go away by using ByRef in the constructor of
RuleClass?

No, you do not need a 'ByRef' here as 'WizardClass' is already a reference
type. Even with 'ByRef', which I recommend in this sitation, no copy of the
'WizardClass' /object/ is created.

Did you mean "Event with 'ByVal', which I recommend [...]"? That's what
I'd expect :)

Gregory: See http://www.pobox.com/~skeet/csharp/parameters.html for
details of parameter passing. It's C#-based, but the basics are the
same for VB.NET. (There are a few differences, such as properties not
being able to be passed by reference in C#, but it should still be
useful in terms of concepts.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Herfried K. Wagner [MVP]]

Jon,

"Jon Skeet [C# MVP]" <sk***@pobox.co m> schrieb:

> I can make the whole issue go away by using ByRef in the constructor of
> RuleClass?

No, you do not need a 'ByRef' here as 'WizardClass' is already a
reference
type. Even with 'ByRef', which I recommend in this sitation, no copy of
the
'WizardClass' /object/ is created.

Did you mean "Event with 'ByVal', which I recommend [...]"? That's what
I'd expect :)

Yep. I wanted to type 'ByVal'. Thanks for pointing out this "bug" in my
post.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Gregory Gadow]

"Jon Skeet [C# MVP]" wrote:

Herfried K. Wagner [MVP] <hi************ ***@gmx.at> wrote:

I can make the whole issue go away by using ByRef in the constructor of
RuleClass?

No, you do not need a 'ByRef' here as 'WizardClass' is already a reference
type. Even with 'ByRef', which I recommend in this sitation, no copy of the
'WizardClass' /object/ is created.

Did you mean "Event with 'ByVal', which I recommend [...]"? That's what
I'd expect :)

Gregory: See http://www.pobox.com/~skeet/csharp/parameters.html for
details of parameter passing. It's C#-based, but the basics are the
same for VB.NET. (There are a few differences, such as properties not
being able to be passed by reference in C#, but it should still be
useful in terms of concepts.)

I'm familiar enough with C and C++ that the basics of C# are no problem. Thanks,
the page is a nice resource.
--
Gregory Gadow