Getting pointer to the memory of MemoryStream

  • Thread starter Thread starter Maciej Oszutowski
  • Start date Start date
M

Maciej Oszutowski

Hi,

I'm going to port my PE manipulation library (written in C) to managed c++
class library. I would like to have opportunity to read content not only
from files, but also from memory, for example using MemoryStream.
Is it any possibility to get the char* pointer to the data stored in
MemoryStream *without* allocation of unmanaged memory and copying entire
stream contents to the newly allocated buffer?

Regards,
 
Maciej Oszutowski pisze:
Hi,

I'm going to port my PE manipulation library (written in C) to managed c++
class library. I would like to have opportunity to read content not only
from files, but also from memory, for example using MemoryStream.
Is it any possibility to get the char* pointer to the data stored in
MemoryStream *without* allocation of unmanaged memory and copying entire
stream contents to the newly allocated buffer?
Click to expand...
Lets say you do not use Stream as your type of entry data but you
consider two situations separatly: file stream and a MemoryStream mentioned.
Even then, what guarantee do you have that the inner implementation of
MemoryStream is based on one continuous table of bytes. Why not linked
list of tables, for instance?
 
Doker said:
Lets say you do not use Stream as your type of entry data but you
consider two situations separatly: file stream and a MemoryStream mentioned.
Even then, what guarantee do you have that the inner implementation of
MemoryStream is based on one continuous table of bytes. Why not linked
list of tables, for instance?
Click to expand...

The GetBuffer method would appear to be a pretty good indication that
it's just one array:

<quote>
The byte array from which this stream was created, or the underlying
array if a byte array was not provided to the MemoryStream constructor
during construction of the current instance.
</quote>
 
Jon Skeet [C# MVP] pisze:
The GetBuffer method would appear to be a pretty good indication that
it's just one array:
Click to expand...
And what happens when where comes more data? More than the capacity of
the array.
 
Doker said:
And what happens when where comes more data? More than the capacity of
the array.
Click to expand...

A new buffer is created to hold the previous contents and the new
contents. It's always in a single buffer though.
 
Jon Skeet [C# MVP] pisze:
A new buffer is created to hold the previous contents and the new
contents. It's always in a single buffer though.
Click to expand...
So what happens when i get the buffer and in the meantime some data
comes? New array is created and the data from the previous one is copied
into the new larger? That would be...
 
Doker pisze:
Jon Skeet [C# MVP] pisze:
A new buffer is created to hold the previous contents and the new
contents. It's always in a single buffer though.
Click to expand...
So what happens when i get the buffer and in the meantime some data
comes? New array is created and the data from the previous one is copied
into the new larger? That would be...
Click to expand...
Okey, i've checked it.
It should be allright as long as you lock on the buffer and pin it.
 
Doker said:
Doker pisze:
Jon Skeet [C# MVP] pisze:
The GetBuffer method would appear to be a pretty good indication
that it's just one array:
And what happens when where comes more data? More than the capacity
of the array.

A new buffer is created to hold the previous contents and the new
contents. It's always in a single buffer though.
Click to expand...
So what happens when i get the buffer and in the meantime some data
comes? New array is created and the data from the previous one is
copied into the new larger? That would be...
Click to expand...
Okey, i've checked it.
It should be allright as long as you lock on the buffer and pin it.
Click to expand...

Yes, if you change data that you use in more than one thread, you always
need to synchronise it.

Preferrably you should not lock on the buffer, but a separate private
object that is only used for the locking and nothing else. This prevents
deadlocks, and also the misconception that the lock statement protects
the object that is used for the lock in any way.

Note that when locking, you need to use it on all code that accesses the
stream, both the code that reads it and the code that writes it,
otherwise it's not doing any good at all.
 
Back
Top