Array in memory

[Mike]

I have read here a few times that it is not guaranteed that an array will
be continous (contiguous?) in memory. Is this true? Is it true that this
can be got around by putting the array in a UDT. Is this also true for strings?
Is there any way to tell where in memory an array goes?

Thanks in advance.

Mike

[Mattias Sjögren]

Mike,

>I have read here a few times that it is not guaranteed that an array will
>be continous (contiguous?) in memory. Is this true?

I've never seen a situation where the memory hasn't been in one single
contiguous chunk of memory. I think the SAFEARRAY (that's what a VB
array is in C++) requires that it is.

Of course, if it's an array of strings or objects, the array contains
only a pointer, and the real data can be spread in different places.


>Is there any way to tell where in memory an array goes?

VarPtr() on the first element of the array.


Mattias

__________________________________________________
Mattias Sjögren (MCP) - mattiass @ hem.passagen.se
VB+ http://hem.spray.se/mattias.sjogren/
Please send questions/replies to the newsgroups

[Mattias Sjögren]

Mike,

>I have read here a few times that it is not guaranteed that an array will
>be continous (contiguous?) in memory. Is this true?

I've never seen a situation where the memory hasn't been in one single
contiguous chunk of memory. I think the SAFEARRAY (that's what a VB
array is in C++) requires that it is.

Of course, if it's an array of strings or objects, the array contains
only a pointer, and the real data can be spread in different places.


>Is there any way to tell where in memory an array goes?

VarPtr() on the first element of the array.


Mattias

__________________________________________________
Mattias Sjögren (MCP) - mattiass @ hem.passagen.se
VB+ http://hem.spray.se/mattias.sjogren/
Please send questions/replies to the newsgroups

[Mike]

Mattias,

Thanks for your reply, again, it seams you always answer my tricky questions


>>Is there any way to tell where in memory an array goes?
>
>VarPtr() on the first element of the array.

What I meant, was were it goes when it becomes non-contiguous, but if it
does not become non contiguous...
If did a test of getting the VarPtr on each element in the array to see if
they were sequential. They always were.

But I read a post regarding filling an array quickly. Someone said that you
could not use the FillMemory API because the array may not be contiguous
(assuming the array is not an array of pointers).

Mike

mattiass.dont.want.spam@hem.passagen.se (Mattias Sjögren) wrote:
>Mike,
>
>>I have read here a few times that it is not guaranteed that an array will
>>be continous (contiguous?) in memory. Is this true?
>
>I've never seen a situation where the memory hasn't been in one single
>contiguous chunk of memory. I think the SAFEARRAY (that's what a VB
>array is in C++) requires that it is.
>
>Of course, if it's an array of strings or objects, the array contains
>only a pointer, and the real data can be spread in different places.
>
>
>>Is there any way to tell where in memory an array goes?
>
>VarPtr() on the first element of the array.
>
>
>Mattias
>
>__________________________________________________
>Mattias Sjögren (MCP) - mattiass @ hem.passagen.se
> VB+ http://hem.spray.se/mattias.sjogren/
> Please send questions/replies to the newsgroups

[Mike]

Mattias,

Thanks for your reply, again, it seams you always answer my tricky questions


>>Is there any way to tell where in memory an array goes?
>
>VarPtr() on the first element of the array.

What I meant, was were it goes when it becomes non-contiguous, but if it
does not become non contiguous...
If did a test of getting the VarPtr on each element in the array to see if
they were sequential. They always were.

But I read a post regarding filling an array quickly. Someone said that you
could not use the FillMemory API because the array may not be contiguous
(assuming the array is not an array of pointers).

Mike

mattiass.dont.want.spam@hem.passagen.se (Mattias Sjögren) wrote:
>Mike,
>
>>I have read here a few times that it is not guaranteed that an array will
>>be continous (contiguous?) in memory. Is this true?
>
>I've never seen a situation where the memory hasn't been in one single
>contiguous chunk of memory. I think the SAFEARRAY (that's what a VB
>array is in C++) requires that it is.
>
>Of course, if it's an array of strings or objects, the array contains
>only a pointer, and the real data can be spread in different places.
>
>
>>Is there any way to tell where in memory an array goes?
>
>VarPtr() on the first element of the array.
>
>
>Mattias
>
>__________________________________________________
>Mattias Sjögren (MCP) - mattiass @ hem.passagen.se
> VB+ http://hem.spray.se/mattias.sjogren/
> Please send questions/replies to the newsgroups

[David Crowell]

I have an app that would fail miserably if a dynamic byte array were not
contiguous. It appears that they always are. I would assume this of all
the basic data types (other than pointers, such as string, object, variant,
whatever).

Dave


