«

// 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

On Feb 27, 2:10*pm, Kira Yamato <kira...@earthlink.net> wrote:
> // 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.

On Feb 27, 10:10*am, Kira Yamato <kira...@earthlink.net> wrote:
> // 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

On Feb 27, 8:22 am, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
> On Feb 27, 10:10 am, Kira Yamato <kira...@earthlink.net> wrote:
>
>
>
> > // 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.
>
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.

On Feb 27, 5:13*pm, kasthurirangan.bal...@gmail.com wrote:

> 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

On 27 Feb., 10:10, Kira Yamato <kira...@earthlink.net> wrote:
> // 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

On Feb 27, 12:38 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
> On 27 Feb., 10:10, Kira Yamato <kira...@earthlink.net> wrote:
>
> > // 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

Kira Yamato wrote:
> ...
> 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".

--
Best regards,
Andrey Tarasevich

On 2008-02-27 13:51:26 -0500, ""
<> said:

> On Feb 27, 12:38 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
>> On 27 Feb., 10:10, Kira Yamato <kira...@earthlink.net> wrote:
>>
>>> // 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.

--

// kira

On Feb 27, 10:21 pm, Andrey Tarasevich <andreytarasev...@hotmail.com>
wrote:
> Kira Yamato wrote:

> > ...

> > 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".

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.

--
James Kanze (GABI Software) email:
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