Unity 2017中C#与C++ UserInfo结构体映射问题咨询

First off, your struct mapping is mostly correct, but there are a few key fixes and best practices you need to implement to guarantee smooth data transfer between your C++ DLL and Unity's C# code. Let's break this down:

1. Fixing the C# Struct Definition #

Your current C# struct has a critical accessibility issue, plus a potential alignment tweak:

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi, Pack = 4)] // Explicit pack to match C++ default alignment
public struct UserInfo {
    public System.Int32 userID; // Make all fields public!
    public System.Int32 loginID;
    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]
    public string username;
    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 128)]
    public string signature;
    public long goldNum;
    public System.Int32 deskID;
}

• Public Fields: Your original C# struct had userID, loginID, and deskID as private. The .NET marshaler can't access private fields when converting between managed and unmanaged memory—this would cause silent data corruption or failures.
• Explicit Packing: Adding Pack = 4 aligns with the default 4-byte packing used by most Windows C++ compilers. Without this, if your C++ project uses a different packing setting (or if Unity's .NET runtime uses a default that differs), the struct memory layout will mismatch.

2. Verifying Struct Size Match #

A quick sanity check to confirm your mapping is correct:

• In C++, compile and run sizeof(UserInfo) to get the unmanaged struct size.
• In C#, run Marshal.SizeOf(typeof(UserInfo)) and compare the result.
  If the numbers don't match, you have a type mismatch or alignment issue. For your struct, the expected size (with 4-byte packing) should be:
  4 + 4 + 32 + 128 + 8 + 4 = 180 bytes

3. Critical Best Practices for Reliable Data Transfer #

• Strict Type Matching:
  • C++ long long is a 64-bit integer, which correctly maps to C# long (also 64-bit). Never use int or UInt64 here unless your C++ code explicitly uses those types.
  • C++ int maps to C# Int32—this is consistent on Windows (where both are 32-bit).
• String Safety:
  • Your C++ char arrays are null-terminated, so when writing to them in C++, ensure you don't exceed the array size (e.g., username can hold 31 characters plus a null terminator). Overflowing will corrupt adjacent fields.
  • The UnmanagedType.ByValTStr in C# correctly handles converting these fixed-size char arrays to managed strings, and vice versa.
• Calling Convention Consistency:
  When declaring your DLL imports in C#, match the calling convention used by your C++ functions. For example:

  // If your C++ function uses __stdcall (common for Windows DLLs)
  [DllImport("YourDLLName.dll", CallingConvention = CallingConvention.StdCall)]
  public static extern void GetUserInfo(out UserInfo info);
  
  // If your C++ function uses __cdecl
  [DllImport("YourDLLName.dll", CallingConvention = CallingConvention.Cdecl)]
  public static extern IntPtr GetUserInfoPtr();
  

  Mismatched calling conventions will cause stack corruption, crashes, or incorrect return values.
• Proper Pointer Handling:
  If your C++ function returns a pointer to a UserInfo struct, convert it safely in C#:

  IntPtr infoPtr = GetUserInfoPtr();
  UserInfo userInfo = Marshal.PtrToStructure<UserInfo>(infoPtr);
  // If the DLL allocates memory, make sure to free it via another exported function!
  

  Never forget to free unmanaged memory if your DLL allocates it—leaks will crash your Unity app over time.
• Test Edge Cases:
  Validate with extreme values:
  • Fill username and signature to their maximum allowed lengths.
  • Use the minimum/maximum values for goldNum, userID, etc.
    This ensures you catch any overflow or truncation issues early.

内容的提问来源于stack exchange，提问作者Obso_lu