受保护的静态也可以公开? [英] Protected Static may as well be public?

查看:82
本文介绍了受保护的静态也可以公开?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我刚刚做了一个观察,我想知道它是否已经普遍知道(或者如果我遗漏了某些东西,那么就是
)。我的观察是静态保护

成员基本上没用,只是给用户一个提示。他们不会实际上保护任何封装或任何东西,并且对于他们提供的所有实际的保护,他们也可能是公开的。


例如:


B级{

受保护:

static int i;

static void f();

};


int B :: i = 0;

void f (){

}


没有什么能阻止任何人阅读或更改B :: i或从

调用B :: F()。所有人都需要做的是创建一个派生类,如

所以:


struct D:B {

static int&我(){返回B :: i; }

static void f(){B :: f(); }

};


而且,瞧,静态保护方法(间接)公开

可访问。两行代码开销加上一行给每个成员

。甚至没有人必须创建一个实例,所以私有

构造函数和析构函数也没有保护。


这是否通常已知(并且是正确的)?也许人们很少会成为受保护的静态成员,所以在实践中这很少是一个问题。

解决方案

< blockquote>好像你错误地解释了

c ++语言提供的访问权限!!!


c ++ dosn不能为你提供这种意外的安全感由

提供的一种加密算法可以抵御你的恶意企图,因为它很好。 c ++只是给你访问说明符,这样如果你想创建好的软件你可以创建它。但是,如果你想要滥用访问说明符,你也可以这样做。


虽然这个静态成员案例没什么特别之处。如果您在基类中有受保护的成员并且某些派生的

类函数返回可以访问这些受保护的成员,那么

sceurtiy可以绕过
对象

为此公开一些公共功能。


谢谢

rt


ra ************ @ gmail。 com 写道:

c ++ dosn不能为你提供一种可以承受恶意企图的加密算法所提供的安全感。
好。 c ++只是为您提供访问说明符,这样如果您想创建好的软件,您就可以创建它。


我理解。但在大多数其他情况下,你必须做一些事情

狡猾的像一个奇怪的演员或预处理器黑客可能会调用

UB打破封装(假设这个类别很好

设计)。在这种情况下,使用相当基本的

语言功能来实现访问。

但是如果你想要滥用访问说明符,你也可以这样做。


嗯,更重要的是,考虑到这是多么容易,当你成为一个受保护的静态成员时,你要求什么样的
保护? br />
即使你丢弃了恶意的意图,也很容易泄露给任何人泄漏。


当我使一个成员函数受到保护,我保证只有

派生类才能调用它,然后才能自己调用​​

或他们自己类的实例。我看不到

" protected static"给出的类似保证。任何地方的任何人。

虽然这个静态成员案例没什么特别之处。如果在基类中有受保护的成员,并且某些派生的类函数返回通过为此公开一些公共函数来访问这些受保护的memeber对象,则可以绕过相同的
。 。




是的,但在这种情况下,只有设计糟糕的类的实例才会暴露出来。从B继承的任何其他类仍将完全受到保护。 B本身的实例受到完全保护。


Adam H. Peterson写道:

< snip>

我明白这一点。**但是* * *大多数*其他*情况,*你*有*做什么*狡猾的东西像一个奇怪的演员或预处理器
黑客可能会调用UB打破封装
(假设该类设计得很好)。**在这个*案例中,* access * * * *使用*相当*基本的
语言功能实现。


< snip>


您可以宣传所有受保护的成员(数据和方法,

静态和非静态)在派生类中公开,

所以你也可以声称所有受保护的成员都可以公开。更重要的是,如果您真的尝试,您可以访问

任何私人数据或会员:


等级泄漏{

int i;

void f();

public:

template< typename T>

void foo(T& t);

};


struct Intruder {int i; void(Leaking :: * f)(); };


模板<>

无法泄漏:: foo<入侵者>(入侵者和入侵者){

intruder.i = i;

intruder.f = f;

}


int main(){

泄漏l;

入侵者i;

l.foo(i);

if(); //调用私人会员功能!

}


这是否意味着所有私人会员都可以公开?
公开?肯定不行。


Marc


I just made an observation and I wondered if it''s generally known (or
if I''m missing something). My observation is that static protected
members are essentially useless, only a hint to the user. They don''t
actually protect any encapsulation or anything, and for all the actual
protection they offer, they might as well be public.

For example:

class B {
protected:
static int i;
static void f();
};

int B::i=0;
void f() {
}

Nothing stops anybody anywhere from reading or changing B::i or from
calling B::f(). All anyone needs to do is create a derived class like
so:

struct D : B {
static int &i() { return B::i; }
static void f() { B::f(); }
};

And, voila, the static protected method is (indirectly) publicly
accessible. Two lines of code overhead plus a line for each member to
be exposed. No one even has to create an instance, so private
constructors and destructors are no protection either.

Is this generally known (and is it correct)? Maybe people seldom make
protected static members, so it''s rarely an issue in practice.

解决方案

seems like you are misinterpreting the scecurity access provided by the
c++ language!!!

c++ dosn''t offer you the scecurity in the sense of the one provided by
some encryption algorithm that can withstand your malicious attempts as
well. c++ just gives you access specifier so that if you want to create
good software you can create that. however if you
want to misuse the access specifiers u can do that as well.

though nothing special about this static members case only. the same
sceurtiy can
be bypasses if you have protected member in base class and some derived
class function returns gives access to these protected memeber objects
by exposing some public functions for this.

thanks
rt


ra************@gmail.com wrote:

c++ dosn''t offer you the scecurity in the sense of the one provided by
some encryption algorithm that can withstand your malicious attempts as
well. c++ just gives you access specifier so that if you want to create
good software you can create that.
I understand that. But in most other cases, you have to do something
crafty like a weird cast or a preprocessor hack that probably invokes
UB to break encapsulation (assuming the class is otherwise well
designed). In this case, access is achieved using fairly basic
language features.
however if you
want to misuse the access specifiers u can do that as well.
Well, more to the point, considering how easy this is, what kind of
protection are you asking for when you make a protected static member?
It''s rather easy for access to leak out to just about anyone even if
you discard malicious intent.

When I make a member function protected, I have the assurance that only
derived classes will be able to invoke it, and then only on themselves
or instances of their own class. I see no similar assurance given by
"protected static" to anyone anywhere.
though nothing special about this static members case only. the same
sceurtiy can
be bypasses if you have protected member in base class and some derived
class function returns gives access to these protected memeber objects
by exposing some public functions for this.



True, but in this case only instances of the poorly designed class are
exposed. Any other class inheriting from B will still be fully
protected. And instances of B itself are fully protected.


Adam H. Peterson wrote:
<snip>

I understand that.**But*in*most*other*cases,*you*have*to
do*something crafty like a weird cast or a preprocessor
hack that probably invokes UB to break encapsulation
(assuming the class is otherwise well designed).**In
this*case,*access*is*achieved*using*fairly*basic
language features.


<snip>

You can promote all protected members (data and methods,
both static and non-static) to public in derived classes,
so you can as well claim that all protected members could
as well be public. What''s more, you can give access to
any private data or member if you really try:

class Leaking {
int i;
void f();
public:
template <typename T>
void foo( T & t );
};

struct Intruder { int i; void (Leaking::*f)(); };

template <>
void Leaking::foo<Intruder>( Intruder & intruder ) {
intruder.i = i;
intruder.f = f;
}

int main() {
Leaking l;
Intruder i;
l.foo( i );
i.f(); // calls private member function!
}

Does that mean that all private members may as well be
public? Surely not.

Marc


这篇关于受保护的静态也可以公开?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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