> What I meant, was were it goes when it becomes non-contiguous, but if it
> does not become non contiguous...
> If did a test of getting the VarPtr on each element in the array to see if
> they were sequential. They always were.
>
> But I read a post regarding filling an array quickly. Someone said that
you
> could not use the FillMemory API because the array may not be contiguous
> (assuming the array is not an array of pointers).
>
> Mike

[David Crowell]

I have an app that would fail miserably if a dynamic byte array were not
contiguous. It appears that they always are. I would assume this of all
the basic data types (other than pointers, such as string, object, variant,
whatever).

Dave


> What I meant, was were it goes when it becomes non-contiguous, but if it
> does not become non contiguous...
> If did a test of getting the VarPtr on each element in the array to see if
> they were sequential. They always were.
>
> But I read a post regarding filling an array quickly. Someone said that
you
> could not use the FillMemory API because the array may not be contiguous
> (assuming the array is not an array of pointers).
>
> Mike

[Anthony Jones]

>>
I have read here a few times that it is not guaranteed that an array will
be continous (contiguous?) in memory.
<<

Perhaps what is being refered to here is that the 'body' of the array may
not always be contiguous with the SAFEARRAY structure.

Oleaut32.dll provides a couple of functions to create arrays. In one
scenario you already have a SAFEARRAY structure which you use (that is VB
can use) in a call to oleaut32 to allocate the array's 'body'. In this
case the memory allocated is unlikely to be contiguous with the SAFEARRAY
structure.

In another scenario you have a variable defined as a pointer to a SAFEARRAY
structure and make a call to oleaut32.dll which will both allocate and
configure a SAFEARRAY structure and allocate the memory required for the
'body'. In this case the structure and the 'body' are contiguous.

I'm not sure which of these VB uses or indeed whether it uses both.
However, that is probably unimportant. If you look at the definition of
the SAFEARRAY struct there is only one place for a pointer to the 'body'.
There is no provision for multiple pointers or some kind of linked list to
non-contigous chunks of memory being used for the body. Hence arrays are
most definitely contiguous. Of course, as has already been pointed out, it
could be a contigous set of pointers. :-)

--
Anthony Jones
Secta Group Ltd
AnthonyWJones@msn.com

[Anthony Jones]

>>
I have read here a few times that it is not guaranteed that an array will
be continous (contiguous?) in memory.
<<

Perhaps what is being refered to here is that the 'body' of the array may
not always be contiguous with the SAFEARRAY structure.

Oleaut32.dll provides a couple of functions to create arrays. In one
scenario you already have a SAFEARRAY structure which you use (that is VB
can use) in a call to oleaut32 to allocate the array's 'body'. In this
case the memory allocated is unlikely to be contiguous with the SAFEARRAY
structure.

In another scenario you have a variable defined as a pointer to a SAFEARRAY
structure and make a call to oleaut32.dll which will both allocate and
configure a SAFEARRAY structure and allocate the memory required for the
'body'. In this case the structure and the 'body' are contiguous.

I'm not sure which of these VB uses or indeed whether it uses both.
However, that is probably unimportant. If you look at the definition of
the SAFEARRAY struct there is only one place for a pointer to the 'body'.
There is no provision for multiple pointers or some kind of linked list to
non-contigous chunks of memory being used for the body. Hence arrays are
most definitely contiguous. Of course, as has already been pointed out, it
could be a contigous set of pointers. :-)

--
Anthony Jones
Secta Group Ltd
AnthonyWJones@msn.com

[Michael \(michka\) Kaplan]

VB does not guarantee a contiguous body (fwiw).

--
MichKa
(insensitive fruitarian)

random junk of dubious value, a multilingual website, the
54-language TSI Form/Report to Data Access Page Wizard,
and lots of replication "stuff" at the (no scripts required!)
http://www.trigeminal.com/


"Anthony Jones" <yadayadayada@msn.com> wrote in message
news:38eda6d8@news.devx.com...
> >>
> I have read here a few times that it is not guaranteed that an array will
> be continous (contiguous?) in memory.
> <<
>
> Perhaps what is being refered to here is that the 'body' of the array may
> not always be contiguous with the SAFEARRAY structure.
>
> Oleaut32.dll provides a couple of functions to create arrays. In one
> scenario you already have a SAFEARRAY structure which you use (that is VB
> can use) in a call to oleaut32 to allocate the array's 'body'. In this
> case the memory allocated is unlikely to be contiguous with the SAFEARRAY
> structure.
>
> In another scenario you have a variable defined as a pointer to a
SAFEARRAY
> structure and make a call to oleaut32.dll which will both allocate and
> configure a SAFEARRAY structure and allocate the memory required for the
> 'body'. In this case the structure and the 'body' are contiguous.
>
> I'm not sure which of these VB uses or indeed whether it uses both.
> However, that is probably unimportant. If you look at the definition of
> the SAFEARRAY struct there is only one place for a pointer to the 'body'.
> There is no provision for multiple pointers or some kind of linked list to
> non-contigous chunks of memory being used for the body. Hence arrays are
> most definitely contiguous. Of course, as has already been pointed out,
it
> could be a contigous set of pointers. :-)
>
> --
> Anthony Jones
> Secta Group Ltd
> AnthonyWJones@msn.com
>
>

