Re: A portion of long data bytes as a property
- From: Peter Duniho <no.peted.spam@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 03 Dec 2009 21:26:08 -0800
Sin Jeong-hun wrote:
[...] In the original code I wrote, it would be very
inefficient because every time "Body" is accessed a new copy will be
created.
Define "very inefficient". Inefficient compared to what? Creating an impact to what degree in the rest of the code?
class Packet
{
private:
char EntireData[1024];
public:
const char* GetBody()
{
int HeaderLength=12;
return EntireData+HeaderLength;
}
};
Like this C++ code. Getting Body doesn't involve any copying.
That's true. But it also exposes implementation detail to client code, making it that much more convenient to shoot yourself in the foot.
Short answer: no, you can't do this in C#.
Slightly longer answer: copying the array isn't really that big of a problem most of the time; usually that copy is going to be sent off somewhere that is WAY slower than memory access. You could copy the array in memory a dozen, maybe even a hundred times, before the overhead becomes noticeable.
There are exceptions to every rule, of course. But for most purposes it's true.
Note that if performance really is a big concern, you may prefer to use the Buffer.BlockCopy() method instead of Array.Copy(). It doesn't do as much validation on the operation, copying raw bytes from one place to the other (even though it can handle any type of array), and so is somewhat faster.
That said, here's a slight variation on what I posted earlier that might work for you:
void DoSomething()
{
FileStream fs;
Packet p;
...
p.UseBody((byte[] rgb, int ibFirst, int cbLength) =>
fs.Write(rgb, ibFirst, cbLength));
}
class Packet
{
byte[] EntireData;
....
public void UseBody(Action<byte[], int, int> actionUse)
{
actionUse(EntireBody, HeaderSize, EntireSize - HeaderSize);
}
public byte[] Body
{
get
{
byte[] rtn = new byte[EntireSize - HeaderSize];
Array.Copy(EntireData, HeaderSize, rtn, BodySize);
return rtn;
}
}
}
That of course exposes implementation details, as your proposed C/C++ variant would. But, it avoids the client having to query three different properties, or pass local variables to some method that returns three different values.
Note that whether you return the byte[] reference to the caller, or you pass it to a delegate the caller provides, you can improve your encapsulation by returning/passing not the byte[] itself, but the result of calling AsReadOnly() on the byte[]. Of course, this is only useful if you don't literally need a byte[]; if you're writing the bytes to a Stream of some sort, for example, then that's probably not going to work for you. I mention it only if it should come up in other situations where it would be feasible.
Pete
.
- Follow-Ups:
- Re: A portion of long data bytes as a property
- From: Sin Jeong-hun
- Re: A portion of long data bytes as a property
- References:
- A portion of long data bytes as a property
- From: Sin Jeong-hun
- Re: A portion of long data bytes as a property
- From: Peter Duniho
- Re: A portion of long data bytes as a property
- From: Peter Duniho
- Re: A portion of long data bytes as a property
- From: Sin Jeong-hun
- A portion of long data bytes as a property
- Prev by Date: RE: Need algorithm to detect region/polygon
- Next by Date: What to do to make compiler consider STATIC Readonly properties as CONSTANT?
- Previous by thread: Re: A portion of long data bytes as a property
- Next by thread: Re: A portion of long data bytes as a property
- Index(es):
Relevant Pages
|