当前位置：首页 > news >正文

C#调用C++可变参数函数的实战指南与避坑策略

news 2026/7/22 6:16:10

1. 项目概述：为什么要在C#里调用C++的可变参数函数？

在混合语言开发的项目里，尤其是涉及到性能敏感的计算模块、图形渲染引擎或者需要复用大量遗留C/C++代码库的场景，C#调用C++函数是家常便饭。大部分时候，我们处理的是参数类型和数量都固定的函数，通过P/Invoke（平台调用）或者C++/CLI包装一下，流程还算清晰。但当你看到C++那边给你一个带着省略号（...）的函数声明时，比如经典的int printf(const char* format, ...);，头可能就大了。这玩意儿在C#里怎么整？直接DllImport一个printf？编译器第一个不答应。

这就是我们今天要啃的硬骨头：如何在C#中安全、正确地调用C++里使用可变参数（Variadic Arguments）的函数。这不仅仅是技术上的“能调用”，更是关于如何保证内存安全、参数传递正确、避免程序崩溃的实战课题。无论是你需要集成一个用C++写的、支持灵活格式的日志库，还是调用一个像sscanf这样需要解析不定数量输入的函数，掌握这套方法都能让你在混合编程的深水区里游刃有余。接下来，我会带你从原理到实操，一步步拆解这个过程中的所有核心环节和隐藏的“坑”。

2. 核心原理与挑战拆解

在动手写代码之前，我们必须搞清楚两件事：C++的可变参数是怎么工作的，以及C#调用本地代码的基本规则。只有理解了底层机制，你才能明白为什么有些方法行不通，而正确的方法又为何是那样设计的。

2.1 C++可变参数函数的本质

C++的可变参数函数，其核心在于stdarg.h头文件（C++中也可用<cstdarg>）里定义的一组宏：va_list,va_start,va_arg,va_end。它的工作方式可以简单理解为“盲人摸象”：

约定一个已知起点：函数至少需要一个固定参数（通常用来指明后续可变参数的数量或类型，如printf的格式字符串）。va_start宏利用这个最后一个固定参数的地址，计算出可变参数列表在内存中的起始位置。
按照约定去“摸”：va_arg宏根据你指定的类型，从当前va_list指针指向的内存中，“取出”相应大小的数据，并将指针向后移动。这里没有任何运行时类型检查，完全依赖调用者传入的格式字符串或其它约定来保证类型匹配。如果类型指定错了，读出来的就是垃圾数据，或者直接导致内存访问越界。
清理现场：va_end宏执行必要的清理工作。

关键点在于，可变参数的传递遵循特定的调用约定（Calling Convention）和应用程序二进制接口（ABI）。在x86/x64平台上，前几个整数/指针参数通常通过寄存器传递，多余的和浮点参数则通过栈来传递。编译器负责按照这个规则把参数“摆放”到正确的位置。当我们从C#跨语言调用时，必须让.NET的互操作层也按照完全相同的规则来摆放参数，否则C++函数读到的就是错乱的数据。

2.2 C# P/Invoke的局限与突破口

C#通过DllImport特性进行平台调用，其本质是让.NET运行时准备好参数，然后进行一次上下文切换，去执行本地代码。DllImport在声明函数签名时，要求参数类型和数量是编译时确定的。它无法直接表示一个C风格的...。

那么，常见的错误尝试有哪些呢？

尝试一：在DllImport中使用params关键字。
```
[DllImport("MyLib.dll")] public static extern int MyVariadicFunc(string format, params object[] args); // 错误！
```
这完全行不通。params是C#语言级别的语法糖，用于简化托管代码内部的调用。在生成本地调用桩（stub）时，P/Invoke根本不理解它，也不知道如何将object[]转换成对应的原生内存布局。

尝试二：声明多个不同参数数量的重载。

[DllImport("MyLib.dll")] public static extern int Func(string a); [DllImport("MyLib.dll")] public static extern int Func(string a, int b); [DllImport("MyLib.dll")] public static extern int Func(string a, int b, string c); // ... 无穷无尽

理论上，如果可变参数类型固定且数量有限，这或许能勉强工作，但极其笨拙且难以维护，完全违背了可变参数的初衷。

所以，正确的突破口不在于让C#直接模仿C++的语法，而在于**“模拟”或“绕过”**可变参数的传递过程。主流且可靠的方法有两种：

