简介面向股票软件二次开发者的WIN32动态链接库接口模板聚焦大智慧新一代公式系统外部扩展函数的C语言实现提供可直接参考的工程骨架适合具备C基础、希望为行情终端接入自定义指标或功能模块的开发者使用。整个压缩包仅6KB共6个文件以2个cpp源文件和2个h头文件为核心配合dsw工作区与dsp工程文件便于在VC环境中直接打开、编译与二次修改源码与头文件分工明确工程配置也一并保留省去从零搭建DLL项目的繁琐。已有1892人学习下载说明其在公式接口与外部函数扩展场景中具有一定参考价值。读者可从中了解外部扩展函数的声明与导出方式、StdAfx预编译头的组织以及最小化DLL工程结构既能作为调试接口调用、排查编译链接问题的起点也便于将模板迁移到自己的公式扩展项目中减少重复搭建环境的时间。1. 行情终端里的 C 语言接口公式不够用的那一步写公式写到第三年总会撞上一堵墙均线、MACD、布林这些内置函数随便拼可一旦要做跨周期校验、要读外部因子文件、要在公式里调用自己写的数值优化器公式语言就彻底不够用了。行情分析终端提供的 C 语言接口本质是把公式引擎的计算权交一部分出来——你编译一个动态库导出符合约定的函数公式里就能像调用 MA、EMA 一样调用它。这套 C 公式接口面向的是有 C/C 底子、需要把私有算法塞进行情终端的人做量化信号验证的、要复用已有 C 库的、嫌公式语言跑得慢的。下文统一用 DG 终端指代这类行情分析终端接口细节按通用约定描述具体版本以随包头文件为准。2. 接口签名定生死调用约定、参数指针与导出表接口设计里最容易拍脑袋、也最容易在半年后翻车的部分就是函数签名。行情终端调用你的 DLL 时它不知道你内部用了几个类、几个模板它只知道一个函数地址、三个参数、一个 double 返回值。任何超出这个约定的东西——异常、C 对象、STL 容器、跨 DLL 的 new/delete——都会在某个用户的机器上炸掉而且往往炸在终端进程里连带用户正在看的行情一起没了。所以第一件事不是写算法是把契约头文件钉死。我的习惯是先写一个dgfunc.h让 DLL 工程和自测宿主工程共用它任何一方改动都必须同步重新编译两边。2.1 三个参数定架构参数个数、参数数组、计算上下文宿主的调用模型通常是这样的公式里写了一行MYMA(CLOSE, 20)引擎解析出函数名MYMA、参数个数 2然后按 K 线逐根调用你导出的函数每次告诉你现在算到第几根。序列数据不通过参数数组传而是放在一个只读上下文结构体里由宿主填充。/* dgfunc.h —— 公式函数接口的唯一契约头文件DLL 与自测宿主共用 */ #ifndef DGFUNC_H #define DGFUNC_H #ifdef __cplusplus extern C { #endif /* 32 位宿主必须 __stdcall64 位下该修饰被忽略但保留写法便于两套二进制共存 */ #ifdef _WIN32 # define DG_CALL __stdcall #else # define DG_CALL #endif /* 计算上下文宿主填充DLL 只读。禁止修改内容禁止把指针存起来下次用 */ typedef struct tagDGCalcCtx { int nDataLen; /* 当前数据集 K 线总根数可能随时变化 */ int nCurIndex; /* 本次调用的位置0 表示第一根 K 线 */ const double* pOpen; /* 以下序列长度均等于 nDataLen可能为 NULL */ const double* pHigh; const double* pLow; const double* pClose; const double* pVol; int nPeriod; /* 周期标识日线/分钟线由宿主给出仅作参考 */ void* pReserved; /* 保留字段必须忽略不要强转成任何结构体 */ } DGCalcCtx; /* 导出函数的统一签名公式端按导出名调用 */ typedef double (DG_CALL *PFN_DG_CALC)(int nParamCount, const double* pParams, const DGCalcCtx* pCtx); #ifdef __cplusplus } #endif #endif三个参数的分工要背下来nParamCount是公式里实际写了几项pParams是这封装换好的 double 数组含第一项通常用来传序列或标量pCtx是行情数据和时间位置的唯一来源。几个参数上的血泪经验值得单独说。nParamCount一定要做上下界双重校验公式作者写错参数个数是家常便饭少传一个你按pParams[1]取值就是越界读多传一个你少读一项也不报错但结果对不上。pCtx-nDataLen不是常量用户切换周期、切换品种、拉长历史区间都会变任何长度的缓存都要带版本号或长度戳。pReserved现在没用不代表以后没用我在代码评审里见过有人把它强转成自家结构体然后写数据进去——这种写法能跑直到宿主换版本。提示pOpen/pHigh/pLow/pClose/pVol允许为 NULL。分钟线、自定义品种、指数合成数据里缺字段的情况真实存在取值前先判空缺数据就返回空值别拿 0 顶上去算。2.2 调用约定与位数比算法更容易翻车的地方__stdcall和__cdecl的区别在教科书上是谁负责清栈在真实项目里是终端闪退还是正常出数。32 位宿主按__stdcall调用你导出的是__cdecl栈指针一错函数返回的那一刻整个进程就没了而且没有任何异常信息只有一个 Windows 错误报告框。这类问题极难从现象反推因为崩的地方离真正的原因十万八千里。位数问题同理。宿主是 32 位进程你编了个 64 位 DLLLoadLibrary会直接失败公式端看到的是函数不存在。反过来也一样。所以工程的第一条纪律是编译前先确认宿主进程的位数在任务管理器里看一眼就行别猜。/* 用 C 写实现、用 C 暴露接口的标准写法 */ #include dgfunc.h #include cmath #include vector #include string namespace { /* 内部随便用 STL、用类、用异常只要不跨过下面的 extern C 边界 */ struct WindowStat { double mean 0.0; double stdev 0.0; }; WindowStat calc(const double* p, int n) { WindowStat s; for (int i 0; i n; i) s.mean p[i]; s.mean / n; for (int i 0; i n; i) { const double d p[i] - s.mean; s.stdev d * d; } s.stdev std::sqrt(s.stdev / n); return s; } } /* 唯一需要导出的入口C 链接、noexcept、只接收 POD */ extern C __declspec(dllexport) double DG_CALL MYSTD(int nParamCount, const double* pParams, const DGCalcCtx* pCtx) noexcept { try { if (!pCtx || !pCtx-pClose) return 0.0; const int i pCtx-nCurIndex; if (i 0 || i pCtx-nDataLen) return 0.0; int n (nParamCount 2) ? static_castint(pParams[1]) : 20; if (n 2) n 2; if (n 2000) n 2000; /* 上限保护公式里写 999999 的人不少 */ if (i 1 n) return 0.0; /* 数据不足返回空不要瞎算 */ return calc(pCtx-pClose (i - n 1), n).stdev; } catch (...) { return 0.0; /* 异常绝不能穿越 C ABI 边界 */ } }这段代码的关键不在算法在边界处理extern C禁止名字修饰否则公式里写的名字永远匹配不上noexcept加 try/catch 兜底异常穿过 C 边界是未定义行为实际表现是进程直接死参数上下界收紧数据不足时返回空值。2.3 从源码到 DLL一份能编译通过的最小工程导出名要和公式里写的完全一致最稳妥的方式是用.def文件显式声明而不是依赖__declspec(dllexport)自动修饰——后者在 32 位下会把__stdcall的名字修饰成_MYSTD12这种形式公式引擎按MYSTD找自然找不到。; mystd.def —— 显式导出屏蔽名字修饰带来的匹配问题 LIBRARY MYSTD EXPORTS MYSTD# 32 位 Release 构建位数必须与宿主进程一致 cl /nologo /LD /O2 /W3 /EHsc /D_CRT_SECURE_NO_WARNINGS \ mystd.cpp /link /DEF:mystd.def /MACHINE:X86 /OUT:MYSTD.dll # 检查导出表确认名字干净、没有 修饰 dumpbin /exports MYSTD.dll/LD生成 DLL/O2开优化公式函数会被逐根 K 线调用几十万次Debug 版慢到没法用/MACHINE:X86强制 32 位/DEF挂上导出脚本。dumpbin /exports是每次打包必跑的检查项输出里如果看到_MYSTD12而不是MYSTD别上传先回去改导出方式。工程组织上我一般会再建一个host_test子工程静态链接同一份.cpp用假数据跑一遍再进终端。原因很实际终端里调试 DLL 基本靠日志和猜宿主进程崩了连调用栈都拿不到把问题前移到可控环境里成本低一个数量级。3. 数据打通double、字符串、序列与空值签名对上只是能加载能不能算出对的结果取决于你对数据类型的处理是否和宿主的预期一致。公式引擎的类型系统比 C 简单得多它只有数值、字符串、序列、空值四类东西映射到 C 接口上各有各的坑。3.1 数值是硬通货int、bool、NaN 的边界所有参数进来都是double所有结果出去也是double。看似简单但类型语义得自己守公式里的整数参数要先static_castint再校验范围直接拿double去比较n 1在n 0.9999999时会误判布尔返回值按惯例用 1.0 和 0.0不要返回 -1.0 当 false公式端做IF(条件, A, B)时只认非零。空值是重灾区。公式引擎里这根 K 线没有值和这根 K 线的值是 0是两回事前者在图上表现为断线后者是一条贴着零轴的实线。C 接口里通常用 NaN 表达空值所以你的函数在数据不足、除零、开方负数、对数非正的时候应该return std::nan()而不是return 0.0。注意NaN 有个特性是NaN ! NaN恒为真用它做判断必须写if (v ! v) return NaN;。但千万别在累加循环里放过 NaN一个 NaN 进来整个和就废了而且不会报错只会静默输出一条断线排查起来非常熬人。还有一个容易被忽略的点double精度。行情价格一般是两位小数但中间计算比如协方差、回归斜率会放大误差最后再拿去和公式里的阈值比较时0.30000000000000004 0.3成立信号就多了一个。涉及阈值判断的地方我会显式加一个 1e-9 量级的容差宁可少一个信号也不要一个逻辑上说不清的多余信号。3.2 字符串参数谁分配谁释放字符串参数普遍采用两次调用模型第一次传入空缓冲区和 0 长度函数返回所需字节数宿主按这个长度分配缓冲区第二次调用把数据拷进去。这套模型的好处是不用约定内存分配器坏处是很多人只实现了一半。/* 两次调用模型szBuf 为 NULL 时只查询长度不写任何数据 */ extern C __declspec(dllexport) int DG_CALL MYSTR(int nParamCount, const double* pParams, char* szBuf, int nBufLen) noexcept { static const char kText[] DG-CUSTOM-1; /* 只读常量生命周期无限长 */ const int nNeed static_castint(sizeof(kText)); /* 含结尾 0 */ if (szBuf 0 || nBufLen 0) return nNeed; /* 第一次只报长度 */ if (nBufLen nNeed) return nNeed; /* 缓冲区不够仍报真实需求 */ for (int i 0; i nNeed; i) szBuf[i] kText[i]; return nNeed; }要点在于长度包含结尾的\0nBufLen不够时不要截断写入直接返回所需长度让宿主重试返回的字符串绝不指向函数内部的局部变量或std::string::c_str()——函数一返回那块内存就没了宿主读到的是野指针内容运气好是乱码运气差是崩溃。如果确实需要返回动态生成的字符串就在 DLL 里用一块静态缓冲区自己管生命周期并且明确约定下一次调用会覆盖上一次的内容。这个约定要在头文件注释里写清楚别指望后来接手的人能猜出来。3.3 序列数据与逐K线调用模型理解逐 K 线调用模型是写出正确函数的前提。宿主不是把你的函数当成一个黑盒一次性喂完所有数据而是从第 0 根 K 线开始一根一根地调nCurIndex 0调一次 1调一次直到最后一根。每次调用你只负责回答在当前这根上结果是多少。这个模型带来两个直接后果。第一你的函数必须对任意nCurIndex都返回正确值包括刚开始数据不足的前几根。第二任何跨 K 线的状态比如递归平滑、累计量都不能存在函数静态变量里——用户切换周期时引擎可能重新计算静态变量的残留值会让你输出的曲线在切换后的前几十根上完全错乱。这类 bug 在图上表现为切换周期后指标头一段是平的很难联想到是状态没清。/* 序列相关的正确写法所有跨 K 线信息都从 pCtx 重新推导不留静态状态 */ extern C __declspec(dllexport) double DG_CALL MYSUM(int nParamCount, const double* pParams, const DGCalcCtx* pCtx) noexcept { if (!pCtx || !pCtx-pClose) return 0.0; const int i pCtx-nCurIndex; int n (nParamCount 2) ? static_castint(pParams[1]) : 5; if (n 1) n 1; if (i 1 n) return 0.0; double sum 0.0; for (int k 0; k n; k) { const double v pCtx-pClose[i - k]; if (v ! v) return 0.0; /* NaN 短路避免污染整段结果 */ sum v; } return sum; }这段的复杂度是 O(n) 每根 K 线总体 O(N·n)在 n 小的时候完全够用。真正上线上量之后才会发现一个 5000 根历史、窗口 250 的函数用户点一次刷新要跑一百多万次循环体感上就是这个指标一加进去软件就卡。性能优化放在第 6 章展开。3.4 异常不能穿过 C ABIC 的异常机制依赖编译器生成的栈展开表跨 DLL 边界抛出时如果两边编译器版本、运行库配置、异常模型不一致结果是未定义行为。实际观察到的现象是函数里抛了个std::out_of_range宿主进程无声无息地消失事件查看器里只有一条应用程序错误。所以导出函数的骨架应该是固定的最外层noexcept函数体整体包在try { ... } catch (...) { return 空值; }里。内部可以随便用异常做控制流只要它在边界内被吃掉。这个 catch 不是防御性编程的装饰是保命的。同理std::string、std::vector、任何带析构函数的类型都不能出现在导出签名里。宿主的调用栈上根本没有你的析构逻辑跨堆分配和释放更是禁忌——你的 DLL 用一份 CRT宿主用另一份new出来的指针传过去让宿主delete堆管理器直接报错。内存谁分配谁释放这条纪律没有例外。4. 联调注册、命名匹配与独立宿主自测DLL 编出来了公式里还是提示找不到函数这是最常见的求助场景。九成情况下问题不在算法在加载环节。把联调拆成注册→命名→调用三段查比在终端里一遍遍重启快得多。4.1 注册与名字匹配DG 终端这类宿主一般要求在设置里指定 DLL 的完整路径然后重启或刷新公式引擎引擎才会去LoadLibrary并枚举导出表。这里有三个独立的失败点任何一个不满足都会报函数不存在错误信息却完全一样。第一是路径。相对路径在不同工作目录下解析结果不同一律写绝对路径并且路径里不要有中文和空格——不是所有版本的宿主都用宽字符 API 加载遇到中文路径可能直接失败。第二是位数前面说过32 位宿主加载 64 位 DLL 必失败。第三是导出名公式里写的MYSTD导出表里必须是MYSTD多一个下划线、多一个12都算不匹配。我的排查顺序是固定的先dumpbin /exports看名字再确认 DLL 位数和宿主一致最后才去查路径和注册。顺序反了会白折腾很久因为重启终端这个动作太廉价容易让人反复重启而忘记做静态检查。提示把 DLL 放到终端安装目录下再注册能规避一部分搜索路径问题。但升级终端时这个目录可能被覆盖或清理长期方案还是放在独立目录、注册绝对路径。4.2 写一个独立宿主程序先跑通在终端里调试 DLL 的体验极差没有断点、没有调用栈、崩了只有一句程序已停止工作。所以我的习惯是永远先写一个几十行的自测宿主用假数据把函数跑通再进终端。/* host_test.c —— 独立自测宿主把联调问题挡在终端之外 */ #include windows.h #include stdio.h #include math.h #include dgfunc.h int main(void) { HMODULE h LoadLibraryA(MYSTD.dll); if (!h) { printf(LoadLibrary failed: %lu\n, GetLastError()); return 1; } PFN_DG_CALC fn (PFN_DG_CALC)GetProcAddress(h, MYSTD); if (!fn) { printf(GetProcAddress failed: %lu\n, GetLastError()); return 2; } /* 造 300 根模拟收盘价避免依赖真实行情 */ double close[300]; for (int i 0; i 300; i) close[i] 10.0 (i % 17) * 0.13; DGCalcCtx ctx {0}; ctx.nDataLen 300; ctx.pClose close; ctx.nPeriod 0; double params[2] { 0.0, 20.0 }; /* [0] 占位序列[1] 窗口长度 */ int nBad 0; for (int i 0; i 300; i) { ctx.nCurIndex i; double v fn(2, params, ctx); if (v ! v) { nBad; continue; } /* NaN 计数正常应集中在前 19 根 */ if (i 299) printf(last%f\n, v); } printf(NaN count%d (expect 19)\n, nBad); FreeLibrary(h); return 0; }这个宿主干了三件事验证LoadLibrary和GetProcAddress能否成功这是名字和位数问题的照妖镜、用可控数据验证数值正确性、统计 NaN 出现的位置是否符合前 n-1 根数据不足的预期。第三点特别有用——如果 NaN 出现在中间而不是开头说明函数内部有分支没处理好或者访问了越界内存。编译它的时候注意同样要用 32 位cl /MACHINE:X86 host_test.c。这个工程编错位数症状和 DLL 编错位数一模一样会让你怀疑人生。4.3 日志与可观测性终端里的 DLL 出问题唯一能带出来的信息就是你主动写进去的。所以关键路径上要有日志但日志本身不能成为性能瓶颈——逐 K 线调用几十万次每次都fopen/fprintf/fclose会让整个指标慢十倍。我一般用两种手段。轻量的用一个进程内的环形缓冲把最近 N 条记录存内存里另导出一个DUMPLOG函数公式里单独跑一次把它写到文件。重一点的用OutputDebugStringA配个调试器看实时输出不影响正常运行。两者都只在异常分支和首次调用时写正常路径一条不写。日志内容上最有价值的不是我算出了什么而是我收到了什么nParamCount、pParams前几项、nCurIndex、nDataLen、指针是否为空。这套信息能解释 80% 的结果不对类问题——多数时候是参数传错了不是算法写错了。5. 避坑与排查五个翻车现场5.1 公式提示函数不存在但 DLL 明明编出来了现象设置里注册成功公式编辑器里一调用就报错或者干脆没有任何反应。原因按发生频率排依次是导出名带修饰_MYSTD12、DLL 位数与宿主不一致、路径含中文或空格、宿主没重启导致旧 DLL 还在内存里被占用时文件替换会失败但很多人没注意。还有一种隐蔽情况DLL 依赖了某个运行库 DLL加载时因缺少依赖而失败LoadLibrary返回 NULL但错误被宿主吞掉了。解决先dumpbin /exports确认导出名干净再dumpbin /dependents看依赖是否都能找到用 4.2 的自测宿主独立验证一次加载最后才去查路径。全部通过说明问题在宿主侧重启后再试。依赖问题我在一台干净机器上遇到过一次本机装了开发环境所以不缺运行库换机器就挂后来改成静态链接运行库才彻底解决。5.2 一加进公式终端直接闪退现象公式里写上函数名回车终端进程消失没有任何提示。原因绝大多数是调用约定不匹配。32 位下宿主按__stdcall调你导出__cdecl函数返回时栈指针错位进程当场死。其次是数组越界写——比如把pParams[1]当长度去写缓冲区实际公式只传了一个参数。第三是导出函数里抛了异常且没被捕获。解决检查头文件里的DG_CALL是否真的落在了导出函数上见过只在 typedef 里加了、实现里忘了加的在函数入口打印nParamCount和nBufLen类参数确认和公式里写的一致最外层无条件加try/catch(...)。这条我踩过一次花了整整一个下午最后发现是.def文件里写了名字但源码里DG_CALL被宏覆盖掉了。5.3 结果全是 0或者整条线是断的现象公式能跑图上一条平线贴着零轴或者干脆什么都不画。原因pCtx判空直接用 0 兜底、nDataLen和nCurIndex关系搞反、取值时用了pCtx-pClose[nCurIndex]但序列指针实际为 NULL分钟线常见、数据不足时返回 0 而不是 NaN 导致有值但都是 0。还有一种参数索引错位把窗口长度读成了第 0 项。解决先确认返回值语义——数据不足返回 NaN真实计算才返回数值。然后逐个打印nParamCount、pParams[0..n]、nCurIndex、nDataLen和公式里写的对照。序列指针为 NULL 时不要硬算直接返回 NaN让图上断线而不是画一条假线。5.4 切换周期后指标头一段明显不对现象日线切到 60 分钟或者切换品种后指标最前面几十根的值和预期完全不符后面的又正常。原因函数里用了静态变量或全局变量保存跨 K 线的累加量。引擎切换周期时会重新从第 0 根开始算但静态变量还留着上一次的残留值于是头几根的计算被污染。解决把所有跨 K 线状态从静态变量里清出去改成每根 K 线从pCtx重新推导必要时用滑动窗口重算。如果确实需要缓存加速缓存必须带数据集标识长度 周期 首值指纹不匹配就整块丢弃重建。这个坑我在第 6 章会再给一套缓存方案。5.5 历史数据一拉长终端就卡住现象默认几百根 K 线时飞快用户把历史数据拉到几千根整个界面卡住十几秒。原因逐 K 线调用 × 每根内部 O(n) 循环 O(N·n)N 是 K 线总数。5000 根、窗口 250就是 125 万次乘法加 125 万次内存访问每根还要重复一遍实际执行量远超直觉。解决能用增量就用增量——滑动窗口求和只需要加一个减一个复杂度降到 O(N)不能增量的用缓存 版本号实在复杂的在首次调用时一次性算完整条序列存进缓冲区后续直接按下标取。缓存要注意容量上限别为了一个指标吃掉几百兆内存。6. 进阶把逐K线调用压成一次计算性能优化这块我吃过一次实打实的教训一个看起来只有十几行的函数因为每根 K 线都重算整段窗口在用户拉满历史数据后把终端拖到无响应。后来改成增量维护同样的计算量从十几秒降到基本无感。核心思路是把每根 K 线重新推导换成缓存 增量更新但缓存必须带失效条件。/* 增量版滑动求和缓存带数据集指纹指纹变化即整体重建 */ extern C __declspec(dllexport) double DG_CALL MYSUM_FAST(int nParamCount, const double* pParams, const DGCalcCtx* pCtx) noexcept { static thread_local struct { int nLen -1, nPeriod -1, nWindow -1; double dFirst 0.0; double dLast 0.0; /* 当前窗口和 */ } cache; try { if (!pCtx || !pCtx-pClose) return 0.0; const int i pCtx-nCurIndex; int n (nParamCount 2) ? static_castint(pParams[1]) : 5; if (n 1) n 1; if (i 1 n) return 0.0; /* 数据集指纹长度、周期、首值任一变化都视为换了一份数据 */ const bool bSame (cache.nLen pCtx-nDataLen) (cache.nPeriod pCtx-nPeriod) (cache.nWindow n) (cache.nLen 0 cache.dFirst pCtx-pClose[0]); if (!bSame || i n - 1) { double s 0.0; for (int k 0; k n; k) s pCtx-pClose[i - k]; cache { pCtx-nDataLen, pCtx-nPeriod, n, pCtx-pClose[0], s }; return s; } /* 增量加上新的一根减掉窗口末端之外的那一根 */ cache.dLast pCtx-pClose[i] - pCtx-pClose[i - n]; return cache.dLast; } catch (...) { return 0.0; } }thread_local是因为公式引擎可能在多线程里跑不同品种全局静态会被并发写乱指纹里的三个字段用来判断是否换了数据集i n - 1是增量链条的起点必须整段重建一次否则累加基准是错的。这套写法收益明显但引入了缓存不一致这个新的故障类别所以上线前我把下面这张表走了一遍。检查项具体动作不通过的典型现象导出名dumpbin /exports看是否为裸名公式报函数不存在位数自测宿主与宿主进程均为 32 位LoadLibrary 返回 NULL调用约定导出函数带DG_CALL终端闪退空值语义数据不足返回 NaN图上画出假平线异常边界最外层noexcept catch-all进程无声消失缓存失效切换周期后头段数值正确指标前几十根错乱性能拉满历史数据计时界面卡顿数秒以上从那以后我每次交付前都强制走一遍这张表尤其是切换周期后头段和拉满历史数据计时这两项——它们不报错只在用户手里慢慢暴露等反馈回来复现成本已经翻了几倍。把这两项变成肌肉记忆比事后加十行日志都管用。希望帮到你。本文还有配套的精品资源点击获取
简介面向股票软件二次开发者的WIN32动态链接库接口模板聚焦大智慧新一代公式系统外部扩展函数的C语言实现提供可直接参考的工程骨架适合具备C基础、希望为行情终端接入自定义指标或功能模块的开发者使用。整个压缩包仅6KB共6个文件以2个cpp源文件和2个h头文件为核心配合dsw工作区与dsp工程文件便于在VC环境中直接打开、编译与二次修改源码与头文件分工明确工程配置也一并保留省去从零搭建DLL项目的繁琐。已有1892人学习下载说明其在公式接口与外部函数扩展场景中具有一定参考价值。读者可从中了解外部扩展函数的声明与导出方式、StdAfx预编译头的组织以及最小化DLL工程结构既能作为调试接口调用、排查编译链接问题的起点也便于将模板迁移到自己的公式扩展项目中减少重复搭建环境的时间。1. 行情终端里的 C 语言接口公式不够用的那一步写公式写到第三年总会撞上一堵墙均线、MACD、布林这些内置函数随便拼可一旦要做跨周期校验、要读外部因子文件、要在公式里调用自己写的数值优化器公式语言就彻底不够用了。行情分析终端提供的 C 语言接口本质是把公式引擎的计算权交一部分出来——你编译一个动态库导出符合约定的函数公式里就能像调用 MA、EMA 一样调用它。这套 C 公式接口面向的是有 C/C 底子、需要把私有算法塞进行情终端的人做量化信号验证的、要复用已有 C 库的、嫌公式语言跑得慢的。下文统一用 DG 终端指代这类行情分析终端接口细节按通用约定描述具体版本以随包头文件为准。2. 接口签名定生死调用约定、参数指针与导出表接口设计里最容易拍脑袋、也最容易在半年后翻车的部分就是函数签名。行情终端调用你的 DLL 时它不知道你内部用了几个类、几个模板它只知道一个函数地址、三个参数、一个 double 返回值。任何超出这个约定的东西——异常、C 对象、STL 容器、跨 DLL 的 new/delete——都会在某个用户的机器上炸掉而且往往炸在终端进程里连带用户正在看的行情一起没了。所以第一件事不是写算法是把契约头文件钉死。我的习惯是先写一个dgfunc.h让 DLL 工程和自测宿主工程共用它任何一方改动都必须同步重新编译两边。2.1 三个参数定架构参数个数、参数数组、计算上下文宿主的调用模型通常是这样的公式里写了一行MYMA(CLOSE, 20)引擎解析出函数名MYMA、参数个数 2然后按 K 线逐根调用你导出的函数每次告诉你现在算到第几根。序列数据不通过参数数组传而是放在一个只读上下文结构体里由宿主填充。/* dgfunc.h —— 公式函数接口的唯一契约头文件DLL 与自测宿主共用 */ #ifndef DGFUNC_H #define DGFUNC_H #ifdef __cplusplus extern C { #endif /* 32 位宿主必须 __stdcall64 位下该修饰被忽略但保留写法便于两套二进制共存 */ #ifdef _WIN32 # define DG_CALL __stdcall #else # define DG_CALL #endif /* 计算上下文宿主填充DLL 只读。禁止修改内容禁止把指针存起来下次用 */ typedef struct tagDGCalcCtx { int nDataLen; /* 当前数据集 K 线总根数可能随时变化 */ int nCurIndex; /* 本次调用的位置0 表示第一根 K 线 */ const double* pOpen; /* 以下序列长度均等于 nDataLen可能为 NULL */ const double* pHigh; const double* pLow; const double* pClose; const double* pVol; int nPeriod; /* 周期标识日线/分钟线由宿主给出仅作参考 */ void* pReserved; /* 保留字段必须忽略不要强转成任何结构体 */ } DGCalcCtx; /* 导出函数的统一签名公式端按导出名调用 */ typedef double (DG_CALL *PFN_DG_CALC)(int nParamCount, const double* pParams, const DGCalcCtx* pCtx); #ifdef __cplusplus } #endif #endif三个参数的分工要背下来nParamCount是公式里实际写了几项pParams是这封装换好的 double 数组含第一项通常用来传序列或标量pCtx是行情数据和时间位置的唯一来源。几个参数上的血泪经验值得单独说。nParamCount一定要做上下界双重校验公式作者写错参数个数是家常便饭少传一个你按pParams[1]取值就是越界读多传一个你少读一项也不报错但结果对不上。pCtx-nDataLen不是常量用户切换周期、切换品种、拉长历史区间都会变任何长度的缓存都要带版本号或长度戳。pReserved现在没用不代表以后没用我在代码评审里见过有人把它强转成自家结构体然后写数据进去——这种写法能跑直到宿主换版本。提示pOpen/pHigh/pLow/pClose/pVol允许为 NULL。分钟线、自定义品种、指数合成数据里缺字段的情况真实存在取值前先判空缺数据就返回空值别拿 0 顶上去算。2.2 调用约定与位数比算法更容易翻车的地方__stdcall和__cdecl的区别在教科书上是谁负责清栈在真实项目里是终端闪退还是正常出数。32 位宿主按__stdcall调用你导出的是__cdecl栈指针一错函数返回的那一刻整个进程就没了而且没有任何异常信息只有一个 Windows 错误报告框。这类问题极难从现象反推因为崩的地方离真正的原因十万八千里。位数问题同理。宿主是 32 位进程你编了个 64 位 DLLLoadLibrary会直接失败公式端看到的是函数不存在。反过来也一样。所以工程的第一条纪律是编译前先确认宿主进程的位数在任务管理器里看一眼就行别猜。/* 用 C 写实现、用 C 暴露接口的标准写法 */ #include dgfunc.h #include cmath #include vector #include string namespace { /* 内部随便用 STL、用类、用异常只要不跨过下面的 extern C 边界 */ struct WindowStat { double mean 0.0; double stdev 0.0; }; WindowStat calc(const double* p, int n) { WindowStat s; for (int i 0; i n; i) s.mean p[i]; s.mean / n; for (int i 0; i n; i) { const double d p[i] - s.mean; s.stdev d * d; } s.stdev std::sqrt(s.stdev / n); return s; } } /* 唯一需要导出的入口C 链接、noexcept、只接收 POD */ extern C __declspec(dllexport) double DG_CALL MYSTD(int nParamCount, const double* pParams, const DGCalcCtx* pCtx) noexcept { try { if (!pCtx || !pCtx-pClose) return 0.0; const int i pCtx-nCurIndex; if (i 0 || i pCtx-nDataLen) return 0.0; int n (nParamCount 2) ? static_castint(pParams[1]) : 20; if (n 2) n 2; if (n 2000) n 2000; /* 上限保护公式里写 999999 的人不少 */ if (i 1 n) return 0.0; /* 数据不足返回空不要瞎算 */ return calc(pCtx-pClose (i - n 1), n).stdev; } catch (...) { return 0.0; /* 异常绝不能穿越 C ABI 边界 */ } }这段代码的关键不在算法在边界处理extern C禁止名字修饰否则公式里写的名字永远匹配不上noexcept加 try/catch 兜底异常穿过 C 边界是未定义行为实际表现是进程直接死参数上下界收紧数据不足时返回空值。2.3 从源码到 DLL一份能编译通过的最小工程导出名要和公式里写的完全一致最稳妥的方式是用.def文件显式声明而不是依赖__declspec(dllexport)自动修饰——后者在 32 位下会把__stdcall的名字修饰成_MYSTD12这种形式公式引擎按MYSTD找自然找不到。; mystd.def —— 显式导出屏蔽名字修饰带来的匹配问题 LIBRARY MYSTD EXPORTS MYSTD# 32 位 Release 构建位数必须与宿主进程一致 cl /nologo /LD /O2 /W3 /EHsc /D_CRT_SECURE_NO_WARNINGS \ mystd.cpp /link /DEF:mystd.def /MACHINE:X86 /OUT:MYSTD.dll # 检查导出表确认名字干净、没有 修饰 dumpbin /exports MYSTD.dll/LD生成 DLL/O2开优化公式函数会被逐根 K 线调用几十万次Debug 版慢到没法用/MACHINE:X86强制 32 位/DEF挂上导出脚本。dumpbin /exports是每次打包必跑的检查项输出里如果看到_MYSTD12而不是MYSTD别上传先回去改导出方式。工程组织上我一般会再建一个host_test子工程静态链接同一份.cpp用假数据跑一遍再进终端。原因很实际终端里调试 DLL 基本靠日志和猜宿主进程崩了连调用栈都拿不到把问题前移到可控环境里成本低一个数量级。3. 数据打通double、字符串、序列与空值签名对上只是能加载能不能算出对的结果取决于你对数据类型的处理是否和宿主的预期一致。公式引擎的类型系统比 C 简单得多它只有数值、字符串、序列、空值四类东西映射到 C 接口上各有各的坑。3.1 数值是硬通货int、bool、NaN 的边界所有参数进来都是double所有结果出去也是double。看似简单但类型语义得自己守公式里的整数参数要先static_castint再校验范围直接拿double去比较n 1在n 0.9999999时会误判布尔返回值按惯例用 1.0 和 0.0不要返回 -1.0 当 false公式端做IF(条件, A, B)时只认非零。空值是重灾区。公式引擎里这根 K 线没有值和这根 K 线的值是 0是两回事前者在图上表现为断线后者是一条贴着零轴的实线。C 接口里通常用 NaN 表达空值所以你的函数在数据不足、除零、开方负数、对数非正的时候应该return std::nan()而不是return 0.0。注意NaN 有个特性是NaN ! NaN恒为真用它做判断必须写if (v ! v) return NaN;。但千万别在累加循环里放过 NaN一个 NaN 进来整个和就废了而且不会报错只会静默输出一条断线排查起来非常熬人。还有一个容易被忽略的点double精度。行情价格一般是两位小数但中间计算比如协方差、回归斜率会放大误差最后再拿去和公式里的阈值比较时0.30000000000000004 0.3成立信号就多了一个。涉及阈值判断的地方我会显式加一个 1e-9 量级的容差宁可少一个信号也不要一个逻辑上说不清的多余信号。3.2 字符串参数谁分配谁释放字符串参数普遍采用两次调用模型第一次传入空缓冲区和 0 长度函数返回所需字节数宿主按这个长度分配缓冲区第二次调用把数据拷进去。这套模型的好处是不用约定内存分配器坏处是很多人只实现了一半。/* 两次调用模型szBuf 为 NULL 时只查询长度不写任何数据 */ extern C __declspec(dllexport) int DG_CALL MYSTR(int nParamCount, const double* pParams, char* szBuf, int nBufLen) noexcept { static const char kText[] DG-CUSTOM-1; /* 只读常量生命周期无限长 */ const int nNeed static_castint(sizeof(kText)); /* 含结尾 0 */ if (szBuf 0 || nBufLen 0) return nNeed; /* 第一次只报长度 */ if (nBufLen nNeed) return nNeed; /* 缓冲区不够仍报真实需求 */ for (int i 0; i nNeed; i) szBuf[i] kText[i]; return nNeed; }要点在于长度包含结尾的\0nBufLen不够时不要截断写入直接返回所需长度让宿主重试返回的字符串绝不指向函数内部的局部变量或std::string::c_str()——函数一返回那块内存就没了宿主读到的是野指针内容运气好是乱码运气差是崩溃。如果确实需要返回动态生成的字符串就在 DLL 里用一块静态缓冲区自己管生命周期并且明确约定下一次调用会覆盖上一次的内容。这个约定要在头文件注释里写清楚别指望后来接手的人能猜出来。3.3 序列数据与逐K线调用模型理解逐 K 线调用模型是写出正确函数的前提。宿主不是把你的函数当成一个黑盒一次性喂完所有数据而是从第 0 根 K 线开始一根一根地调nCurIndex 0调一次 1调一次直到最后一根。每次调用你只负责回答在当前这根上结果是多少。这个模型带来两个直接后果。第一你的函数必须对任意nCurIndex都返回正确值包括刚开始数据不足的前几根。第二任何跨 K 线的状态比如递归平滑、累计量都不能存在函数静态变量里——用户切换周期时引擎可能重新计算静态变量的残留值会让你输出的曲线在切换后的前几十根上完全错乱。这类 bug 在图上表现为切换周期后指标头一段是平的很难联想到是状态没清。/* 序列相关的正确写法所有跨 K 线信息都从 pCtx 重新推导不留静态状态 */ extern C __declspec(dllexport) double DG_CALL MYSUM(int nParamCount, const double* pParams, const DGCalcCtx* pCtx) noexcept { if (!pCtx || !pCtx-pClose) return 0.0; const int i pCtx-nCurIndex; int n (nParamCount 2) ? static_castint(pParams[1]) : 5; if (n 1) n 1; if (i 1 n) return 0.0; double sum 0.0; for (int k 0; k n; k) { const double v pCtx-pClose[i - k]; if (v ! v) return 0.0; /* NaN 短路避免污染整段结果 */ sum v; } return sum; }这段的复杂度是 O(n) 每根 K 线总体 O(N·n)在 n 小的时候完全够用。真正上线上量之后才会发现一个 5000 根历史、窗口 250 的函数用户点一次刷新要跑一百多万次循环体感上就是这个指标一加进去软件就卡。性能优化放在第 6 章展开。3.4 异常不能穿过 C ABIC 的异常机制依赖编译器生成的栈展开表跨 DLL 边界抛出时如果两边编译器版本、运行库配置、异常模型不一致结果是未定义行为。实际观察到的现象是函数里抛了个std::out_of_range宿主进程无声无息地消失事件查看器里只有一条应用程序错误。所以导出函数的骨架应该是固定的最外层noexcept函数体整体包在try { ... } catch (...) { return 空值; }里。内部可以随便用异常做控制流只要它在边界内被吃掉。这个 catch 不是防御性编程的装饰是保命的。同理std::string、std::vector、任何带析构函数的类型都不能出现在导出签名里。宿主的调用栈上根本没有你的析构逻辑跨堆分配和释放更是禁忌——你的 DLL 用一份 CRT宿主用另一份new出来的指针传过去让宿主delete堆管理器直接报错。内存谁分配谁释放这条纪律没有例外。4. 联调注册、命名匹配与独立宿主自测DLL 编出来了公式里还是提示找不到函数这是最常见的求助场景。九成情况下问题不在算法在加载环节。把联调拆成注册→命名→调用三段查比在终端里一遍遍重启快得多。4.1 注册与名字匹配DG 终端这类宿主一般要求在设置里指定 DLL 的完整路径然后重启或刷新公式引擎引擎才会去LoadLibrary并枚举导出表。这里有三个独立的失败点任何一个不满足都会报函数不存在错误信息却完全一样。第一是路径。相对路径在不同工作目录下解析结果不同一律写绝对路径并且路径里不要有中文和空格——不是所有版本的宿主都用宽字符 API 加载遇到中文路径可能直接失败。第二是位数前面说过32 位宿主加载 64 位 DLL 必失败。第三是导出名公式里写的MYSTD导出表里必须是MYSTD多一个下划线、多一个12都算不匹配。我的排查顺序是固定的先dumpbin /exports看名字再确认 DLL 位数和宿主一致最后才去查路径和注册。顺序反了会白折腾很久因为重启终端这个动作太廉价容易让人反复重启而忘记做静态检查。提示把 DLL 放到终端安装目录下再注册能规避一部分搜索路径问题。但升级终端时这个目录可能被覆盖或清理长期方案还是放在独立目录、注册绝对路径。4.2 写一个独立宿主程序先跑通在终端里调试 DLL 的体验极差没有断点、没有调用栈、崩了只有一句程序已停止工作。所以我的习惯是永远先写一个几十行的自测宿主用假数据把函数跑通再进终端。/* host_test.c —— 独立自测宿主把联调问题挡在终端之外 */ #include windows.h #include stdio.h #include math.h #include dgfunc.h int main(void) { HMODULE h LoadLibraryA(MYSTD.dll); if (!h) { printf(LoadLibrary failed: %lu\n, GetLastError()); return 1; } PFN_DG_CALC fn (PFN_DG_CALC)GetProcAddress(h, MYSTD); if (!fn) { printf(GetProcAddress failed: %lu\n, GetLastError()); return 2; } /* 造 300 根模拟收盘价避免依赖真实行情 */ double close[300]; for (int i 0; i 300; i) close[i] 10.0 (i % 17) * 0.13; DGCalcCtx ctx {0}; ctx.nDataLen 300; ctx.pClose close; ctx.nPeriod 0; double params[2] { 0.0, 20.0 }; /* [0] 占位序列[1] 窗口长度 */ int nBad 0; for (int i 0; i 300; i) { ctx.nCurIndex i; double v fn(2, params, ctx); if (v ! v) { nBad; continue; } /* NaN 计数正常应集中在前 19 根 */ if (i 299) printf(last%f\n, v); } printf(NaN count%d (expect 19)\n, nBad); FreeLibrary(h); return 0; }这个宿主干了三件事验证LoadLibrary和GetProcAddress能否成功这是名字和位数问题的照妖镜、用可控数据验证数值正确性、统计 NaN 出现的位置是否符合前 n-1 根数据不足的预期。第三点特别有用——如果 NaN 出现在中间而不是开头说明函数内部有分支没处理好或者访问了越界内存。编译它的时候注意同样要用 32 位cl /MACHINE:X86 host_test.c。这个工程编错位数症状和 DLL 编错位数一模一样会让你怀疑人生。4.3 日志与可观测性终端里的 DLL 出问题唯一能带出来的信息就是你主动写进去的。所以关键路径上要有日志但日志本身不能成为性能瓶颈——逐 K 线调用几十万次每次都fopen/fprintf/fclose会让整个指标慢十倍。我一般用两种手段。轻量的用一个进程内的环形缓冲把最近 N 条记录存内存里另导出一个DUMPLOG函数公式里单独跑一次把它写到文件。重一点的用OutputDebugStringA配个调试器看实时输出不影响正常运行。两者都只在异常分支和首次调用时写正常路径一条不写。日志内容上最有价值的不是我算出了什么而是我收到了什么nParamCount、pParams前几项、nCurIndex、nDataLen、指针是否为空。这套信息能解释 80% 的结果不对类问题——多数时候是参数传错了不是算法写错了。5. 避坑与排查五个翻车现场5.1 公式提示函数不存在但 DLL 明明编出来了现象设置里注册成功公式编辑器里一调用就报错或者干脆没有任何反应。原因按发生频率排依次是导出名带修饰_MYSTD12、DLL 位数与宿主不一致、路径含中文或空格、宿主没重启导致旧 DLL 还在内存里被占用时文件替换会失败但很多人没注意。还有一种隐蔽情况DLL 依赖了某个运行库 DLL加载时因缺少依赖而失败LoadLibrary返回 NULL但错误被宿主吞掉了。解决先dumpbin /exports确认导出名干净再dumpbin /dependents看依赖是否都能找到用 4.2 的自测宿主独立验证一次加载最后才去查路径。全部通过说明问题在宿主侧重启后再试。依赖问题我在一台干净机器上遇到过一次本机装了开发环境所以不缺运行库换机器就挂后来改成静态链接运行库才彻底解决。5.2 一加进公式终端直接闪退现象公式里写上函数名回车终端进程消失没有任何提示。原因绝大多数是调用约定不匹配。32 位下宿主按__stdcall调你导出__cdecl函数返回时栈指针错位进程当场死。其次是数组越界写——比如把pParams[1]当长度去写缓冲区实际公式只传了一个参数。第三是导出函数里抛了异常且没被捕获。解决检查头文件里的DG_CALL是否真的落在了导出函数上见过只在 typedef 里加了、实现里忘了加的在函数入口打印nParamCount和nBufLen类参数确认和公式里写的一致最外层无条件加try/catch(...)。这条我踩过一次花了整整一个下午最后发现是.def文件里写了名字但源码里DG_CALL被宏覆盖掉了。5.3 结果全是 0或者整条线是断的现象公式能跑图上一条平线贴着零轴或者干脆什么都不画。原因pCtx判空直接用 0 兜底、nDataLen和nCurIndex关系搞反、取值时用了pCtx-pClose[nCurIndex]但序列指针实际为 NULL分钟线常见、数据不足时返回 0 而不是 NaN 导致有值但都是 0。还有一种参数索引错位把窗口长度读成了第 0 项。解决先确认返回值语义——数据不足返回 NaN真实计算才返回数值。然后逐个打印nParamCount、pParams[0..n]、nCurIndex、nDataLen和公式里写的对照。序列指针为 NULL 时不要硬算直接返回 NaN让图上断线而不是画一条假线。5.4 切换周期后指标头一段明显不对现象日线切到 60 分钟或者切换品种后指标最前面几十根的值和预期完全不符后面的又正常。原因函数里用了静态变量或全局变量保存跨 K 线的累加量。引擎切换周期时会重新从第 0 根开始算但静态变量还留着上一次的残留值于是头几根的计算被污染。解决把所有跨 K 线状态从静态变量里清出去改成每根 K 线从pCtx重新推导必要时用滑动窗口重算。如果确实需要缓存加速缓存必须带数据集标识长度 周期 首值指纹不匹配就整块丢弃重建。这个坑我在第 6 章会再给一套缓存方案。5.5 历史数据一拉长终端就卡住现象默认几百根 K 线时飞快用户把历史数据拉到几千根整个界面卡住十几秒。原因逐 K 线调用 × 每根内部 O(n) 循环 O(N·n)N 是 K 线总数。5000 根、窗口 250就是 125 万次乘法加 125 万次内存访问每根还要重复一遍实际执行量远超直觉。解决能用增量就用增量——滑动窗口求和只需要加一个减一个复杂度降到 O(N)不能增量的用缓存 版本号实在复杂的在首次调用时一次性算完整条序列存进缓冲区后续直接按下标取。缓存要注意容量上限别为了一个指标吃掉几百兆内存。6. 进阶把逐K线调用压成一次计算性能优化这块我吃过一次实打实的教训一个看起来只有十几行的函数因为每根 K 线都重算整段窗口在用户拉满历史数据后把终端拖到无响应。后来改成增量维护同样的计算量从十几秒降到基本无感。核心思路是把每根 K 线重新推导换成缓存 增量更新但缓存必须带失效条件。/* 增量版滑动求和缓存带数据集指纹指纹变化即整体重建 */ extern C __declspec(dllexport) double DG_CALL MYSUM_FAST(int nParamCount, const double* pParams, const DGCalcCtx* pCtx) noexcept { static thread_local struct { int nLen -1, nPeriod -1, nWindow -1; double dFirst 0.0; double dLast 0.0; /* 当前窗口和 */ } cache; try { if (!pCtx || !pCtx-pClose) return 0.0; const int i pCtx-nCurIndex; int n (nParamCount 2) ? static_castint(pParams[1]) : 5; if (n 1) n 1; if (i 1 n) return 0.0; /* 数据集指纹长度、周期、首值任一变化都视为换了一份数据 */ const bool bSame (cache.nLen pCtx-nDataLen) (cache.nPeriod pCtx-nPeriod) (cache.nWindow n) (cache.nLen 0 cache.dFirst pCtx-pClose[0]); if (!bSame || i n - 1) { double s 0.0; for (int k 0; k n; k) s pCtx-pClose[i - k]; cache { pCtx-nDataLen, pCtx-nPeriod, n, pCtx-pClose[0], s }; return s; } /* 增量加上新的一根减掉窗口末端之外的那一根 */ cache.dLast pCtx-pClose[i] - pCtx-pClose[i - n]; return cache.dLast; } catch (...) { return 0.0; } }thread_local是因为公式引擎可能在多线程里跑不同品种全局静态会被并发写乱指纹里的三个字段用来判断是否换了数据集i n - 1是增量链条的起点必须整段重建一次否则累加基准是错的。这套写法收益明显但引入了缓存不一致这个新的故障类别所以上线前我把下面这张表走了一遍。检查项具体动作不通过的典型现象导出名dumpbin /exports看是否为裸名公式报函数不存在位数自测宿主与宿主进程均为 32 位LoadLibrary 返回 NULL调用约定导出函数带DG_CALL终端闪退空值语义数据不足返回 NaN图上画出假平线异常边界最外层noexcept catch-all进程无声消失缓存失效切换周期后头段数值正确指标前几十根错乱性能拉满历史数据计时界面卡顿数秒以上从那以后我每次交付前都强制走一遍这张表尤其是切换周期后头段和拉满历史数据计时这两项——它们不报错只在用户手里慢慢暴露等反馈回来复现成本已经翻了几倍。把这两项变成肌肉记忆比事后加十行日志都管用。希望帮到你。本文还有配套的精品资源点击获取
