locked
Managed array of pointers to elements in another managed array RRS feed

  • Question

  • Hello,

    I have some problems using arrays (system.array) in managed code. I have a two-dimensional array available and I would like to sort the values in this array by making a second, jagged array of pointers to the elements in the first array.

    However, there are some problems: the first array is of course declared on the managed heap. Pointers to elements in that array can change as the CLR rearranges the heap. The solution to this is could be an interior_ptr (which makes sure the pointer is updated when the heap is rearranged) or a pin_ptr (which makes sure the 'pointed' part of the heap isn't rearranged).
    The problem is that both pointers are only declared on the local stack: it is not allowed to form an array of pin_ptr or interior_ptr pointers.

    My question is: what is the way to implement this in managed code? Or is it impossible and should I use a piece of unmanaged code to solve my problem? Or am I completely missing the point here?

    Kind regards,

    Maikel

    Tuesday, October 10, 2006 11:01 AM

Answers

  • Sarath, your post is not helpful whatsoever.  You should take time to read the question before answering.

    Korenwolf, you are right: you can't put a pinned pointer on the managed heap (it cannot be part of a class).  If I understand you correctly, you are maintaining a separate array that points to the original array that can be sorted.  This is called an indexing array.  Instead of having it contain pointers, have you considered letting them contain integer indices instead?

    Tuesday, October 10, 2006 11:36 AM

All replies

  • Sometimes this may help you
    Tuesday, October 10, 2006 11:27 AM
  • Sarath, your post is not helpful whatsoever.  You should take time to read the question before answering.

    Korenwolf, you are right: you can't put a pinned pointer on the managed heap (it cannot be part of a class).  If I understand you correctly, you are maintaining a separate array that points to the original array that can be sorted.  This is called an indexing array.  Instead of having it contain pointers, have you considered letting them contain integer indices instead?

    Tuesday, October 10, 2006 11:36 AM
  • Hello Brain, yes, I considered to use the indices; the problem is that the first array is 2-dimensional. Then, I should store 2 indices every time (or use one index and do some calculations) in the sorted array. Actually, I "decided" that there must be a way to get and store the pointers. But it seems more and more likely that doing that is impossible.

    Tuesday, October 10, 2006 11:47 AM
  • Hi,

    If you want to sort the values of an array, why you do not use "Sort()" method of "Array" class?

    Regards.

    Tuesday, October 10, 2006 1:06 PM
  • That is because I do not want to disturb the original array. I want a method to access specific elements of it, without having to search for them in the entire array every time. The way to do this is a jagged array (an array of arrays) with pointers to elements in the original 2 dimensional array. That is not very difficult in normal C++, but I'm wondering if and how it's possible to implement this with managed types.
    Tuesday, October 10, 2006 1:26 PM
  • There should be no difference between using a pointer to an element and an integer index to it, other than saving a few instructions in the language where pointers are possible.  Could you elaborate more why this is a problem?
    Tuesday, October 10, 2006 2:39 PM
  • The first array is a two dimensional one; that means I would have to store two indices (expanding the necessary amount of memory) or one index (like j*arraywidth+i) but with the result that I need more computation time (integer division + modulo) to calculate the original two indices. Of course, I could also store the first array in one dimension. That would also solve the problem, but at the cost of the convenient 2-dimensional array solution the CLR is offering me.

    My point is: in plain C++ it could have been implemented easily. In fact, I already did that in order to be able to proceed with my project. As a former user of BCB, over the last half year I have grown to like the managed code idea very much; I just cannot imagine that there isn't a better solution for my problem.

    Wednesday, October 11, 2006 8:07 AM
  • Okay, so we are on the same page that direct cell pointers and cell offsets are equivalent functionally, but one is faster than the other.

    Suppose you rewrote your 2-D array and associated methods in C++ and wrap it with C++/CLI?

     

    Wednesday, October 11, 2006 2:49 PM
  • More or less: if you mean that I declared my arrays in normal memory (like unsigned char *array = new unsigned char[100];) and deleted them properly after use, then yeah, that's what I did. Actually, I was surprised that I could compile a program like that with the /clr:pure switch.
    Wednesday, October 11, 2006 3:22 PM
  • I would be interested in an informal benchmark that compared the two approaches: a C-runtime heap array vs. a managed array (with necessary coding changes around it).
    Wednesday, October 11, 2006 5:12 PM
  • How do you implement such a benchmark? Is that simply a case of taking the system time two times and subtract them? In that case, I can always try, of course.
    Thursday, October 12, 2006 7:26 AM
  • Yep, that's all you really need to do.  You would probably want to repeat your stuff in a loop many times to magnify the timing difference.
    Thursday, October 12, 2006 1:17 PM
  • Ok, then I'll try that tomorrow or Monday. Working day is almost over, here...
    Thursday, October 12, 2006 1:45 PM
  • Ok, here we are. I excuted my algorithm 100 times and measured the time it took. The unmanaged versions uses pointers in the jagged array pointing to elements in the 2-dimensional array. The managed version uses two managed arrays of unsigned ints to point to both indices in the 2-dimensional array. The implementation is quick and dirty and perhaps not even comparable, so no garantuees whatsoever!

    The results are an execution time of 18.3 seconds for the unmanaged version and an execution time of 41.0 seconds for the managed version. A second run yielded similar results. It seems the managed version is slower by a factor of 2; I must admit that I didn't expect it to be that high.

    Tuesday, October 17, 2006 3:23 PM