Array in memory


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 3 123 LastLast
Results 1 to 15 of 33

Thread: Array in memory

  1. #1
    Mike Guest

    Array in memory


    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

  2. #2
    Mattias Sjögren Guest

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


    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

  3. #3
    Mattias Sjögren Guest

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


    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

  4. #4
    Mike Guest

    Re: Array in memory


    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



  5. #5
    Mike Guest

    Re: Array in memory


    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



  6. #6
    David Crowell Guest

    Re: Array in memory

    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





  7. #7
    David Crowell Guest

    Re: Array in memory

    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





  8. #8
    Anthony Jones Guest

    Re: Array in memory

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



  9. #9
    Anthony Jones Guest

    Re: Array in memory

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



  10. #10
    Michael \(michka\) Kaplan Guest

    Re: Array in memory

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




  11. #11
    Michael \(michka\) Kaplan Guest

    Re: Array in memory

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




  12. #12
    Mike Guest

    Re: Array in memory


    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

    >
    >
    >



  13. #13
    Mike Guest

    Re: Array in memory


    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

    >
    >
    >



  14. #14
    Jonathan Wood Guest

    Re: Array in memory

    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



  15. #15
    Jonathan Wood Guest

    Re: Array in memory

    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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center