使用C++/CLI编写一个包装层：创建一个托管C++项目，在其中编写一个拥有固定签名的托管函数，这个函数内部再调用真正的可变参数C++函数。这是最强大、最灵活的方式。
在C#端手动构建参数栈/数组：利用__arglist关键字（仅限x86）或更通用的System.Runtime.InteropServices中的高级功能，手动模拟参数传递。这种方式更底层，挑战更大。

注意：对于新手或者追求稳定性的项目，我强烈推荐方法一（C++/CLI包装）。它虽然增加了一个中间层，但能提供完整的类型安全性和调试便利性，是工程实践中的首选。方法二更像是一种高级技巧或对特定历史遗留问题的解决方案。

3. 方案一：使用C++/CLI创建托管包装层（推荐）

这是最标准、最受控的方案。C++/CLI是一门特殊的.NET语言，它允许你在同一个项目里混合编写托管代码和原生C++代码，并且能无缝地进行互操作。我们可以用它创建一个“桥接”DLL，对C#暴露一个干净的托管API，内部则处理肮脏的可变参数细节。

3.1 创建C++/CLI类库项目

首先，在Visual Studio中新建一个“C++ CLR 类库(.NET Framework)”或“C++ CLR 类库(.NET Core/.NET 5+)”项目，命名为NativeWrapper。

项目创建后，确保项目属性中“公共语言运行时支持”设置为“公共语言运行时支持(/clr)”。对于.NET Core/5+项目，可能需要选择“公共语言运行时支持(通用)”或类似的选项。

3.2 编写包装函数

假设我们有一个名为MyNativeLib.dll的原生DLL，其中包含一个可变参数函数：

// 原生C++头文件声明 extern "C" __declspec(dllexport) int __cdecl MyLog(const char* category, const char* format, ...);

我们的目标是让C#能像这样调用：Wrapper.Log("Network", "Received %d packets from %s.", packetCount, ipAddress);

在C++/CLI项目中，我们添加一个头文件NativeWrapper.h和一个源文件NativeWrapper.cpp。

NativeWrapper.h:

#pragma once using namespace System; namespace NativeWrapper { public ref class Logger sealed // ref class 表示托管类，sealed表示不可继承 { public: // 托管方法，拥有固定签名 static int Log(String^ category, String^ format, ...array<Object^>^ args); }; }

NativeWrapper.cpp:

#include "pch.h" // 预编译头 #include "NativeWrapper.h" #include <cstdarg> #include <vcclr.h> // 用于pin_ptr // 引入原生DLL的函数声明 extern "C" __declspec(dllimport) int __cdecl MyLog(const char* category, const char* format, ...); namespace NativeWrapper { int Logger::Log(String^ category, String^ format, ...array<Object^>^ args) { if (category == nullptr || format == nullptr) { return -1; // 错误处理 } // 关键步骤1：将托管字符串转换为原生C字符串。 // pin_ptr 在转换期间固定内存，防止GC移动对象。 pin_ptr<const wchar_t> wchCategory = PtrToStringChars(category); pin_ptr<const wchar_t> wchFormat = PtrToStringChars(format); // 将宽字符串（Unicode）转换为窄字符串（ANSI/UTF-8）。这里简单用ANSI，实际项目应考虑UTF-8。 size_t convertedChars = 0; size_t catLen = wcslen(wchCategory) + 1; size_t fmtLen = wcslen(wchFormat) + 1; char* nativeCategory = new char[catLen]; char* nativeFormat = new char[fmtLen]; wcstombs_s(&convertedChars, nativeCategory, catLen, wchCategory, _TRUNCATE); wcstombs_s(&convertedChars, nativeFormat, fmtLen, wchFormat, _TRUNCATE); // 关键步骤2：准备可变参数列表。 // 我们不能直接将托管对象数组传递给va_start。必须根据format字符串解析，并准备一个原生参数列表。 // 这是一个简化示例，假设args只包含int和char*（String^）类型。 // 在实际项目中，你需要一个更复杂的解析器，类似于printf的实现。 // 这里演示一个简单（且不安全）的版本：假设所有参数都是int。 // 正确做法是解析format字符串中的格式说明符（%d, %s等）。 va_list argList; va_start(argList, nativeFormat); // 注意：va_start针对的是“原生”的format和栈 // 我们需要手动将托管args中的值，按照原生方式“推”到argList对应的内存位置。 // 这非常棘手，因为va_list是编译器实现的内部结构。 // 更实用的方法是：放弃使用va_list，而是根据参数数量和类型，直接调用不同的MyLog重载（如果你能修改原生库）或使用其他方法。 // 鉴于直接操作va_list在C++/CLI中极其复杂且不稳定，我们换一种思路： // 如果原生函数是我们自己编写的，可以为其添加一个“v”版本（vprintf风格）。 // 例如：int MyLogV(const char* category, const char* format, va_list args); // 这样，我们就可以在C++/CLI中安全地使用va_list了。 // 假设我们拥有 MyLogV 函数。 // int result = MyLogV(nativeCategory, nativeFormat, argList); // 需要MyLogV存在 // 由于演示目的，我们采用一个更可行的“穷举”包装方法（适用于参数类型和数量有限的情况）： int result = -1; switch (args->Length) { case 0: result = MyLog(nativeCategory, nativeFormat); break; case 1: // 需要根据args[0]的实际类型进行转换和调用 // 例如，如果是int: if (args[0]->GetType() == int::typeid) { int arg0 = safe_cast<int>(args[0]); result = MyLog(nativeCategory, nativeFormat, arg0); } // 如果是string: else if (args[0]->GetType() == String::typeid) { String^ managedStr = safe_cast<String^>(args[0]); pin_ptr<const wchar_t> wchArg = PtrToStringChars(managedStr); char* nativeArg = new char[wcslen(wchArg) + 1]; wcstombs_s(&convertedChars, nativeArg, wcslen(wchArg) + 1, wchArg, _TRUNCATE); result = MyLog(nativeCategory, nativeFormat, nativeArg); delete[] nativeArg; } break; case 2: // 类似地处理两个参数... 代码会迅速膨胀。 break; default: // 参数太多，不支持 break; } va_end(argList); delete[] nativeCategory; delete[] nativeFormat; return result; } }

