在C ++中将私有定义为公开 [英] Define private to public in C++

查看:103
本文介绍了在C ++中将私有定义为公开的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想定义私有并受公共保护。

 #定义私有公共
#定义受保护公共

在C ++中这样安全吗?

解决方案

不,这几乎肯定会导致不确定的行为。



来自 n4296 17.6.4.3.1 [宏名称] / 2 :(通过下面的@james)


翻译单元不得 #define #undef 在词法上与关键字,表2中列出的标识符或7.6中描述的属性标记相同。


private public 是关键字。仅对其中之一执行 #define 是未定义的行为如果使用C ++标准库中的任何内容:



17.6.4.1/1 [constraints.overview]


本节介绍了对使用以下C ++程序的限制


如果您不这样做,则17.6.4.3.1中的限制似乎不适用。



另一种可能导致违反的方式是,如果您使用具有两个不同定义的相同结构。尽管大多数实现可能并不关心两个结构是否相同,除了 public private 之外,但该标准并没有做到这一点



尽管如此,最常见的UB类型是有效,因为很少有编译器关心。



但这并不意味着它是安全的。在特定的编译器中可能是安全的(请检查所述编译器的文档:但是,这是一个奇怪的保证!)。如果您通过两个不同的定义访问相同的结构,那么即使很少有其他错误的可能性,很少有编译器(如果有的话)会提供上述保证显式工作所需的布局保证(和损坏保证)。



许多编译器将正常工作。但这并不安全:下一个编译器版本可能会进行大量更改,并以难以(或易于)发现的方式破坏代码。





我找不到证据表明 #define 使用关键字是未定义的行为如果您从不包括任何标准库头,并且不要使用它在两个编译单元中使定义不同。因此,在严格限制的程序中,这可能是合法的。实际上,即使合法,它仍然不是安全的,这既是因为合法性非常脆弱,又是因为编译器不太可能针对这种语言滥用进行测试,也不太可能会导致错误。 p>

#define private foo 引起的未定义行为似乎不限于在之前执行标头 std #include ,例如它多么脆弱。


I want to define private and protected to public.

#define private public
#define protected public

Is this safe in C++?

解决方案

No, this almost certainly results in undefined behaviour.

From n4296 17.6.4.3.1 [macro.names] /2: (via @james below)

A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 2, or to the attribute-tokens described in 7.6.

private and public are keywords. Simply doing a #define on one of them is undefined behavior if you use anything in the C++ standard library:

17.6.4.1/1 [constraints.overview]

This section describes restrictions on C ++ programs that use the facilities of the C++ standard library.

If you do not, the restriction in 17.6.4.3.1 does not seem to apply.

The other way it could lead to violation is if you use the same structure with two different definitions. While most implementations may not care that the two structures are identical other than public vs private, the standard does not make that guarantee.

Despite that, the most common kind of UB is 'it works', as few compilers care.

But that does not mean it is 'safe'. It may be safe in a particular compiler (examine the docs of said compiler: this would be a strange guarantee to give, however!). Few compilers (if any) will provide the layout guarantees (and mangling guarantees) required for the above to work explicitly if you access the same structure through two different definitions, for example, even if the other possibilities of error are more remote.

Many compilers will 'just work'. That does not make it safe: the next compiler version could make one of a myriad of changes and break your code in difficult (or easy) to detect ways.

Only do something like this if the payoff is large.

I cannot find evidence that #defineing a keyword is undefined behavior if you never include any standard library headers and do not use it to make a definition different in two compilation units. So in a highly restricted program, it may be legal. In practice, even if it legal, it still isn't 'safe', both because that legality is extremely fragile, and because compilers are unlikely to test against that kind of language abuse, or care if it leads to a bug.

The undefined behavior caused by #define private foo does not seem to be restricted to doing it before the #include of the std header, as an example of how fragile it is.

这篇关于在C ++中将私有定义为公开的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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