C++访问说明符太少?

发布于 2024-09-24 14:36:42 字数 261 浏览 7 评论 0原文

据我所知,C++ 中只有 3 个访问说明符:privatepublicprotected

通过这 3 个访问说明符,我怎样才能使一个方法对项目中的类可用,但对“外国人”不可用??(如内部< C# 中的 /strong> 和 public

As far as i know, there're only 3 access-specifiers in C++: private, public, protected

With these 3 access-specifiers, how can i make a method usable to the classes in the project but unusable to the "foreigners" ??(like internal and public in C#)

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

扫码二维码加入Web技术交流群

发布评论

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

评论(4

冷默言语 2024-10-01 14:36:42

C++ 不知道什么是项目。

C++ 了解类,它提供了您提到的三个访问说明符。

C++ 了解翻译单元,它提供两个访问说明符:内部链接和外部链接。

编辑:关于内部和外部链接,这与符号是否会在翻译单元(目标文件)之外看到有关。 TU 中定义的任何全局staticconst 变量都具有内部链接。其他有外部链接。

C++ does not know what a project is.

C++ knows about classes, where it offers the three access specifiers you mentioned.

C++ knows about translation units, where it offers two access specifiers: internal and external linkage.

Edit: About internal and external linkage, this is related to whether a symbol will be seen outside of the translation unit (the object file). Any global static or const variable defined in the TU has internal linkage. Others have external linkage.

赤濁 2024-10-01 14:36:42

简而言之,你不知道。 C++ 与 C# 完全不同。

如果您不想让某个类在给定库或可执行文件之外可用,那么只需不要向项目的用户提供头文件即可。

Put simply, you don't. C++ is not anything like C#.

If you don't want to make a class available outside a given library or executable, then simply don't provide the header file to users of your project.

丶视觉 2024-10-01 14:36:42

您可以使用

不过,这不是您能够搜索的术语。这个想法并不新鲜,尽管不是很常见,而且是在 SO 上出现的。上面的链接是我对通用解决方案的尝试(在 C++03 中不可能干净地完成,在 C++0x 中很漂亮)。

我确信还有其他方法可以尝试做到这一点,但由于某种原因我对上述内容有附件...:)


但除此之外, 。一个更常见和更简单的解决方案是将您的内容放入 detail 命名空间中(在 中很常见例如,Boost),然后说“不要去那里”。

You can use the passkey friend idiom.

This isn't a term you'll be able to search for, though. The idea isn't new, though not terribly common, and sort of arose on SO. The link above is my attempt at a generic solution (impossible to do cleanly in C++03, beautiful in C++0x).

I'm sure there are other ways to try to do it, but for some reason I have an attachment to the above...:)


But otherwise, no. A far more common and simpler solution is to just throw your stuff in a detail namespace (common throughout Boost, for example), and say "don't go there".

岁吢 2024-10-01 14:36:42

与解决方案最接近的两个事情是

  1. 拥有一个在代码中使用但并未真正公开的内部命名空间。然后,您的库的用户可以使用您使用的供公共使用的任何名称空间。然而,它并没有强制执行。它只是令人困惑,因为他们不一定知道名称空间,或者被告知不要使用它,所以他们不知道。

  2. 使用朋友。这是由编译器强制执行的。如果一个类是另一个类的友元,或者一个函数是另一个类的友元,那么它可以访问其私有成员函数,而其他类则不能。不幸的是,这意味着朋友可以访问所有私有成员,因此它可以比您想要的更多地访问各种类或函数(尽管它会在您自己的类和函数中,而不是在您自己的类和函数中) )。

C++ 比 C#、Java 和 D 等语言更古老,它们可以让您对访问级别进行更细粒度的控制。 C++ 开创了很多此类东西,但它并不总是正确的。较新语言的设计者已经从中学习并在许多方面对其进行了改进,因此您将在较新语言中找到 C++ 所没有的某些概念(尽管有时 C++ 具有较新语言未采用的概念)。其他示例是包和密封/最终类和函数。

The two closest things that you have to a solution are

  1. Have an internal namespace that you use in your code which you don't really publicize. Users of your library then use whatever namespace that you use that is intended for public consumption. However, it's not enforced. It's just obfuscated in that they won't necessarily know about the namespace or are told not to use it, so they don't.

  2. Use friend. This is enforced by the compiler. If a class is a friend of another class, or if a function is a friend of a class, then it can access its private member functions while others can't. Unfortunately, that means that the friend has access to all private members, so it can give more access to various classes or functions than you'd like (though it would be within your own classes and functions rather than that of the users of your library).

C++ is older than such languages as C#, Java, and D which give you finer grained control over access levels. C++ pioneered a lot of this sort of stuff, and it didn't always get it right. Designers of newer languages have learned from it and improved upon it in many ways, so you're going to find certain concepts in newer languages which C++ just doesn't have (though sometimes C++ has concepts that newer languages didn't adopt). Other example would be packages and sealed/final classes and functions.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文