Cannot take the address of, get the size of, or declare a pointer to a managed type

SantasNotReal picture SantasNotReal · Nov 8, 2012 · Viewed 26.5k times · Source

I've done a fair bit of research, but am stuck now as to why I'm still getting this error. I have a struct with the following attributes:

struct Account
{
    //private attributes
    private double mBalance;
    private int mAccountNumber;
    private string mName;
    private string mDateCreated;
}

and am trying to do the following:

class BankManager
{
    //private attributes
    private unsafe Account *mAccounts;
    private unsafe bool *mAccountsAvailable;
    private int mNumberAccounts;
}

Even after turning my class Account to a struct, using "unsafe" for the attributes in class BankManager, and telling the compiler it can use unsafe code (in properties -> Build), I'm still getting this error at

*mAccounts

Any ideas as to why? I'm pretty sure all the types I'm using in the struct are legal to have pointers to in c#. Thanks in advance!

Answer

Hans Passant picture Hans Passant · Nov 9, 2012

The strings in the Account class cause this problem. To understand why, you need to understand how the garbage collector works. It discovers garbage by tracking references to objects. The mName and mDateCreated are such references. The mBalance and mAccountNumber are not, those fields are value types. And, most importantly, the BankManager.mAccounts field is not, it is a pointer.

So the compiler can tell up front that the garbage collector will never be able to see the string references. Because the only way to do so is to go through the mAccount field and its not a reference.

The only cure for this is to limit yourself strictly to value types. The only way to do that for strings is to allocate them in unmanaged memory with, say, Marshal.StringToCoTaskMemUni() and store the IntPtr in the field. It is now out of reach from the garbage collector and cannot get moved by it. You'll now also have the burden of releasing that string.

Clearly that's not practical and prone to cause leaks, the kind of problem that's so common in C programs. Not sure why you are pursuing this at all but do keep in mind that a reference to an object is already a simple pointer so you are not gaining anything by using pointers yourself.