查找诸如 L“%s”之类的宽字符串问题的最佳方法是什么?
下面是我所说的令人头疼的问题之一的示例:
我们有一个多平台项目,主要使用 Unicode 字符串将文本渲染到屏幕上。在 Windows 的 VC++ 中,该行:
swprintf(swWideDest, LEN, L"%s is a wide string", swSomeWideString);
编译良好并将宽字符串打印到另一个宽字符串中。 然而,这实际上应该是:
swprintf(swWideDest, LEN, L"%ls is a wide string", swSomeWideString);
如果不将“%s”替换为“%ls”,这将无法在其他平台上工作。因为在我们的 Windows 环境中进行测试更容易、更快,而且调试起来也更简单。此类错误很容易被忽视。
我知道最好的解决方案是首先编写正确的代码,但在压力下会犯简单的错误,在这种特殊情况下,错误很容易在很长一段时间内被忽视。
我怀疑这种错误有很多变化,我们还没有享受到。
有没有人有一种漂亮而简洁的方法来发现这些类型的错误?
:D
Here is an example of one of the headaches I mean:
We have a multiplatform project that uses mostly Unicode strings for rendering text to the screen. On windows in VC++ the line:
swprintf(swWideDest, LEN, L"%s is a wide string", swSomeWideString);
compiles fine and prints the wide string into the other wide string.
However, this should really be:
swprintf(swWideDest, LEN, L"%ls is a wide string", swSomeWideString);
Without replacing the '%s' with a '%ls' this will not work on other platforms. As testing in our environment on Windows is easier, quicker, and far simpler to debug. These kind of bugs can easily go unnoticed.
I know that the best solution is to write correct code in the first place, but under pressure simple mistakes are made, and in this particular case, the mistake can easily go unnoticed for a long time.
I suspect there are many variations on this sort of bug, that we are yet to enjoy.
Does anyone have a nice and neat way of finding these kind of bugs?
: D
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可能需要查看 FastFormat,以防 Boost.Format 太慢而无法满足您的需求。
与 stringstreams 和 Boost.Format 相比:
You might want to have a look at FastFormat in case Boost.Format is too slow for your needs.
Compared to stringstreams and Boost.Format:
由于
*printf
系列的函数都不是类型安全的,因此您可以As none of the functions of
*printf
family are typesafe you either