By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,433 Members | 1,643 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,433 IT Pros & Developers. It's quick & easy.

What c++ doesn't show error

P: n/a
Hi,

I've a class

class A
{
private:
int _mem;
public:
void foo(A a)
{
_mem = 0;
_a.mem = 0;//not showing access viloation error
}

};

In the above function I'm accessing object a's private member by
a._mem. Why c++ is not restricting private member access inside a
member fn
even if the object is different?

Is there any specific reason for this?
Nov 12 '08 #1
Share this Question
Share on Google+
12 Replies


P: n/a
On 12 nov, 09:08, Faisal <faisal...@gmail.comwrote:
Hi,

I've a class

class A
{
private:
* * * * int _mem;
public:
* * * * void foo(A a)
* * * * {
* * * * * * * * _mem = 0;
* * * * * * * * _a.mem = 0;//not showing access viloation error
* * * * }

};

In the above function I'm accessing object a's private member by
a._mem. Why c++ is not restricting private member access inside a
member fn
even if the object is different?

Is there any specific reason for this?
Because foo is a member function of A. Inside member functions you're
allowed to access private members on any instance of the class (not
only on the 'this' instance).
--
Leandro T. C. Melo
Nov 12 '08 #2

P: n/a
On Nov 12, 4:21*pm, Leandro Melo <ltcm...@gmail.comwrote:
On 12 nov, 09:08, Faisal <faisal...@gmail.comwrote:
Hi,
I've a class
class A
{
private:
* * * * int _mem;
public:
* * * * void foo(A a)
* * * * {
* * * * * * * * _mem = 0;
* * * * * * * * _a.mem = 0;//not showing access viloation error
* * * * }
};
In the above function I'm accessing object a's private member by
a._mem. Why c++ is not restricting private member access inside a
member fn
even if the object is different?
Is there any specific reason for this?

Because foo is a member function of A. Inside member functions you're
allowed to access private members on any instance of the class (not
only on the 'this' instance).

--
Leandro T. C. Melo
I would like to know why c++ allows it. Is there any particular reason
for this?
Nov 12 '08 #3

P: n/a
On 12 nov, 09:21, Leandro Melo <ltcm...@gmail.comwrote:
On 12 nov, 09:08, Faisal <faisal...@gmail.comwrote:
Hi,
I've a class
class A
{
private:
* * * * int _mem;
public:
* * * * void foo(A a)
* * * * {
* * * * * * * * _mem = 0;
* * * * * * * * _a.mem = 0;//not showing access viloation error
* * * * }
};
In the above function I'm accessing object a's private member by
a._mem. Why c++ is not restricting private member access inside a
member fn
even if the object is different?
Is there any specific reason for this?

Because foo is a member function of A. Inside member functions you're
allowed to access private members on any instance of the class (not
only on the 'this' instance).

--
Leandro T. C. Melo

Notice that you have some typos in function foo... (_a.mem should be
a._mem)
--
Leandro T. C. Melo
Nov 12 '08 #4

P: n/a
On Nov 12, 2:08*pm, Faisal <faisal...@gmail.comwrote:
Hi,

I've a class

class A
{
private:
* * * * int _mem;
public:
* * * * void foo(A a)
* * * * {
* * * * * * * * _mem = 0;
* * * * * * * * _a.mem = 0;//not showing access viloation error
* * * * }

};

In the above function I'm accessing object a's private member by
a._mem. Why c++ is not restricting private member access inside a
member fn
even if the object is different?

Is there any specific reason for this?
Hi

Because a member function of class A has access to private members of
an object of itself. Compare the foo member function with other
following Foo s:
class B {
int i;
};
class A {
public:
void foo(B b)
{
b.i = 1; // cannot access private member declared in class B
}

};

or

class A {
int _mem;
};

void foo(A a) // non-lobal function
{
a._mem = 0; // cannot access private member declared in class A
}

In other words a member function of class A is friends to all objects
of A.

Regards,
Saeed Amrollahi
Nov 12 '08 #5

P: n/a
On Nov 12, 2:29*pm, Faisal <faisal...@gmail.comwrote:
On Nov 12, 4:21*pm, Leandro Melo <ltcm...@gmail.comwrote:


