Visibility in C++

[ExplosiveBrohoof]

That feel when you have no friends that want to access your private members.

[leixun]

*My takeaways:*
1. Private 1:49, only this class and its Friend class can access Private attributes
2. Protect 3:20, only this class and its subclass can access Protect attributes
3. Public 3:56, everything can access Public attributes
4. Why do we want to use them rather than using Public all the time? 4:17

[martiananomaly]

The UI example was really great! I love how you always showcase the practical use of a concept.

[bygonefire]

Cherno, Your videos are really good! Any chance you can do a day in the life at EA or something similar, I would love to see what its like eg, your workspace, the programs you use

THanks! <3

[BasicPoke]

I really appreciate your explanation of why certain things should be done, their implications, etc. This is much more difficult to explain than to start typing code and show how it's done, which is what most "teachers" do. Keep up the good work. I am using your videos to refresh my C++ skills and prepare for interviews. I would appreciate you moving slower, especially when typing code. When you type out something very quickly, then the screen jumps because you scrolled, it's very hard for me to absorb what just happened.

[canadianblitz]

we're gonna have a class on friends, guys! FRIENDS!

[KennethFeur]

Recently had a chance to use a library where the author decided to make one important method private. Had to throw away that trash and write my own.
It was a library for an API, where each API entry has its corresponding method in a class. User-facing methods call private method `request` under the hood. The author made `request` private because he thought users will not need to call it directly. But after some time the company added new functionality to their API and didn't update the library. Now users can't use new API functions. Good job!
All you had to do was make the `request` method public, CJ!

[WayneRiesterer]

I've usually made members private where possible, i.e. leaned towards the 'always'. The reason for this is that it allows additional checks or functionality to be added to getters/setters if needed in the future. By doing things this way, there is no need to refactor the calling code. Any changes are confined to the class only. Having said that, I've rarely had to change member access to allow additional functionality; so having the flexibility up-front may not really pay dividends. I guess from a performance point-of-view, allowing direct access would be better. Using getters/setters is a pain in terms of boilerplate code.

[DanielKierkegaardAndersen]

Why is it that your content always is of pure quality... Especialy how your episodes end... Keyboard + music, while keeping it clean, simple and soothing n.n

[vertigo]

01:44 Wheres your link goin? nowhere! GOIN. NOWHERE.

Cherno just a reminder to update the video to add link to Structs versus Classes video.

Keep up the good work.

[sharper]

Thanks for these videos! This has the potential to be the best C++ tutorial on youtube

[manafon]

Another Advantage of using visibility properly aside from the code being easier to understand / remember is that when you have a bug you won't have to chase a variable you need to debug through the whole project because you can't remember which external class actually modified it or for what purpose, it really makes debugging a lot faster.

[rcookie]

thanks for the many uploads recently!!

but at 1:45 you forgot to place the link to the struct/class videos, didn't you??

[ZulnorineP_Coding]

the camparison b/w the private and public usage is given Check and observe which one is good to
#include <iostream>
#include <vector>
using namespace std;

class observing
{
int a, b ;
public :
void accessing ()
{
vector <observing> fr;
int size;
cout << " enter how much time you want to run the loop " << endl;
cin >> size;
for (int i=0;i<size;i++)
{
//creating the instance of the class
observing sure;
cout << " enter the value for a " << endl;
cin >> sure.a;
cout << " Enter the value for b is " << endl;
cin >> sure.b;
fr.push_back(sure);
}
for (auto & element : fr)
{
cout << " The value for a is " << element.a << " The value for b is " << element.b << endl;
}
}
};

int main ()
{
observing obj;
obj.accessing();

return 0;
}
PUBLIC CHECKING PUBLIC CHECKING
#include <iostream>
#include <vector>
using namespace std;

class publicChecking
{
public :
int a, b;
};

int main ()
{
publicChecking first;// creating the instance to the class..
vector <publicChecking> fr;
int size;
cout << " Enter the running time for the loop " << endl;
cin >> size;
for (int i=0;i<size;i++)
{
cout << " Enter the value for a " << endl;
cin >> first.a;
cout << " Enter the value for b " << endl;
cin >> first.b;
fr.push_back(first);
}
for (publicChecking & element : fr)
{
cout << " The value for a is " << element.a << " The value for b is " << element.b << endl;
}


return 0;
}
Now comment which one is the best to use which one is large in length of code and which one is small....

[hansdampf]

I think when stroustrup came up with “friend” he was just high

[Heyothatsittahowski]

Hi Cherno Big fan of your channel here.

I think it might be more explanatory to title as "Accesibility" instead of "Visibility". Because in a context they can "see" the private methods/members but they can not "access" it.

When you try to compile a class with private method called elsewhere than class itself, compiler gives "accessibility error" not visibility.

I would just wanted to tell the small difference because I think It is important to have that kind of realization as a developer.

Cheers :)

[karmavil]

People tend to write getters and setters to access their private stuffs (encapsulating everything), but what really happens is that usually the project development is late and most of that things are fixed when testing (if testing is done ...), so instead of apply filters in setters they end up with a lot of "extra code".
That is not wrong because you develop your entire project using best practices and so you apply filters to your Entities and not re writing your entire project.
I bet if you go for a project in development process you will find what I mean.. a lot of useless code (but best practices).
Like you said, visibility is related to maintenance.. but for some reasons `best practices` are not visible for `dead lines`

[HappyMatt]

I'm still learning C++, but I do code in C# because I make games using the Unity engine, and I imagine visibility applies just as much in object-oriented C++. I think a good rule of thumb is to make all of your variables and methods private unless you actually need to access them from outside of their class because it makes it easier to keep your code organized, prevents you from feeling tempted to directly modify something you shouldn't, and when you have an error, it makes it much easier to pinpoint what you did wrong where. Also on the topic of visibility and how I use it, you're right, I can't say I always make class members private but I ALMOST always do unless the class is a collection of values that I reference in several scripts (such as user-specific data, like a players high score) except for a few exceptional cases and write public 'getter' methods and in specific cases setters, even setters I don't like because that makes it easier for class co-dependencies to form, and co-dependency leads to further co-dependency and then when something breaks it takes you two hours to fix it because your code is like a pile of yarn you need to sift through, so that's my stance on that. Great explanation as always tho!

[fishyperil]

really cool and simple explanation on what the point of visibility actually is !
I knew about it and how it works for some time but was always like "wtf is even the point of this " ^^. now it makes sense, cheers

[xkrypton]

even after 7 years this is still the best c++ series on youtube.