[Michael \(michka\) Kaplan]

VB does not guarantee a contiguous body (fwiw).

--
MichKa
(insensitive fruitarian)

random junk of dubious value, a multilingual website, the
54-language TSI Form/Report to Data Access Page Wizard,
and lots of replication "stuff" at the (no scripts required!)
http://www.trigeminal.com/


"Anthony Jones" <yadayadayada@msn.com> wrote in message
news:38eda6d8@news.devx.com...
> >>
> I have read here a few times that it is not guaranteed that an array will
> be continous (contiguous?) in memory.
> <<
>
> Perhaps what is being refered to here is that the 'body' of the array may
> not always be contiguous with the SAFEARRAY structure.
>
> Oleaut32.dll provides a couple of functions to create arrays. In one
> scenario you already have a SAFEARRAY structure which you use (that is VB
> can use) in a call to oleaut32 to allocate the array's 'body'. In this
> case the memory allocated is unlikely to be contiguous with the SAFEARRAY
> structure.
>
> In another scenario you have a variable defined as a pointer to a
SAFEARRAY
> structure and make a call to oleaut32.dll which will both allocate and
> configure a SAFEARRAY structure and allocate the memory required for the
> 'body'. In this case the structure and the 'body' are contiguous.
>
> I'm not sure which of these VB uses or indeed whether it uses both.
> However, that is probably unimportant. If you look at the definition of
> the SAFEARRAY struct there is only one place for a pointer to the 'body'.
> There is no provision for multiple pointers or some kind of linked list to
> non-contigous chunks of memory being used for the body. Hence arrays are
> most definitely contiguous. Of course, as has already been pointed out,
it
> could be a contigous set of pointers. :-)
>
> --
> Anthony Jones
> Secta Group Ltd
> AnthonyWJones@msn.com
>
>

[Mike]

LOL! I am in the same situation, that is why I posted the question

Mike

"David Crowell" <davidc@qtm.net> wrote:
>I have an app that would fail miserably if a dynamic byte array were not
>contiguous. It appears that they always are. I would assume this of all
>the basic data types (other than pointers, such as string, object, variant,
>whatever).
>
>Dave
>
>
>> What I meant, was were it goes when it becomes non-contiguous, but if
it
>> does not become non contiguous...
>> If did a test of getting the VarPtr on each element in the array to see
if
>> they were sequential. They always were.
>>
>> But I read a post regarding filling an array quickly. Someone said that
>you
>> could not use the FillMemory API because the array may not be contiguous
>> (assuming the array is not an array of pointers).
>>
>> Mike
>
>
>

[Mike]

LOL! I am in the same situation, that is why I posted the question

Mike

"David Crowell" <davidc@qtm.net> wrote:
>I have an app that would fail miserably if a dynamic byte array were not
>contiguous. It appears that they always are. I would assume this of all
>the basic data types (other than pointers, such as string, object, variant,
>whatever).
>
>Dave
>
>
>> What I meant, was were it goes when it becomes non-contiguous, but if
it
>> does not become non contiguous...
>> If did a test of getting the VarPtr on each element in the array to see
if
>> they were sequential. They always were.
>>
>> But I read a post regarding filling an array quickly. Someone said that
>you
>> could not use the FillMemory API because the array may not be contiguous
>> (assuming the array is not an array of pointers).
>>
>> Mike
>
>
>

[Jonathan Wood]

Mike,

> But I read a post regarding filling an array quickly. Someone said that
you
> could not use the FillMemory API because the array may not be contiguous
> (assuming the array is not an array of pointers).

I think Mattias addressed this. The array *will* be contiguous. However, if
the array items hold strings or objects, etc., then only the pointers will
be part of that contiguous array and the actual data will be all over the
place.

So, yes. They are always contiguous. But may reference data outside the
array block, depending on the data types.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Mike,

> But I read a post regarding filling an array quickly. Someone said that
you
> could not use the FillMemory API because the array may not be contiguous
> (assuming the array is not an array of pointers).

I think Mattias addressed this. The array *will* be contiguous. However, if
the array items hold strings or objects, etc., then only the pointers will
be part of that contiguous array and the actual data will be all over the
place.

So, yes. They are always contiguous. But may reference data outside the
array block, depending on the data types.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com