当前位置：文江博客话题详情

类成员访问说明符和二进制代码

发布于 2024-08-31 07:27:42 字数 259 浏览 9 评论 0原文

我了解典型的访问说明符是什么以及它们的含义。 “公共”成员可以在任何地方访问，“私有”成员只能由同一个班级和朋友等访问。

我想知道的是，如果有的话，这在较低级别的术语中相当于什么。它们之间的编译后功能差异是否超出了它们所使用的语言（本例中为 c++）所施加的高级限制（什么可以访问什么）。

另一种说法 - 如果这是一个完美的世界如果程序员总是做出好的选择（例如不访问以后可能会更改的成员，并且仅使用在实现之间应保持不变的定义良好的成员），那么他们有什么理由使用这些东西吗？

原文

分享到QQ

分享到微博

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

发布评论

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

岁吢 2024-09-07 07:27:42

访问说明符仅用于编译目的。程序分配的任何内存都可以由可执行文件的任何部分访问；运行时没有公共/私有概念

回复收藏 0 原文

请帮我爱他 2024-09-07 07:27:42

迈克尔的回答是正确的。访问说明符不会直接影响结果代码。

但是，访问说明符可以解决不明确的标识符/重载错误，否则会阻止编译。

class A {
private:
    int x;
};

class B {
protected:
    int x;
};

class C : public A, public B {
public:
    int &get_x() { return x; } // only B::x is accessible, no error.
};

所以它们肯定比限制程序员有更高的目的。

Michael's answer is right. Access specifiers do not directly affect the resulting code.

However, access specifiers may resolve ambiguous identifier/overload errors that would otherwise prevent compilation.

class A {
private:
    int x;
};

class B {
protected:
    int x;
};

class C : public A, public B {
public:
    int &get_x() { return x; } // only B::x is accessible, no error.
};

So they definitely serve a higher purpose than restricting the programmer.

回复收藏 0 原文

浅蓝的眸勾画不出的柔情 2024-09-07 07:27:42

您的问题的答案可能会因编译器的不同而有所不同，但一般来说不会有什么区别。人们可以设想这样一种环境，其中编译的代码对于这些不同的可访问性可能具有不同的特征，但我不知道存在任何这样的环境。

回复收藏 0 原文

躲猫猫 2024-09-07 07:27:42

程序员只有在掌握了正确的信息后才能做出正确的选择。访问修饰符是向程序员发出信号的一种方式，表明某些东西不应该被触及，并且它具有强制执行正确行为的副作用。

没有运行时影响。您可以使用正确的访问修饰符编写一个程序，并使用 c++ -Dprotected=public -Dprivate=public file.cc 进行构建，并且它应该构建并生成几乎完全相同的代码（有一些假设）注意事项，例如类的数据布局）。

回复收藏 0 原文

扬花落满肩 2024-09-07 07:27:42

编译后，您留下的机器代码（程序集）没有“公共”或“私有”（或类、成员等）的概念。一切都只是一个内存地址（无论是代码还是数据），并且可以像任何其他内存地址一样进行访问。整个公共\私有区别（以及高级语言中可用的几乎所有其他构造）纯粹是为了程序员的利益，允许编译器强制执行一组旨在实现代码意图的规则更清晰并有助于避免潜在的错误。编译后，您的代码不知道它最初是用什么语言编写的，更不用说使用什么类型的访问说明符了。

话虽如此，可以操纵编译器，以便每当调用 private 类成员函数时它都会修改代码，以便检测何时不恰当地调用该函数（添加一个额外的参数并设置当从类内部调用该函数时，它会达到某个预期值；从类外部调用该函数将提供错误的值）。这种方法的问题是你现在做什么？锁？什么都不做并返回无效数据？这些类型的问题在编译时（相对）很容易检测和纠正，因此很少看到在运行时强制实施此类问题（在调试或代码分析工具之外）。

回复收藏 0 原文

~没有更多了~