struct or class?

  • Thread starter Thread starter Lloyd Dupont
  • Start date Start date
L

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 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?
 
Lloyd Dupont said:
I thought it might be much more efficient memory wise to make TheWrapper a
struct.
Click to expand...

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
 
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 said:
Implement Idisposable interface and destructor rather.
http://msdn2.microsoft.com/en-us/library/system.idisposable(VS.80).aspx

chanmm

Lloyd Dupont said:
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?
Click to expand...
Click to expand...
 
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>
 
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.
Click to expand...

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 said:
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.
Click to expand...

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