How to simulate a member reference tracking variable in C++/CLI?

This is going to be a really goofy question but is it possible to do the following in C++/CLI?

// C++/CLI
public ref class Managed
{
    public:
        array<double>^ m_data;
        Managed(array<double>^% data) : m_data(data)
        {
        }

        void bar(int x)
        {
            System::Array::Resize(m_data, x);
        }
};
// C#
static void Main(string[] args)
{
    double [] d = new double[10];
    Foo.Managed f = new Foo.Managed(d);
    f.bar(5);
}

Such that, after calling f.bar(5) from Main, Main::d and f.m_data are the same "reallocated" array? I've tried with unmanaged references, pointers, pin_ptr and so forth but nothing. Any ideas? If this is just not possible, is there a reason why?

Using the reference tracking operator (%) I could do that if I would to resize in the con开发者_Python百科structor, that's what it has kept me trying.

This is possible in C++ using references, unfortunately I don't know how to cast a array^ to array^& nor I can use array^% as a member:

class Foo{
public:
    double *& m_data;
    Foo(double*& data): m_data(data)
    {
    }

    void bar(int x)
    {
        delete m_data;
        m_data = new double[x];
    }

    ~Foo(){
        delete [] m_data;
    }
};

int _tmain(int argc, _TCHAR* argv[])
{

    double* data = new double[10];

    Foo f(data);
    std::cout << &data << "\n" << &f.m_data << "\n";
    f.bar(5);
    std::cout << &data << "\n" << &f.m_data;
    getchar();
    return 0;
}

---

This is not possible, because references are stored by value: that is, the CLR does not support by-ref member fields. (Eric Lippert discusses why here (around the second list of bullet points).) So although d is passed by reference into Managed's constructor, when Managed stores this in m_data, that takes a copy of Main's reference to the size-10 array, and this copy is now independent of the original. The bar function passes f's m_data reference -- which is a now independent copy of Main's reference -- into Array::Resize, which modifies m_data to refer to a new size-5 array. But because m_data is an independent copy, that doesn't affect Main.d -- that still refers to the size-10 array.

A possible alternative strategy is to encapsulate the array reference in a small shim class, and have Main create (and Foo.Managed accept) an instance of the shim class instead. Then bar could resize the array pointed to by the shim. Because Main.d and f.m_data would still be references to the same shim (and would thereby share a single reference to the real array), Main.d would see the resized array (through the shim).