Fed up of a concept in c++

[DaemonAkaDevil]

Hello friends ,

I am learning c++ and am a n00b in c++ , for one month i am trying to understand a concept but unable to , here it is :

when we create a class like:

class daemon{

int data;

public:

void _function(){}

}

now i want to ask that if we create a object with in the class why _function inside class can enter private data of that object too ?? it has only access to pvt data of that class but why objects too??

as you all know that i am a n00b , please teach me as a n00b i'll be yours debtor if you can solve my this problem !!

[slickshoes]

Possible you can rephrase the question? Maybe provide an example.

[Hnefi]

I'm not sure I understand your question. Objects are just instances of classes. A class is to an object what Ford Fiesta is to the car parked across the street.

Objects can, of course, manipulate their own data, private or not. If an object could not reach its own data, then how would it be reached?

[bovinedragon]

your question is not very clear, but the 'private' only means that it cannot be accesed from outside the class. Functions inside the class, no matter if they may be private or public, can access anything inside the class. The private, public and protected do not limit the other members of the same class, but limit how they may be acessed from outside the class

access premission
public: everyting inside class, friend classes, outside of class
protected: everyting inside class, friend classes
private: everyting inside class

There is not way to deny acces of things inside the same class, like _function, from the other memebrs of that class, like the int.

[JamesSchumacher]

your question is not very clear, but the 'private' only means that it cannot be accesed from outside the class. Functions inside the class, no matter if they may be private or public, can access anything inside the class. The private, public and protected do not limit the other members of the same class, but limit how they may be acessed from outside the class

access premission
public: everyting inside class, friend classes, outside of class
protected: everyting inside class, friend classes
private: everyting inside class

There is not way to deny acces of things inside the same class, like _function, from the other memebrs of that class, like the int.

Actually, friend classes can access private data the same way as a friend function can. And derived classes can access public and protected data members as well. (Public, Protected, and Private inheritance apply to how the derived sees the members)

And as far as the question of the post, I think he means this.

class daemon
{
private:
    int Value;

public:
    void _Function()
    {
        daemon objInside;

        objInside.Value = 100;
    }

    // Static Members can do the same thing

    static void _Function2()
    {
        daemon objInside;

        objInside.Value = 100;
    }
};

[DaemonAkaDevil]

Actually, friend classes can access private data the same way as a friend function can. And derived classes can access public and protected data members as well. (Public, Protected, and Private inheritance apply to how the derived sees the members)

And as far as the question of the post, I think he means this.

class daemon
{
private:
    int Value;

public:
    void _Function()
    {
        daemon objInside;

        objInside.Value = 100;
    }

    // Static Members can do the same thing

    static void _Function2()
    {
        daemon objInside;

        objInside.Value = 100;
    }
};

Thanks bro you're right i meant same thing , can you explain this how its done ?? why _function can access objects private data of objInside , when it has only access to it class pvt data .

thanks!!!

[GCDEF]

An object can access private data in an object of the same class, private or otherwise. That's just the way it is. Private restricts data by class, not by object.

[DaemonAkaDevil]

"Private restricts data by class, not by object." -> unable to understand this line!

[JVene]

Private restricts data by class, not by object.

And perhaps it is a bit terse; it makes sense to those of us already familiar with the subject.

private (or protected) access is applied across all instances of a class, not just to (or within) a particular instance.

When you substitute the word object for 'instance of a class' it may be a little clearer.

Essentially, its what the posted example code in JamesSchumacher illustrated.

Put another way, if you create an instance of a class while in a function of that class, as that code does, access to private data in the new, temporary instance is permitted because the restriction applies to the class, not to the instance of the class upon which the original function call was made.

This restriction isn't intended to provide security. The idea of private and protected members and functions is that of declaring what is internal to the workings of the class, and (for public) what is external (or what is intended for application code to use and access).

One (of many) way(s) to view the notion of objects is that of the black box component. I happen to be an electronics hobbyist, and I create gadgets for various purposes. The outer box of whatever device I create may have a knob or two, a switch, maybe a gauge, possibly some jacks for input, output and power. These are exposed to the 'user' of the gadget, and what I guarantee is for their use.

Internally there will be any number of components, wires, interconnections, possibly other knobs which I set when I created the device. These are not exposed to the user, because I don't guarantee they can be of any use in the otherwise normal functioning of the device. If unskilled users were to meddle with the internal wiring, or adjust the internal knobs which calibrate the device, its operation would no longer be what I could guarantee. They would be, in essence, modifying my design.

