468,133 Members | 1,283 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,133 developers. It's quick & easy.

struct or class?

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 UtiliyOneLikeSearch() {}
//... 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?
Jun 25 '06 #1
9 1148
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**************@TK2MSFTNGP02.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 UtiliyOneLikeSearch() {}
//... 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?

Jun 25 '06 #2
chanmm <ch*****@hotmail.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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jun 25 '06 #3
"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/
Jun 25 '06 #4
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*****@hotmail.com> wrote in message
news:O$**************@TK2MSFTNGP03.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**************@TK2MSFTNGP02.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 UtiliyOneLikeSearch() {}
//... 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?


Jun 26 '06 #5
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.com...
"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/

Jun 26 '06 #6
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.
Jun 26 '06 #7
"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/
Jun 26 '06 #8
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.com...
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.

Jun 26 '06 #9
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.com...
"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/

Jun 26 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

21 posts views Thread by Kilana | last post: by
4 posts views Thread by Steve | last post: by
15 posts views Thread by Steven T. Hatton | last post: by
4 posts views Thread by DaHool | last post: by
5 posts views Thread by jwright | last post: by
27 posts views Thread by didacticone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.