C 和 C++ 之间的常量正确性有什么区别?
我理解 const 正确性意味着什么,我的问题不是 const 正确性是什么。所以我不期待对此的解释或 C++-FAQ 链接。
我的问题是:
- C 中的
const
和 C++ 中的const
之间的语义差异是什么? 和 - 差异的原因是什么?
最好能引用各自标准的内容来明确差异。
我经常在 C 和 C++ 之间切换,我想知道这样做时应该记住的要点。
我似乎不记得这些的原因(如果你能提供推理,特别感谢),但从我的脑海中,我记得:
- C++ 中的 const 变量默认有内部链接,而在 C 中它们有默认的外部链接连锁;
- const 对象可以用作 C++ 中的编译时值,但不能用作 C 中的编译时值;
- 在 C++ 中,指向字符串文字的指针必须是
char const*
,但在 C 中它可以是char*
。
我缺少什么?
I understand what const correctness means and my question is not about what const correctness is. So I am not expecting an explanation or C++-FAQ links for that.
My questions are:
- What are the semantic differences between
const
in C andconst
in C++? and - What is the reason for the difference?
Quotes from the respective standards which make the differences clear would be nice to have.
I regularly switch between C and C++ and I would like to know the important points that one should keep in mind while doing so.
I don't seem to remember the reason for these (special thanks if you can provide a reasoning) but from the top of my mind, I can remember:
- const variables in C++ have internal linkage by default, while in C they have default external linkage;
- const objects can be used as compile-time values in C++, but cannot be used as compile-time values in C;
- Pointers to string literals must be an
char const*
in C++ but in C it can bechar*
.
What am I missing?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
除了您引用的差异以及库的差异之外
Steve Jessop 提到,
在 C++ 中是合法的,但在 C 中则不然。从历史上看,这是因为 C
最初允许:
在标准被采用之前不久,有人意识到这
在 const 安全性上打了一个洞(因为
*p2
现在可以被分配一个char const*
,这会导致p1
被分配一个char const*
);和没有实时深入分析问题,C委员会禁止任何
除顶级 const 之外的其他
const
。 (即&p1
可以是分配给
char **
或char **const
,但不分配给char const**
也不是
char const* const*
。)C++ 委员会做了进一步的工作分析,意识到问题仅在
const
时出现level 之后是一个非 const level,并计算出了必要的
措辞。 (参见标准中的§4.4/4。)
In addition to the differences you cite, and the library differences that
Steve Jessop mentions,
is legal in C++, but not in C. Historically, this is because C
originally allowed:
Shortly before the standard was adopted, someone realized that this
punched a hole in const safety (since
*p2
can now be assigned achar const*
, which results inp1
being assigned achar const*
); withno real time to analyse the problem in depth, the C committee banned any
additional
const
other than top level const. (I.e.&p1
can beassigned to a
char **
or achar **const
, but not to achar const**
nor a
char const* const*
.) The C++ committee did the furtheranalysis, realized that the problem was only present when a
const
level was followed by a non-
const
level, and worked out the necessarywording. (See §4.4/4 in the standard.)
在 C 中,const 声明不会生成常量表达式,即在 C 中,您不能在 case 标签中使用 const int 对象作为位域宽度或数组非 VLA 数组声明中的 size(这一切在 C++ 中都是可能的)。此外,const 对象在 C 中默认具有外部链接(在 C++ 中为内部链接)。
C++语言的常量正确性规则支持以下标准转换
这些在c中不起作用。
In C
const
declarations do not produce constant expressions, i.e. in C you can't use aconst int
object in a case label, as a bit-field width or as array size in a non-VLA array declaration (all this is possible in C++). Also, const objects have external linkage by default in C (internal linkage in C++).Const-correctness rules of C++ language support the following standard conversion
These will not work in c.
其中一些差异的原因是为了让我们摆脱预处理器宏,这是 Bjarne 的早期设计目标之一。
在 C 中,我们可能有
在 C++ 中,我们希望能够编写
为了使其工作,
max_foos
需要可在常量表达式中使用。它还需要具有内部链接,因此定义可以出现在标头中而不会导致多个定义错误,更重要的是使编译器更容易不为max_foos
分配任何存储空间。当 C 委员会从 C++ 中采用 const 时,他们并没有采用对宏的反感,因此他们不需要这些语义。
The reason for some of these differences is to allow us to get rid of preprocessor macros, which was one of Bjarne's early design goals.
In C we might have
In C++ we'd prefer to be able to write
For that to work
max_foos
needs to be usable in a constant expression. It also needs to have internal linkage, so the definition can appear in a header without causing multiple definition errors, and more importantly to make it easier for the compiler to not allocate any storage formax_foos
.When the C committee adopted const from C++ they didn't adopt the antipathy to macros, so they didn't need these semantics.