On 12 nov, 09:08, Faisal <faisal...@gmail.comwrote:
Hi,
I've a class
class A
{
private:
* * * * int _mem;
public:
* * * * void foo(A a)
* * * * {
* * * * * * * * _mem = 0;
* * * * * * * * _a.mem = 0;//not showing access viloation error
* * * * }
};
In the above function I'm accessing object a's private member by
a._mem. Why c++ is not restricting private member access inside a
member fn
even if the object is different?
Is there any specific reason for this?
Because foo is a member function of A. Inside member functions you're
allowed to access private members on any instance of the class (not
only on the 'this' instance).
--
Leandro T. C. Melo

I would like to know why c++ allows it. Is there any particular reason
for this?- Hide quoted text -

- Show quoted text -
The life will be difficult if you can't access to yourself. If A
member function of class A doesn't has access to its object, you as a
class designer will have to
1. declare data members public or
2. define accessor member functions for all data members.

Best
Saeed Amrollahi

Nov 12 '08 #6

P: n/a
On 12 nov, 09:29, Faisal <faisal...@gmail.comwrote:
>
I would like to know why c++ allows it. Is there any particular reason
for this?
Well, I think that's the usual behavior in most programming languages.
Basically, in a object oriented design encapsulation is provided in
the class level, not in the object level.
--
Leandro T. C. Melo
Nov 12 '08 #7

P: n/a
On 2008-11-12 06:29:41 -0500, Faisal <fa*******@gmail.comsaid:
On Nov 12, 4:21┬*pm, Leandro Melo <ltcm...@gmail.comwrote:
>On 12 nov, 09:08, Faisal <faisal...@gmail.comwrote:

>>I've a class
>>class A
{
private:
┬* ┬* ┬* ┬* int _mem;
public:
┬* ┬* ┬* ┬* void foo(A a)
┬* ┬* ┬* ┬* {
┬* ┬* ┬* ┬* ┬* ┬* ┬* ┬* _mem = 0;
┬* ┬* ┬* ┬* ┬* ┬* ┬* ┬* _a.mem = 0;//not showing access viloa
tion error
>>┬* ┬* ┬* ┬* }
>>};
>>In the above function I'm accessing object a's private member by
a._mem. Why c++ is not restricting private member access inside a
member fn
even if the object is different?
>>Is there any specific reason for this?

Because foo is a member function of A. Inside member functions you're
allowed to access private members on any instance of the class (not
only on the 'this' instance).

I would like to know why c++ allows it. Is there any particular reason
for this?
Try writing a copy constructor or a copy assignment operator when you
can't get at the internals of the thing you're copying.

Access restrictions in C++ help protect against errors, not against malice.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Nov 12 '08 #8

P: n/a
Faisal wrote:
I would like to know why c++ allows it. Is there any particular reason
for this?
How would you write a copy constructor if you weren't able to access
the private members of the object you got as the parameter of your
constructor?

Besides, consider this:

void A::foo(A a)
{
A* ptr;
if(someObscureFunction())
ptr = this;
else
ptr = &a;

ptr->privateMember = 5; // Error or not?
// How would the compiler know?
}
Nov 12 '08 #9

P: n/a
Faisal wrote:
On Nov 12, 4:21 pm, Leandro Melo <ltcm...@gmail.comwrote:
>Inside member functions you're
allowed to access private members on any instance of the class
I would like to know why c++ allows it. Is there any particular reason
for this?
The compiler doesn't necessarily know whether the incoming instance is
"this" or not, because the decision may not be made until run time.
Anyway, C++ isn't python; the question usually is whether there's any
particular reason to prohibit something, rather than whether there's any
reason to allow it. C++ gives you a lot of rope.
Nov 12 '08 #10

P: n/a
On 12 Nov, 17:37, Juha Nieminen <nos...@thanks.invalidwrote:
Faisal wrote:
I would like to know why c++ allows it. Is there any particular reason
for this?

* How would you write a copy constructor if you weren't able to access
the private members of the object you got as the parameter of your
constructor?

* Besides, consider this:

