Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Friend Classes #29

Open
ada-foss opened this issue Oct 15, 2012 · 0 comments
Open

Friend Classes #29

ada-foss opened this issue Oct 15, 2012 · 0 comments

Comments

@ada-foss
Copy link
Collaborator

Making some unrelated changes I noticed that lidarquadtree (and maybe the main body of LAG) mostly just defines every value and function as protected, then makes the classes that need those classes friends.

I poked around looking at QuadtreeNode as my example. I'm certain that this class is completely internal to the quadtree. QuadtreeNode is not an outward facing class, nothing outside of the library should be able to access it or refer to it, so I would argue that everything that uses it should use only public components (of which there are currently none), and that QuadtreeNode should have no friends at all.

What I would really like is for C++ to be more capable of specifying more exactly what should be able to access what. Or perhaps these classes should be more broken up? Just speculation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant