struct or class?

[Lloyd Dupont]

I have an object which is just a thin wrapper over an other object and might
be created in big quantities.
something like that:

// ===== pseudo-code cample =======
class TheObject
{
int[] data;

TheWrapper Data { get { return new TheWrapper(data ); } }
}

class or struct TheWrapper
{
int[] data;

public TheWrapper(int[] data)
{
this.data = data;
}
public int Length { get { return data.Length; } }
public int this[int index] { get { return data[index]; } }

public int UtiliyOneLikeSe arch() {}
//... etc ...
}
// ========= end of pseudo-code sample ==========
Now it is very likely that aTheObject.Data would be called many times used
for a few lines and forgot.

I thought it might be much more efficient memory wise to make TheWrapper a
struct.

but somehow I feel it's quite unconventional.
what do you think?

[chanmm]

Implement Idisposable interface and destructor rather.
http://msdn2.microsoft.com/en-us/lib...le(VS.80).aspx

chanmm

"Lloyd Dupont" <net.galador@ld > wrote in message
news:Op******** ******@TK2MSFTN GP02.phx.gbl...

I have an object which is just a thin wrapper over an other object and
might be created in big quantities.
something like that:

// ===== pseudo-code cample =======
class TheObject
{
int[] data;

TheWrapper Data { get { return new TheWrapper(data ); } }
}

class or struct TheWrapper
{
int[] data;

public TheWrapper(int[] data)
{
this.data = data;
}
public int Length { get { return data.Length; } }
public int this[int index] { get { return data[index]; } }

public int UtiliyOneLikeSe arch() {}
//... etc ...
}
// ========= end of pseudo-code sample ==========
Now it is very likely that aTheObject.Data would be called many times used
for a few lines and forgot.

I thought it might be much more efficient memory wise to make TheWrapper a
struct.

but somehow I feel it's quite unconventional.
what do you think?