void A::foo(A a)
{
* * A* ptr;
* * if(someObscureFunction())
* * * * ptr = this;
* * else
* * * * ptr = &a;

* * ptr->privateMember = 5; // Error or not?
* * * * * * * * * * * * * * // How would the compiler know?
}
But that example's not totally convincing - what about this?

int someObscureFunction();

class base {
protected: int privateMember; };

class A : public base {
public: void foo(base a); };

void A::foo(base a) {
base* ptr;
if(someObscureFunction())
ptr = this;
else
ptr = &a;

this -privateMember = 5; // OK
ptr -privateMember = 5; // Error or not?
// How would the compiler know?
}
Nov 12 '08 #11

P: n/a
On Nov 12, 11:38 pm, gw7...@aol.com wrote:
On 12 Nov, 17:37, Juha Nieminen <nos...@thanks.invalidwrote:
Faisal wrote:
I would like to know why c++ allows it. Is there any
particular reason for this?
How would you write a copy constructor if you weren't able
to access the private members of the object you got as the
parameter of your constructor?
Besides, consider this:
void A::foo(A a)
{
A* ptr;
if(someObscureFunction())
ptr = this;
else
ptr = &a;
ptr->privateMember = 5; // Error or not?
// How would the compiler know?
}
But that example's not totally convincing - what about this?
int someObscureFunction();
class base {
protected: int privateMember; };
class A : public base {
public: void foo(base a);
};
void A::foo(base a) {
base* ptr;
if(someObscureFunction())
ptr = this;
else
ptr = &a;
this -privateMember = 5; // OK
ptr -privateMember = 5; // Error or not?
// How would the compiler know?

}
This second example is an error. The rights you acquire by
being in a member function of A only apply to objects known to
be of type A. Since *ptr is not known to be of type A, member
functions of A can only access its public members.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientÚe objet/
Beratung in objektorientierter Datenverarbeitung
9 place SÚmard, 78210 St.-Cyr-l'╔cole, France, +33 (0)1 30 23 00 34
Nov 13 '08 #12

P: n/a
On 13 Nov, 09:03, James Kanze <james.ka...@gmail.comwrote:
On Nov 12, 11:38 pm, gw7...@aol.com wrote:
On 12 Nov, 17:37, Juha Nieminen <nos...@thanks.invalidwrote:
Faisal wrote:
I would like to know why c++ allows it. Is there any
particular reason for this?
How would you write a copy constructor if you weren't able
to access the private members of the object you got as the
parameter of your constructor?
Besides, consider this:
void A::foo(A a)
{
* * A* ptr;
* * if(someObscureFunction())
* * * * ptr = this;
* * else
* * * * ptr = &a;
* * ptr->privateMember = 5; // Error or not?
* * * * * * * * * * * * * * // How would the compiler know?
}
But that example's not totally convincing - what about this?
int someObscureFunction();
class base {
* protected: int privateMember; };
class A : public base {
* public: *void foo(base a);
};
void A::foo(base a) {
base* ptr;
if(someObscureFunction())
* ptr = this;
else
* ptr = &a;
this -privateMember = 5; // OK
ptr -privateMember = 5; // Error or not?
* * * * * * * * * * * * * // How would the compiler know?
}
This second example is an error. *The rights you acquire by
being in a member function of A only apply to objects known to
be of type A. *Since *ptr is not known to be of type A, member
functions of A can only access its public members.
Ah. I didn't explain what I meant at all clearly. Sorry.

You are right that in my code, the compiler happily objects to an
error at the "ptr -privateMember = 5;" line.

However, my code is similar to Juha's example, and the language could
have been set up (it wasn't, but it could have been) so that in Juha's
code the line "ptr->privateMember = 5;" was equally an error. Instead
the language was set up so that a class is a friend of itself, and
"ptr->privateMember = 5;" works whether or not ptr is this or not.

My point was that the existence of code such as Juha's did not compel
the language to be set up so that a class was a friend of itself.

The copy constructor argument is a more compelling argument.

Regards.
Paul.
Nov 13 '08 #13

This discussion thread is closed

Replies have been disabled for this discussion.