This analogy breaks down a bit, though, because it DOES suggest the privacy of the internal components is by instance (privacy for each copy of this device I create, such that devices couldn't 'see' into each other). In classes, this isn't the case, yet the overall sense of what is kept internal (private and protected) or external (public) is the thrust behind using these features in C++. It helps create objects that have clearly defined usage, while having complex internal workings, making the object more like a device or component than just a bunch of code.

Since the focus isn't with regard to security, there's little reason to impose the privacy restriction of various instances against each other. Doing so may have even been considered an impediment, because certainly we see that instances of a class may have reason to work directly with each other. It is the privacy restriction of other code that is of importance.

[SuperKoko]

JVene gave a good explanation.
I'll try to give another one.

Carefully note that "object" means "class instance".

The C++ access rights model is different from the SmallTalk one, and is partially due to a different apprehension of relationship between methods and objects.

In SmallTalk methods are members of objects, tied to a specific object. They're actors from inside the object.
In SmallTalk, a method is a little daemon living inside the black box. It doesn't cooperate with any high level entity. It lives with the specific object only.

In C++ methods are members of classes. In C++, methods are actors, living outside of objects, and are separate entities, though the principle of class allows one to put together objects and methods.
Analogy: Electricity provided to every house is counted with sealed counters (at least in France). Access to users is forbidden. These counters are owned by EDF (Electricité De France), and only EDF employees are allowed to open these.
Counters are C++ objects.
EDF employees are actors allowed to access these objects.
They don't live inside the black box. They live outside it, and can act on many of them.

Consequences.

In SmallTalk, the notion of static method doesn't exist... In C++, it does.
In SmallTalk, methods (the little daemons) are restricted to using their object. They cannot access private parts of other instances of the same class!

In C++, methods can access the inside of all objects of the class. Whenever a method gets a reference to ANY object of that class (through a global variable, a parameter, the this pointer, creation inside it, creation through a call to another function, etc.), it can access to its internal details.

The C++ approach, has many advantages. Actually, the SmallTalk approach is pretty, simple, cute, but doesn't work very well in real world.

Relevant example:

Assume you want to write a BigNum class. BigNums have an internal representation that only mathematicians can understand and exposing it to users is useless, as they only want to add, substract, multiply, divide and compare numbers.

-- SmallTalk --
In SmallTalk, where could we put the Add() method?
As a member of every object? But... If to add two numbers, there are TWO objects involved. The daemon inside the first object cannot access to the data inside the second object!
The daemons need to communicate somehow! Unfortunately, daemons have no telepathic powers. They're very lonely creatures, and they don't like to cooperate.
When cooperating, they need to do so through high level human language.

So, to add two numbers, in SmallTalk, there must be a hole in every number, through which the daemon can publically communicate (i.e. some public methods giving access to internal implementation details), so that daemons can communicate their data. The daemon makes no difference between human people and other daemons... They're very self centered, and, for them, everything outside of their little box is "the outside", including other daemons of the same specy.
That's a problem: Your black box is not closed anymore.
Second problem: There's an assymetry. One of the two daemons must start the communication, and must do part, or all, the calculus, and must build a new number...

Now, when someone wants to add two numbers, he must ask to one daemon, through a public interface, to adds itself to the other daemon... Then, they start their communication, and the first daemon produces a new number.

-- C++ --
In C++, where could we put the Add() method?
As a member of the class!
As a friend overloaded operator+ (friend functions, conceptually, are members of the class), or a Add() static method.
This method is a highly skilled employee, with a math degree, hired by the numbers objects corp., member of this corp., who knows the internal details that share all numbers, and has a key that opens all these numbers.
He is familiar with all the numbers, and like them all equally. He is not bound to a particular number.

When someone needs to add two numbers, he asks to this employee, who serves everybody who has bought two numbers or more, to add the two numbers.
The employee comes, open the two numbers with a key, look at the internal details (i.e. access private data or invoke private methods), and generate a fresh new number.

About virtual methods: A virtual method is nothing more than an employee whose telephone number is written on the object and who is entirely responsible of maintaining this object (he can be called whenever anybody who uses the object needs his service), but is highly skilled and able to access any other object, though he may have specific knowledge about specific types of these objects.

I'm not sure it helps, but at least, reading my post should have been entertaining.

[DaemonAkaDevil]

Thanksssssssssss a lot friends , i got the concept , btw i would like to tell you guyz that soon i'll be shifting to visual c++ soon !!

[DaemonAkaDevil]

I am almost giving up , again got confused cause always my mind stop at the concept of object s. while learning other things of c++ .

here is visualization of my problem!



please start reading it from bottom!!

[ZuK]

It seams that you still don't understand the difference between a class and an instance of a class.
The class can be seen as a set of rules to manipulate the data ( state ) of instances of that class ( objects ).
In your example both objects are of type mammal so both objects know the rules how to manipulate mammals.
C++ allowes a mammal to manipulate mammals, no matter if it is the same instance or another, it trusts that they always play according to the rules.
And then, I can't even imagine how a language that doesn't allow that would implement something like a copy constructor, if an object can't access all the data of another object of the same type.
Kurt

[sunnypalsingh]

Classes are a way to localize all the state (data) and services (typically member functions) associated with a cohesive concept. The main idea is to organize things so that when changes to the concept or abstraction occur (as is inevitable), it will be possible to go to one place to make the necessary modifications.

To a programmer, an object is a region of storage with associated semantics. To a designer, an object is any identifiable component in the problem domain.

As an analogy, consider a home. A home is like an object since it has state (whether the lights are on, ambient temperature, and so on) and it provides services (a button that opens the garage door, a thermostat that controls the temperature, an alarm system that detects intruders, and so on). To carry the home metaphor a bit further, a blueprint for a home is like a class since a blueprint defines the characteristics of a group of similar homes.

[DaemonAkaDevil]

Actually i understands the rules but let me divide my question :-

Inside the class (class definition ) you have (its you! , not methods, cause member methods has always access to its pvt data , whether you're outside or not) access to pvt data .
so that you can access pvt data of the object of same class too (cause you're inside the class definition).

in my questions please always note the position where you're (outside the class, inside class definition ,etc)

when you're are outside the class -> you don't have access to private data (cause you're out side the class definition and you've declared it in main function or where ever) , so that you can't access the object too? (cause it is inherited by the rules of his class)

i would feel great if one of you can teach me or clear my confusion by a animation or by an image!

Thansssssssssssssssssss!!