实操心得：上面的代码揭示了核心矛盾。直接包装一个通用的可变参数函数非常困难，因为C++/CLI虽然能混合代码，但无法安全地“构造”一个给纯C++函数使用的va_list。最有效的策略是修改或要求原生库提供一个“v”系列的函数（如MyLogV），它接受一个va_list参数。这样，在C++/CLI包装器中，我们可以先使用托管代码的params或数组收集参数，然后在同一编译单元内（即同一个.cpp文件里）调用这个“v”函数，此时va_list的创建和使用是编译器内部一致完成的。

3.3 为原生库添加“v”版本函数（理想情况）

如果原生库是你维护的，这是最佳实践。为每个可变参数函数添加一个对应的“v”版本。

原生库头文件 (MyNativeLib.h):

#ifdef MYNATIVELIB_EXPORTS #define MYAPI __declspec(dllexport) #else #define MYAPI __declspec(dllimport) #endif extern "C" { MYAPI int __cdecl MyLog(const char* category, const char* format, ...); MYAPI int __cdecl MyLogV(const char* category, const char* format, va_list args); // 新增的V版本 }

原生库实现文件 (MyNativeLib.cpp):

#include "MyNativeLib.h" #include <cstdarg> #include <iostream> int __cdecl MyLog(const char* category, const char* format, ...) { va_list args; va_start(args, format); int result = MyLogV(category, format, args); // 复用V版本 va_end(args); return result; } int __cdecl MyLogV(const char* category, const char* format, va_list args) { // 实际的日志逻辑在这里实现 printf("[%s] ", category); int result = vprintf(format, args); printf("\n"); return result; }

3.4 编写调用“v”版本的C++/CLI包装器

有了MyLogV，C++/CLI包装器就变得清晰和安全：

NativeWrapper.cpp (修订版):

