在确保翻译单元之间的可用性时是否静态弃用? [英] Is static deprecated when ensuring availability between translation units?

查看:292
本文介绍了在确保翻译单元之间的可用性时是否静态弃用?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

从以下 stackoverflow answer ,用户说:

< blockquote>

这意味着变量对于翻译单元是本地的(简单地说,
到单个源文件),并且不能从外部访问它。这个
的静态使用实际上在当前的C ++标准 -
中被弃用,而不是你应该使用匿名命名空间:

  static int x = 0; 

应该是:

  namespace {
int x = 0;
}


我不反对匿名命名空间是
的首选方法,但现在使用静态真的不赞成?

标准在哪里说这个?

解决方案

不,目前不推荐使用。这是在一个点,但由于C的可比性问题,这一点被扭转。在1999年之前的某个时候,它被弃用,导致缺陷报告174 ,其中说:


决定弃用全局静态应该颠倒过来。




  • 我们不能否认静态,因为它是C的一个重要部分,放弃它会使C ++不必要地与C不兼容。

  • 可能会对未命名的名称空间的成员实例化,但某些编译系统可能会将这些符号放在
    全局链接器空间中,这可能会给
    链接器带来很大的负担。没有静态的,程序员没有机制来避免
    的负担。


其中 deprecation 被修改为:
$ b blockquote>

过时定义为:对当前版本的标准规范,但不能保证在未来修订中成为标准的一部分。


有人指出,这意味着,未来的标准只支持未弃用的功能:


然而,这个定义似乎表明,任何未弃用的功能在未来版本中都保证成为标准的一部分。目前尚不清楚这个含义是否有意,因此这个定义可能需要修改。


并改变了弃用的含义: : 被确定为从未来版本中删除的候选人。


后来由于 defect report 1012


尽管7.3.1.1 [namespace.unnamed]声明使用static关键字来声明名称空间作用域中的变量已被弃用,因为未命名的名称空间提供了一种优越的替代方案,所以不太可能在可预见的未来,特别是考虑到C兼容性问题。委员会应考虑取消弃用。



From the following stackoverflow answer, the user says:

It means that the variable is local to a translation unit (simply put, to a single source file), and cannot be accessed from outside it. This use of static is in fact deprecated in the current C++ Standard - instead you are supposed to use anonymous namespaces:

static int x = 0;

should be:

namespace {
    int x = 0;    
}

I don't disagree that anonymous namespaces are the preferred method,
but is using static really deprecated now?
Where does the standard say this?

解决方案

No, it is not currently deprecated. It was at one point but this was reversed due to C comparability issues. At some point before 1999 it was deprecated and this lead to defect report 174 which says:

The decision to deprecate global static should be reversed.

  • We cannot deprecate static because it is an important part of C and to abandon it would make C++ unnecessarily incompatible with C.
  • Because templates may be instantiated on members of unnamed namespaces, some compilation systems may place such symbols in the global linker space, which could place a significant burden on the linker. Without static, programmers have no mechanism to avoid the burden.

This lead to defect report 223 in which the meaning of deprecation was revised from:

deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions.

it was noted that this implies, only non-deprecated features will be support in future standards:

However, this definition would appear to say that any non-deprecated feature is "guaranteed to be part of the Standard in future revisions." It's not clear that that implication was intended, so this definition may need to be amended.

and changed the meaning of deprecated to:

These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but having been identified as a candidate for removal from future revisions.

and later the feature was undeprecated due to C compatibility issues by defect report 1012:

Although 7.3.1.1 [namespace.unnamed] states that the use of the static keyword for declaring variables in namespace scope is deprecated because the unnamed namespace provides a superior alternative, it is unlikely that the feature will be removed at any point in the foreseeable future, especially in light of C compatibility concerns. The Committee should consider removing the deprecation.

这篇关于在确保翻译单元之间的可用性时是否静态弃用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