Microsoft 的函数是 C++ 的一部分吗? 现在标准吗?

发布于 2024-07-14 10:17:44 字数 214 浏览 4 评论 0原文

我最近刚刚将 IDE 从 MSVC++ 6 更改为 MS Visual Studio 2005,并且收到了很多弃用警告。 我没有忽略警告,而是开始将它们更改为 _s 等效项。 然而,我后来发现这些只是微软的实现。

我在某处读到他们正在推动这些成为标准的一部分。 是吗?

使用这些 _s 函数是个好主意吗? 或者我应该使用其他东西?

谢谢。

I just recently changed my IDE to MS Visual Studio 2005 coming from MSVC++ 6, and I've gotten a lot of deprecation warnings. Rather than ignore the warning, I started to change them to the _s equivalents. However, I then found out that these were microsoft-only implementations.

I read somewhere that they were pushing for these to become part of the standard. Is it?

Is it a good idea to use these _s functions? Or should I use something else?

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

标点 2024-07-21 10:17:44

*_s() 函数不是 C 标准的一部分,但有一个待定的“技术报告”建议添加它们(我不确定 TR 中的例程是否完全是与 Microsoft 相同或者只是相似)。

TR 24731-1:C 库扩展第 I 部分:边界检查接口:

如果您想继续使用旧函数,您可以保留弃用警告通过定义宏_CRT_SECURE_NO_WARNINGS(可能仍受支持的_CRT_SECURE_NO_DEPRECATE)来保持安静。

The *_s() functions are not part of the C standard, but there is a pending 'Technical Report' proposing that they be added (I'm not sure if the routines in the TR are exactly the same as Microsoft's or if they're just similar).

TR 24731-1: Extensions to the C Library Part I: Bounds-checking interfaces:

If you want to continue to use the old functions you can keep the deprecation warnings quiet by defining the macro _CRT_SECURE_NO_WARNINGS (was _CRT_SECURE_NO_DEPRECATE which might still be supported).

小镇女孩 2024-07-21 10:17:44

您升级了 IDE,也升级了 Microsoft 库。 坦率地说,您可以继续使用旧的库,因为它们将继续保留(为了向后兼容),尽管微软表示他们实际上将开始删除其中一些旧的功能。 我想说的是,如果你正在向前发展,那么你可以使用更新的功能; 如果您正在向后开发(或者不担心版本是什么),那么您可能想使用旧的函数。

You upgraded your IDE and also upgraded your Microsoft libraries. Frankly you can continue to use your old libraries as they continue to be kept (for backwards compatibility) although Microsoft has said that they are going to actually start taking out some of these older functions. I would say that if you're developing forward then you can use the newer functions; if you're developing backwards (or not worrying what the version is) then you might want to use the older functions.

孤檠 2024-07-21 10:17:44

如果您的目标是 Microsoft 平台,请务必使用它们。 即使您不这样做,当您需要将软件移植到非 Microsoft 平台时,您也可以随时自行实现它们。

最糟糕的情况是您最终使用一些 #ifdef 进行条件编译。

If you're targeting the Microsoft platform, by all means use them. Even if you're not, you can always implement them yourself when (or if) you need to port your software to a non-Microsoft platform.

Worst case is that you end up using a few #ifdefs to conditionally compile.

jJeQQOZ5 2024-07-21 10:17:44

据我所知,它们正在考虑标准化。 该提案为 TR 24731

至于使用它们是否是一个好主意,我会说是的。 我不太喜欢他们捕获错误的方式,但我相信你可以为他们提供你自己的处理程序。 如果您需要跨平台兼容性,您有两种选择:在非 Windows 平台上使用宏实现它们或关闭弃用警告。

在对大型代码库进行审查后,我确定几乎不可能让所有程序员正确使用 C 标准库函数进行字符串操作,因此旨在纠正这一问题的所有内容都是值得欢迎的补充。

They're being considered for standardization, as far as I'm able to tell. The proposal is TR 24731.

As for whether it's a good idea to use them, I'd say yes. I don't much like the way they catch errors but I believe you can provide them with your own handler. If you need cross-platform compatibility you have two choices: implement them with macros on the non-Windows platforms or turn off the deprecation warnings.

After doing a review through a large codebase I determined that it's nearly impossible to get all programmers to use the C standard library functions for string manipulation correctly, so everything that aims to correct that is a welcome addition.

不念旧人 2024-07-21 10:17:44

您应该使用标准函数并禁用 Microsoft 默认打开的所有虐待警告,以阻止您编写符合标准的代码。 我严重怀疑“_s 函数”是否会被添加到标准 C 中(尽管它们已经被提议),因为它们是单个供应商的发明,并且从未被任何其他供应商实现过。 (嘿,让我们将所有 POSIX 合并到 C 标准中......)

You should use the standard functions and disable whatever sadistic warnings Microsoft has turned on by default to discourage you from writing standards-conformant code. I seriously doubt the "_s functions" will ever be added to standard C (though they have been proposed) since they are an invention of a single vendor and have never been implemented by any other vendor. (Hey let's incorporate all of POSIX into the C standard while we're at it...)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文