#include "pch.h" #include "NativeWrapper.h" #include <cstdarg> #include <vcclr.h> // 引入原生DLL的V函数声明 extern "C" __declspec(dllimport) int __cdecl MyLogV(const char* category, const char* format, va_list args); namespace NativeWrapper { int Logger::Log(String^ category, String^ format, ...array<Object^>^ args) { if (category == nullptr || format == nullptr) { return -1; } // 转换字符串 pin_ptr<const wchar_t> wchCategory = PtrToStringChars(category); pin_ptr<const wchar_t> wchFormat = PtrToStringChars(format); size_t convertedChars = 0; size_t catLen = wcslen(wchCategory) + 1; size_t fmtLen = wcslen(wchFormat) + 1; char* nativeCategory = new char[catLen]; char* nativeFormat = new char[fmtLen]; wcstombs_s(&convertedChars, nativeCategory, catLen, wchCategory, _TRUNCATE); wcstombs_s(&convertedChars, nativeFormat, fmtLen, wchFormat, _TRUNCATE); int result = -1; // 关键：我们需要根据args数组，构造一个va_list。 // 这只能在理解format字符串的前提下进行。这里演示一个极度简化的场景：假设所有参数都是int。 // 一个完整的实现需要解析format字符串中的每一个格式说明符。 // 简化版实现（仅处理%d）： // 由于我们无法动态构造一个标准的va_list，这里采用另一种思路： // 如果参数类型和数量是有限的，我们可以直接调用原生的、参数数量固定的重载。 // 但既然有了MyLogV，我们可以尝试一种“欺骗”编译器的方法：使用内联汇编或编译器内置函数？不，这不可移植且危险。 // 更实际的做法：放弃在C++/CLI中构造va_list，转而调用一系列我们预先用原生C++写好的、针对不同参数数量的辅助函数。 // 例如，在原生DLL中提供： // int MyLogHelper1(const char* cat, const char* fmt, int a1); // int MyLogHelper2(const char* cat, const char* fmt, int a1, int a2); // int MyLogHelperS1(const char* cat, const char* fmt, const char* a1); // ... // 结论：即使有V版本，在托管环境中通用地包装可变参数函数依然非常复杂。 // 对于不可修改的黑盒DLL，最稳健的C++/CLI方案是“穷举包装”。 // 对于可修改的DLL，最佳方案是提供针对常用参数组合的、非可变的辅助函数。 delete[] nativeCategory; delete[] nativeFormat; return result; } }

看到这里你可能有点晕，这恰恰说明了问题的复杂性。在工程实践中，如果遇到一个黑盒的可变参数DLL函数，并且你必须从C#调用，最可行的C++/CLI方案是“有限穷举包装”。也就是为你会用到的几种参数组合（例如：一个int；一个string；一个int加一个string），分别编写一个原生的辅助函数（非可变参数）或一个C++/CLI包装函数。虽然不优雅，但它是可靠和可维护的。

3.5 在C#项目中引用并调用

编译你的C++/CLI项目，生成NativeWrapper.dll（或.netmodule）。
在你的C#主项目（如一个控制台应用）中，添加对NativeWrapper.dll的引用。
同时，确保MyNativeLib.dll放在C#应用程序的执行目录下。
在C#代码中调用：