[Jon Skeet [C# MVP]]

chanmm <ch*****@hotmai l.com> wrote:

Implement Idisposable interface and destructor rather.
http://msdn2.microsoft.com/en-us/lib...le(VS.80).aspx

Why? There's no suggestion of anything which indicates that IDisposable
is required, or any need for a finalizer.

--
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

[Barry Kelly]

"Lloyd Dupont" <net.galador@ld > wrote:

I thought it might be much more efficient memory wise to make TheWrapper a
struct.

It might be slightly more efficient, but you won't know until you
measure. Be careful, though: structs have different semantics to
classes, since they get copied around rather than referenced. Structs
work best for immutable values - i.e. the methods and properties on the
struct don't change the internal state of the struct. That way you can
avoid accidentally modifying a copy rather than the original, if
somebody writes code that mistakes a struct for a class.

-- Barry

--
http://barrkel.blogspot.com/

[Lloyd Dupont]

why?
my concern being performance I'm afraid write a finalizer might worsen the
performance, not improve it.

--
Regards,
Lloyd Dupont

NovaMind development team
NovaMind Software
Mind Mapping Software
<www.nova-mind.com>
"chanmm" <ch*****@hotmai l.com> wrote in message
news:O$******** ******@TK2MSFTN GP03.phx.gbl...

Implement Idisposable interface and destructor rather.
http://msdn2.microsoft.com/en-us/lib...le(VS.80).aspx

chanmm

"Lloyd Dupont" <net.galador@ld > wrote in message
news:Op******** ******@TK2MSFTN GP02.phx.gbl...

I have an object which is just a thin wrapper over an other object and
might be created in big quantities.
something like that:

// ===== pseudo-code cample =======
class TheObject
{
int[] data;

TheWrapper Data { get { return new TheWrapper(data ); } }
}

class or struct TheWrapper
{
int[] data;

public TheWrapper(int[] data)
{
this.data = data;
}
public int Length { get { return data.Length; } }
public int this[int index] { get { return data[index]; } }

public int UtiliyOneLikeSe arch() {}
//... etc ...
}
// ========= end of pseudo-code sample ==========
Now it is very likely that aTheObject.Data would be called many times
used for a few lines and forgot.

I thought it might be much more efficient memory wise to make TheWrapper
a struct.

but somehow I feel it's quite unconventional.
what do you think?

[Lloyd Dupont]

They would be readonly wrapper, so there is no concern.

My main concern is that the underlying object won't be an array but a
reference to a custom type, which would change (not the reference but it's
"content").
hence the wrapper will too (much in the same ways as ReadOnlyLists).
That might be rather unintuitive for a struct.
--
Regards,
Lloyd Dupont

NovaMind development team
NovaMind Software
Mind Mapping Software
<www.nova-mind.com>
"Barry Kelly" <ba***********@ gmail.com> wrote in message
news:7k******** *************** *********@4ax.c om...

"Lloyd Dupont" <net.galador@ld > wrote:

I thought it might be much more efficient memory wise to make TheWrapper
a
struct.

It might be slightly more efficient, but you won't know until you
measure. Be careful, though: structs have different semantics to
classes, since they get copied around rather than referenced. Structs
work best for immutable values - i.e. the methods and properties on the
struct don't change the internal state of the struct. That way you can
avoid accidentally modifying a copy rather than the original, if
somebody writes code that mistakes a struct for a class.

-- Barry

--
http://barrkel.blogspot.com/

[Chris Chilvers]

On Mon, 26 Jun 2006 10:54:15 +1000, "Lloyd Dupont" <net.galador@ld >
wrote:

They would be readonly wrapper, so there is no concern.

My main concern is that the underlying object won't be an array but a
reference to a custom type, which would change (not the reference but it's
"content").
hence the wrapper will too (much in the same ways as ReadOnlyLists).
That might be rather unintuitive for a struct.

If the wrapper is ReadOnly and will be created many times could it be
worthwhile to cache the wrapper within the object?

If the wrapper copies the data to make it immutable you when the object
is next modified, the object can drop the reference to the current
wrapper and return a new one when next requested. Not even sure if
thread syncronization is a problem here as it wouldn't really matter if
you got two wrappers created.

[Barry Kelly]

"Lloyd Dupont" <net.galador@ld > wrote:

They would be readonly wrapper, so there is no concern.

My main concern is that the underlying object won't be an array but a
reference to a custom type, which would change (not the reference but it's
"content").
hence the wrapper will too (much in the same ways as ReadOnlyLists).
That might be rather unintuitive for a struct.

Classes have other benefits beyond structs. For example, you can
eliminate a public constructor taking no arguments, while every struct
has a public constructor taking no arguments, which initializes the
struct to all zeros.

I think you need to measure the performance improvements that may or may
not occur when you toggle between struct and class, and decide if the
performance benefits, if any, are worth the difference in semantics.

-- Barry

--
http://barrkel.blogspot.com/

[Lloyd Dupont]

PS: I don't copy any data.
Just a reference to a class.
And I provide only the read / get / view method to it (in the wrapper), much
in the same way as ReadOnlyList.

While the idea to cache the wrapper is good, I try to minimize the number of
instance variable of my main object, as there would be many instance of it
and I need to it to be as compact as possible.

--
Regards,
Lloyd Dupont

NovaMind development team
NovaMind Software
Mind Mapping Software
<www.nova-mind.com>
"Chris Chilvers" <ke****@dynafus .com> wrote in message
news:pj******** *************** *********@4ax.c om...

On Mon, 26 Jun 2006 10:54:15 +1000, "Lloyd Dupont" <net.galador@ld >
wrote:

They would be readonly wrapper, so there is no concern.

My main concern is that the underlying object won't be an array but a
reference to a custom type, which would change (not the reference but it's
"content").
hence the wrapper will too (much in the same ways as ReadOnlyLists).
That might be rather unintuitive for a struct.

If the wrapper is ReadOnly and will be created many times could it be
worthwhile to cache the wrapper within the object?

If the wrapper copies the data to make it immutable you when the object
is next modified, the object can drop the reference to the current
wrapper and return a new one when next requested. Not even sure if
thread syncronization is a problem here as it wouldn't really matter if
you got two wrappers created.

[Lloyd Dupont]

Yes.. I will wait until I'm able to profile the application.
Perhaps it doesn't matter at all!
And yes it was bothering me not to be able to get rid of the parameterless
constructor...

--
Regards,
Lloyd Dupont

NovaMind development team
NovaMind Software
Mind Mapping Software
<www.nova-mind.com>
"Barry Kelly" <ba***********@ gmail.com> wrote in message
news:1d******** *************** *********@4ax.c om...

"Lloyd Dupont" <net.galador@ld > wrote:

They would be readonly wrapper, so there is no concern.

My main concern is that the underlying object won't be an array but a
reference to a custom type, which would change (not the reference but
it's
"content").
hence the wrapper will too (much in the same ways as ReadOnlyLists).
That might be rather unintuitive for a struct.

Classes have other benefits beyond structs. For example, you can
eliminate a public constructor taking no arguments, while every struct
has a public constructor taking no arguments, which initializes the
struct to all zeros.

I think you need to measure the performance improvements that may or may
not occur when you toggle between struct and class, and decide if the
performance benefits, if any, are worth the difference in semantics.

-- Barry

--
http://barrkel.blogspot.com/