Is violating access scope an undefined behavior?

K

Kira Yamato

// Is the following code well-defined?

class A
{
private:
int foo(int n);

public:
typedef int (A::*ftype)(int);

ftype get() const { return &A::foo; }
};

int main()
{
A a;
A::ftype f = a.get();

(a.*f)(5);

return 0;
}

// Thank you.

// --

// kira
 
K

kasthurirangan.balaji

// Is the following code well-defined?

class A
{
private:
        int foo(int n);

public:
        typedef int (A::*ftype)(int);

        ftype get() const { return &A::foo; }

};

int main()
{
        A       a;
        A::ftype f = a.get();

        (a.*f)(5);

        return 0;

}

// Thank you.

// --

// kira

compiling the code with xlC(AIX) and CC(solaris) compilers, the error
is
Undefined symbol: A::foo(int)

Thanks,
Balaji.
 
S

Szabolcs Ferenczi

// Is the following code well-defined?

class A
{
private:
        int foo(int n);

public:
        typedef int (A::*ftype)(int);

        ftype get() const { return &A::foo; }

};

int main()
{
        A       a;
        A::ftype f = a.get();

        (a.*f)(5);

        return 0;

}

// Thank you.

// --

// kira

It is not the behaviour what is undefined here but the function foo as
the compiler indicates. g++ gives the following message:

... In function `A::get() const':
: undefined reference to `A::foo(int)'

As soon as you define your function foo, it will compile and run.

In this code fragment, you just try to demonstrate how one can misuse
an object-oriented language concept, don't you?

Best Regards,
Szabolcs
 
K

kasthurirangan.balaji

It is not the behaviour what is undefined here but the function foo as
the compiler indicates. g++ gives the following message:

... In function `A::get() const':
: undefined reference to `A::foo(int)'

As soon as you define your function foo, it will compile and run.
function foo is already defined in the private section(and the post is
about breaking it using function pointer).
In this code fragment, you just try to demonstrate how one can misuse
an object-oriented language concept, don't you?

Best Regards,
Szabolcs


Unfortunately, the same code compiles under g++ 3.4.4(my version of g+
+ on my toshiba tecra 9000 laptop with FreeBSD 6.1). I would say the
code is correct syntatically but not semantically. As pointed out
earlier, we are trying to break the languages rules or using the dark
corners of the language. If interested, google for writing oo code
using 'c'.

Hope someone posts what the standard says. Anyhow, hats off to you.

Thanks,
Balaji.
 
S

Szabolcs Ferenczi

function foo is already defined in the private section(and the post is
about breaking it using function pointer).

Well, it is defined but not implemented.
Unfortunately, the same code compiles under g++ 3.4.4(my version of g+
+ on my toshiba tecra 9000 laptop with FreeBSD 6.1). I would say the
code is correct syntatically but not semantically. As pointed out

What you get is actually an error from the linker. If you just compile
it with the -c flag, it compiles. But the linker does not find the
code body and hence the error.

Best Regards,
Szabolcs
 
P

peter koch

// Is the following code well-defined?

class A
{
private:
        int foo(int n);

public:
        typedef int (A::*ftype)(int);

        ftype get() const { return &A::foo; }

};

int main()
{
        A       a;
        A::ftype f = a.get();

        (a.*f)(5);

        return 0;

}
Of course it is. Also, there's no violation of access scope as the
title seems to imply.

/Peter
 
J

jason.cipriani

// Is the following code well-defined?
[snip]

Of course it is. Also, there's no violation of access scope as the
title seems to imply.

Yes; it is similar in spirit to doing something like this:

class A {
public:
int & value (void) { return _value; }
private:
int _value;
};

Where, by returning a reference to a private member through a public
function, you let a caller modify the "private" member. Having things
be "private" or "protected" doesn't really put any code or data in a
magical protected area of memory or something; you can still access
them from anywhere. "Private" and "protected" exist to help a
programmer enforce access rules at compile time, and also to add some
convenient rules to how derived classes inherit access to member
variables (in the case of "private" vs. "protected"). You can still
access the data from anywhere though.

Think of it like... you have an XBox 360 in your living room. It's
declared as "private", so people can't just walk in and play it
whenever they feel like it. However you can send out a public
invitation to your friends, and give them full access to your private
XBox. Not a problem. This is similar to providing public function
pointers to private functions or public access to private members. Of
course somebody could just break into your house and start playing
your video games -- that's more equivalent to accessing private data
by accessing the instance's block of memory directly instead of by
named members.

Jason
 
A

Andrey Tarasevich

Kira said:
> ...
A::ftype f = a.get();
(a.*f)(5);
...

Access control in C++ is purely compile-time concept. What you are doing
here does not "violate access scope" in any way and, therefore, does
not trigger any kind of "undefined behavior".
 
K

Kira Yamato

// Is the following code well-defined?
[snip]

Of course it is. Also, there's no violation of access scope as the
title seems to imply.

Yes; it is similar in spirit to doing something like this:

class A {
public:
int & value (void) { return _value; }
private:
int _value;
};

Where, by returning a reference to a private member through a public
function, you let a caller modify the "private" member. Having things
be "private" or "protected" doesn't really put any code or data in a
magical protected area of memory or something; you can still access
them from anywhere. "Private" and "protected" exist to help a
programmer enforce access rules at compile time, and also to add some
convenient rules to how derived classes inherit access to member
variables (in the case of "private" vs. "protected"). You can still
access the data from anywhere though.

Think of it like... you have an XBox 360 in your living room. It's
declared as "private", so people can't just walk in and play it
whenever they feel like it. However you can send out a public
invitation to your friends, and give them full access to your private
XBox. Not a problem. This is similar to providing public function
pointers to private functions or public access to private members. Of
course somebody could just break into your house and start playing
your video games -- that's more equivalent to accessing private data
by accessing the instance's block of memory directly instead of by
named members.

Jason

Thanks everyone. I just wanted to make sure I'm not doing anything
whose results could be compiler-dependent.
 
J

James Kanze

Kira Yamato wrote:
Access control in C++ is purely compile-time concept. What you
are doing here does not "violate access scope" in any way and,
therefore, does not trigger any kind of "undefined behavior".

Also, access control really only concerns names, and not objects
or types. If you write something like:

class C
{
class Nested { ... } ;
public:
typedef Nested N ;
// ...
} ;

client code can use N, but not Nested, even though they both
mean exactly the same thing. And any access to a member of
Nested (e.g. through an object declared with type C::N) depends
on the access controls active in Nested.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top