using NativeWrapper; class Program { static void Main(string[] args) { // 调用我们包装的Logger.Log方法 // 注意：我们的简化包装器可能只支持特定类型和数量的参数 // 例如，假设我们只实现了处理 (string, string, int) 的重载 int ret = Logger.Log("App", "Processed %d items.", 42); Console.WriteLine($"Log returned: {ret}"); } }

4. 方案二：在C#中使用低级互操作技术（高级/特定场景）

如果你不能或不想引入C++/CLI项目，并且主要工作在x86平台（因为__arglist的局限性），可以尝试此方案。这需要深入理解调用约定和内存布局。

4.1 使用`__arglist`关键字（仅限x86，已过时）

C#编译器有一个鲜为人知的关键字__arglist，它允许你声明一个类似C风格可变参数的函数，并且使用__arglist、__refvalue、__makeref等关键字来访问参数。注意：此特性不被CLS（公共语言规范）兼容，且仅在x86的默认调用约定（__cdecl）下有效，x64不支持。微软官方也不推荐在新项目中使用。

using System; using System.Runtime.InteropServices; class Program { // 声明一个使用__arglist的DllImport。调用约定必须是Cdecl。 [DllImport("MyNativeLib.dll", CallingConvention = CallingConvention.Cdecl)] public static extern int MyLog(string format, __arglist); // 只能有一个固定参数 static void Main() { // 调用时使用__arglist关键字传递额外参数 int result = MyLog("Test %d %s\n", __arglist(123, "hello")); Console.WriteLine(result); } }

为什么这能工作？在x86的__cdecl约定下，调用者负责清理栈。__arglist告诉C#编译器以与C编译器兼容的方式，将后续的参数压栈。然而，这种方法有巨大限制：参数类型转换非常脆弱（如字符串需要手动处理为IntPtr），完全缺乏类型安全，且x64不可用。强烈不建议在现代项目中使用。

4.2 使用`System.Runtime.InteropServices.Marshal`和委托动态构建调用

这是一种更通用但更复杂的方法，核心思想是：在运行时，根据参数动态构造一个函数指针，然后通过委托调用。这涉及到Marshal.GetDelegateForFunctionPointer和Marshal.AllocHGlobal等低级操作。

步骤概述：

使用LoadLibrary和GetProcAddress获取原生函数指针。
根据你计划传递的参数类型和数量，在运行时“拼装”出一个正确的函数签名对应的委托类型。
将参数值转换为非托管内存块。
使用一些极其底层的技巧（如内联汇编或预编译的汇编桩）来执行调用。或者，更现实的做法是，为有限的几种签名预定义好委托。

由于此方法极其复杂、易错，且严重依赖平台和架构，除非你有非常特殊的底层交互需求（如编写通用Hook框架），否则应避免使用。它超出了大多数应用开发者的合理需求范围。

5. 实战总结与避坑指南

经过上面的剖析，我们可以得出一些清晰的结论和实操建议。

5.1 方案选择决策树

面对“C#调用C++可变参数函数”的需求，你可以遵循以下决策路径：

目标DLL是否可由你修改？
- 是：恭喜，这是最优情况。立即为每个可变参数函数添加一个对应的V版本（如MyLogV）。然后在C++/CLI包装器中，可以相对安全地调用这个V版本。这是首选方案。
- 否：进入下一步。
你需要调用的参数组合是否固定且数量有限（例如，不超过3种）？
- 是：采用C++/CLI“穷举包装”方案。为每一种你用到的参数类型和数量组合，在C++/CLI中编写一个专门的包装函数。虽然代码有些重复，但稳定可靠。
- 否（参数组合多变或未知）：情况变得棘手。你需要评估：
  - 平台是否仅限于x86？项目是否接受使用已过时的技术？
    - 是：可以谨慎尝试__arglist，但要做好调试和崩溃的准备。
    - 否：强烈建议重新设计。考虑是否真的必须直接调用这个可变参数函数。能否在C++侧封装一个固定参数的接口？能否用其他方式（如文件、管道、Socket）进行进程间通信？直接调用一个黑盒的、参数多变的可变参数函数，在C#端几乎是一个无法完美解决的任务。

5.2 核心避坑点

字符串编码陷阱：C#字符串是Unicode（UTF-16），而大多数C++可变参数函数（如printf）期望的是ANSI（本地代码页）或UTF-8字符串。在C++/CLI中使用pin_ptr和wcstombs_s转换时，务必考虑编码一致性。对于现代项目，优先在C++侧使用宽字符版本（wprintf）或显式处理UTF-8。
调用约定必须匹配：C++函数是__cdecl还是__stdcall？在DllImport或C++/CLI的extern声明中必须严格指定（CallingConvention.Cdecl或CallingConvention.StdCall）。不匹配会导致栈损坏，程序瞬间崩溃。
内存管理与GC：在C++/CLI中，pin_ptr用于在非托管代码执行期间固定托管对象的内存地址，防止垃圾回收器移动它。务必确保pin_ptr的生命周期只覆盖其被非托管代码使用的时段，过后应立即释放（离开作用域即可），以减少对GC性能的影响。
类型映射的精确性：int在C#和C++中可能都是32位，但long就不同（C#是64位，C++在Windows上是32位）。使用MarshalAs特性或C++/CLI中的安全转换（safe_cast）来确保类型大小和符号匹配。
可变参数函数的“不可知性”：这是最大的坑。C#端无法在编译时检查传递给可变参数函数的参数类型和数量是否与C++端期望的格式字符串匹配。任何不匹配都会导致未定义行为，通常表现为数据错乱或访问违规。唯一的防御手段是在C++/CLI包装层进行严格的参数验证和转换。

5.3 一个更实际的替代思路：重新设计接口

很多时候，我们执着于调用一个现有的可变参数函数，可能是因为它是最方便的接口。但从系统设计的角度看，为跨语言调用设计一个“消息”或“请求”接口往往更健壮。例如：

结构化参数传递：让C++函数接受一个const char* format和一个const void* data_array，以及一个描述data_array中元素类型和数量的结构。C#端可以轻松地序列化参数到这个结构体中。
使用标准序列化格式：通过JSON、Protocol Buffers等格式在C#和C++之间传递复杂数据。C++侧提供一个接收字符串或字节流的固定参数函数。
包装为固定参数函数：在C++侧，围绕原有的可变参数函数，编写一系列参数固定的包装函数（如LogInt,LogString,LogIntAndString），供C#调用。

这些方法虽然增加了初期的工作量，但彻底解决了跨语言可变参数调用的根本性难题，带来了更好的类型安全性和可维护性。

6. 常见问题排查与调试技巧

即使按照最佳实践操作，混合编程的调试依然令人头疼。这里记录几个我踩过坑后总结的排查技巧。

问题：调用后程序立即崩溃，错误代码为 0xC0000005 (访问冲突)。
- 排查思路：
  1. 调用约定：这是头号嫌疑犯。确认DllImport或C++/CLI extern声明的调用约定与DLL导出函数的约定完全一致。用Dependency Walker或dumpbin /exports查看DLL的导出函数名，注意修饰名（如_MyLog@4是__stdcall）。
  2. 参数堆栈清理：对于__cdecl，调用者清理栈；对于__stdcall，被调用者清理。如果约定错了，栈指针就会错乱。
  3. 字符串内存：确保传递给C++的字符串指针在调用期间有效。在C++/CLI中是否正确使用了pin_ptr？在纯P/Invoke中，默认的MarshalAs(LPStr)可能会在调用返回前就释放临时内存吗？（对于[In]参数通常不会，但需确认）。
- 调试工具：在Visual Studio中，同时调试托管代码和本机代码。在C++/CLI包装函数和原生C++函数内部设置断点，观察参数值是否正确传递。
问题：函数执行成功，但输出的内容乱码或完全不对。
- 排查思路：
  1. 字符串编码：99%是编码问题。确认C#端的字符串在传递给C++时，其编码（ANSI, UTF-8, WideChar）是否符合C++函数的预期。在C++/CLI中，使用wcstombs_s转换到ANSI时，注意代码页。对于中文等非ASCII字符，强烈建议统一使用UTF-8，并在C++侧使用MultiByteToWideChar/WideCharToMultiByte或类似库进行转换。
  2. 格式字符串与参数不匹配：检查C#端传入的参数类型和顺序，是否与C++端format字符串中的格式说明符（%d,%s,%f）严格匹配。一个%s对应的是一个char*的地址，如果你传了一个int的地址进去，就会把整数当内存地址去读，必然崩溃或乱码。
问题：在C++/CLI项目中链接原生DLL时出现“无法解析的外部符号”错误。
- 排查思路：
  1. 导出声明：确认原生DLL的头文件中，函数声明是否正确使用了__declspec(dllexport)（在编译DLL时）和extern "C"（防止C++名称修饰）。
  2. 链接库：在C++/CLI项目的属性中，“链接器”->“输入”->“附加依赖项”里，是否添加了原生DLL对应的.lib文件？或者，你是否在源代码中使用#pragma comment(lib, "MyNativeLib.lib")？
  3. 路径：确保.lib文件的路径在“链接器”->“常规”->“附加库目录”中设置正确。
问题：在x64环境下，使用某些技巧（如__arglist）失效。
- 根本原因：x86和x64的调用约定有本质不同。x64下前几个参数通过寄存器传递，而不是全部压栈。许多针对x86栈布局的技巧在x64上完全不适用。
- 解决方案：放弃针对特定架构的Hack方案。回归到使用C++/CLI包装或重新设计接口的稳健道路上。

我个人在实际项目中，处理过一个古老的日志库，它只提供了一个Log(const char* fmt, ...)接口。最初尝试用各种奇技淫巧从C#调用，结果调试时间远超开发时间。最后，我花了半天时间，在C++侧为其添加了五个最常用的固定参数重载（LogInt,LogString,LogIntString等），并通过C++/CLI暴露给C#。虽然代码有点重复，但自此之后，这个模块再也没出过问题。这个经历让我深刻体会到，在软件工程中，清晰和可靠远比“炫技”重要。面对可变参数这个“刺头”，如果无法从根源（C++侧）将其“驯化”，那么在边界（C++/CLI包装层）进行有限制的、明确的封装，是性价比最高的选择。

查看全文

http://www.jsqmd.com/news/1232811/