Getting pointer to the memory of MemoryStream

[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 | Mowa jest srebrem |
| imagiATpsytranceDOTpl | a milczenie owiec. |

[Doker]

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?

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?

[Jon Skeet [C# MVP]]

Doker <do****@wp.plwrote:

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?

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?

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

[Doker]

Jon Skeet [C# MVP] pisze:

Doker <do****@wp.plwrote:

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

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?

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.

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

Doker <do****@wp.plwrote:

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.

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

[Doker]

Jon Skeet [C# MVP] pisze:

Doker <do****@wp.plwrote:

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

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]

Doker pisze:

Jon Skeet [C# MVP] pisze:

>Doker <do****@wp.plwrote:

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

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

Okey, i've checked it.
It should be allright as long as you lock on the buffer and pin it.

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Doker wrote:

Doker pisze:

>Jon Skeet [C# MVP] pisze:

>>Doker <do****@wp.plwrote:
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.

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

Okey, i've checked it.
It should be allright as long as you lock on the buffer and pin it.

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.

--
Göran Andersson
_____
http://www.guffa.com