在 C++ 上公开的基本类型应用程序编程接口
我的目标是 Windows,但我不明白为什么我正在编写的某些 API 代码不能使用基本 C++ 类型。我想要做的是公开返回字符串和整数的方法。在 C# 世界中,我只使用字符串,并且有一个 unicode 字符串,但在 VC++ 中,我可以选择使用 std::string、std::wstring 或 MFC/ATL CString。
我应该只使用 std::wstring 来支持 unicode,还是可以使用 std::string 根据我的构建设置编译为 unicode?我倾向于后者。我更愿意在我的对象上为其他字符串类型提供 Get[Item]AsCString() 方法。
我还应该使用 size_t 而不是整数吗?
该 API 将由我使用,也许未来的开发人员将使用 C++ GUI。这是一种分离关注点的方法。我的偏好:
- 对其他开发人员来说直观。
- 与 VC++ 的前向兼容性
- 与其他 C++ 编译器的兼容性
- 性能(这对我来说不太关心,但需要我的应用程序的其余部分的启动时间)
任何指南将不胜感激。
I'm targeting Windows but I don't see any reason why some API code I'm writing cannot use basic C++ types. What I want to do is expose methods that return strings and ints. In the C# world I'd just use string, and have a unicode string, but in VC++ I've got the option of using std::string, std::wstring, or MFC/ATL CStrings.
Should I just use std::wstring exclusively to support unicode, or can I use std::string which would be compiled to unicode based on my build settings? I'm leaning toward the latter. I'd prefer to provide Get[Item]AsCString() methods on my objects for other string types.
Also should I be using size_t instead of integer?
The API is going to be used by me, and perhaps a future developer working on the C++ GUI. It is a way to separate concerns. My preferences:
- Intuitiveness for other developers.
- Forward compatibility with VC++
- Compatibility with other C++ compilers
- Performance (this is a lesser concern for me, but need the startup time for rest of my app)
Any guides would be appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可能应该坚持使用 STL 字符串类型。无论如何,MFC CString 类现在是建立在该类之上的。
正如之前所指出的,使用 wstring 并不是解决 Unicode 问题的灵丹妙药,因为有许多 Unicode 字符仍然需要多个 wchar 进行编码。
使用 Utf-8 具有潜在的好处(例如,您不必担心字节顺序)。
在 Windows 上,所有现代内核都是基于 wchar 的,因此如果您使用 8 位 char 版本的 API,则会产生(最小的)性能开销。
You should probably stick to the STL string type. The MFC CString class is built on top of that nowadays anyway.
As has been noted before, using wstring is not a magic bullet to address Unicode issues since there are many Unicode characters that still require multiple wchars to encode.
Using Utf-8 instead has potential benefits (you don't have to worry about endianness for example).
On Windows, all modern kernels are wchar based, so there is a (minimal) performance overhead involved if you use the 8bit char versions of APIs.
在你的情况下,我需要几个小时/几天的时间才能形成意见并做出决定。首先,与 C++_API 相比,我更喜欢 C_API,即使对于 C++ 代码也是如此。那么答案将是 char*、wchar* 或 TCHAR*。现在,尝试猜测您是否真的期望需要 UNICODE。我的绝大多数项目(包括那些带有 GUI 的项目)都不需要 UNICODE,普通 C 数组的简单性和熟悉性往往是难以匹敌的。
简而言之,尝试预测您的需求是什么,不要试图展望太远的未来(2年是一个很好的标志),然后提出最简单的解决方案来满足需求。
最后:为了更直接地回答你的问题,我将从 std::string 作为我评估的第一选择开始。除非我能找到一些有利于其他选择的出价优势,否则我会坚持下去。
In your situation it would take me few hours / days to develop an opinion and decide. First of all, I very much prefer C_API to C++_API, even for C++ code. Then the answer would be char*, or wchar*, or TCHAR*. Now, try to guess if you REALLY expect the need for UNICODE. Great majority of my projects (including those with GUIs), had no need for UNICODE, the simplicity and familiarity of plain C-arrays is often hard to beat.
In short, try to predict what will be your needs, do not try to look too far into future (2 years is a good mark), then come up with the simplest solution to meet the needs.
Last: To answer your question more directly, I would start with std::string as my 1st choice to evaluate. Unless I would find some bid advantage in favor of the other choices, I would stay with it.
使用 std::wstring/string 代替 MFC CString 将允许您将代码移植到其他框架(例如 Qt for Windows)。
即使使用 std::string 您也可以使用 UTF-8 对字符串进行编码,因此您的 API 仍然能够返回 UNICODE 字符串。
请记住,即使 wstring 实际上也是 UTF-16,而不是完整的 32 位 UNICODE(而在某些操作系统上,wstring 是 UTF-32)。
Using std::wstring/string instead of the MFC CString will allow you to port your code to other frameworks (e.g. Qt for Windows).
Even when using std::string you could encode the strings in UTF-8, so your API will still be able to return UNICODE strings.
Keep in mind that even wstring is really UTF-16 and not the full 32 bits UNICODE (while on some operating systems wstring is UTF-32).