POV-Ray : Newsgroups : povray.programming : C++ inheritance puzzler Server Time: 19 Aug 2019 14:03:41 GMT
  C++ inheritance puzzler (Message 1 to 10 of 13)  
Goto Latest 10 Messages Next 3 Messages >>>
From: clipka
Subject: C++ inheritance puzzler
Date: 27 Nov 2010 14:01:15
Message: <4cf10f2b$1@news.povray.org>
Hacking happily along at the POV-Ray code, I stumbled across this MS 
Visual Studio 2005 C++ anomaly:

   class A
   {
       protected:
           void a() {}
   };

   class B : public A
   {
       protected:
           void b(A* other)
           {
               this->a();  // (1)
               other->a(); // (2)
           }
   };

While (1) compiles fine, (2) raises an error C2248, "'A::a' : cannot 
access protected member declared in class 'A'"

What the F*** am I doing wrong here?


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: C++ inheritance puzzler
Date: 27 Nov 2010 14:03:54
Message: <4cf10fca$1@news.povray.org>
On 27.11.10 15:00, clipka wrote:
> Hacking happily along at the POV-Ray code, I stumbled across this MS Visual
> Studio 2005 C++ anomaly:
>
> class A
> {
> protected:
> void a() {}
> };
>
> class B : public A
> {
> protected:
> void b(A* other)
> {
> this->a(); // (1)
> other->a(); // (2)
> }
> };
>
> While (1) compiles fine, (2) raises an error C2248, "'A::a' : cannot access
> protected member declared in class 'A'"
>
> What the F*** am I doing wrong here?

SP1 installed?


Post a reply to this message

From: clipka
Subject: Re: C++ inheritance puzzler
Date: 27 Nov 2010 14:12:10
Message: <4cf111ba$1@news.povray.org>
Am 27.11.2010 15:03, schrieb Thorsten Froehlich:
>> What the F*** am I doing wrong here?
>
> SP1 installed?

Not sure; here's what the "about" window says:

Microsoft Visual Studio 2005
Version 8.0.50727.762  (SP.050727-7600)
Microsoft .NET Framework
Version 2.0.50727 SP2

Installed Edition: Standard

Microsoft Visual Basic 2005   77633-235-7976321-41904
Microsoft Visual Basic 2005

Microsoft Visual C# 2005   77633-235-7976321-41904
Microsoft Visual C# 2005

Microsoft Visual C++ 2005   77633-235-7976321-41904
Microsoft Visual C++ 2005

Microsoft Visual J# 2005   77633-235-7976321-41904
Microsoft Visual J# 2005

Microsoft Visual Web Developer 2005   77633-235-7976321-41904
Microsoft Visual Web Developer 2005

Microsoft Web Application Projects 2005   77633-235-7976321-41904
Microsoft Web Application Projects 2005
Version 8.0.50727.762

Microsoft Visual Studio 2005 Standard Edition - ENU Service Pack 1 
(KB926601)
This service pack is for Microsoft Visual Studio 2005 Standard Edition - 
ENU.
If you later install a more recent service pack, this service pack will 
be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/926601

Security Update for Microsoft Visual Studio 2005 Standard Edition - ENU 
(KB971090)
This Security Update is for Microsoft Visual Studio 2005 Standard 
Edition - ENU.
If you later install a more recent service pack, this Security Update 
will be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/971090

Security Update for Microsoft Visual Studio 2005 Standard Edition - ENU 
(KB973673)
This Security Update is for Microsoft Visual Studio 2005 Standard 
Edition - ENU.
If you later install a more recent service pack, this Security Update 
will be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/973673

VisualHG   1.0.8
Mercurial based source contol provider.


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: C++ inheritance puzzler
Date: 27 Nov 2010 14:40:47
Message: <4cf1186f@news.povray.org>
On 27.11.10 15:11, clipka wrote:
> Am 27.11.2010 15:03, schrieb Thorsten Froehlich:
>>> What the F*** am I doing wrong here?
>>
>> SP1 installed?
>
> Not sure; here's what the "about" window says:
 >
> Microsoft Visual Studio 2005 Standard Edition - ENU Service Pack 1 (KB926601)
> This service pack is for Microsoft Visual Studio 2005 Standard Edition - ENU.

Seems installed. Note that apparently there are several bugs related to 
C2248 that were not fixed in VC 2005.

	Thorsten


Post a reply to this message

From: Warp
Subject: Re: C++ inheritance puzzler
Date: 27 Nov 2010 14:45:23
Message: <4cf11983@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Hacking happily along at the POV-Ray code, I stumbled across this MS 
> Visual Studio 2005 C++ anomaly:

  AFAIK it's not an anomaly in VS, but a quirk in the C++ standard.

-- 
                                                          - Warp


Post a reply to this message

From: Le Forgeron
Subject: Re: C++ inheritance puzzler
Date: 27 Nov 2010 20:01:20
Message: <4cf16390@news.povray.org>
Le 27/11/2010 15:00, clipka nous fit lire :
> Hacking happily along at the POV-Ray code, I stumbled across this MS
> Visual Studio 2005 C++ anomaly:
> 
>   class A
>   {
>       protected:
>           void a() {}
>   };
> 
>   class B : public A
>   {
>       protected:
>           void b(A* other)
>           {
>               this->a();  // (1)
>               other->a(); // (2)
>           }
>   };
> 
> While (1) compiles fine, (2) raises an error C2248, "'A::a' : cannot
> access protected member declared in class 'A'"
> 
> What the F*** am I doing wrong here?

Issue of C++, or on the chair ?

(1) is ok because B is an A, so can access the protected function.
(2) is not allowed because a() of A is protected, so can only be called
by the object itself (in a gross simplification).

Works as designed.


Post a reply to this message

From: Warp
Subject: Re: C++ inheritance puzzler
Date: 27 Nov 2010 20:27:00
Message: <4cf16993@news.povray.org>
Le_Forgeron <jgr### [at] freefr> wrote:
> (2) is not allowed because a() of A is protected, so can only be called
> by the object itself (in a gross simplification).

  Actually that's not completely true. This is completely ok:

class A
{
 protected:
    void protectedFunctionOfA() {}
};

class B : public A
{
 public:
    void foo(B* other)
    {
        other->protectedFunctionOfA(); // ok
    }
};

  'protectedFunctionOfA()' is not being called by the object itself, yet
it's ok. However, the difference is that 'other' is of type B, in which
case it's allowed. However, if it was of type A, it would not be allowed:

    void foo(A* other)
    {
        other->protectedFunctionOfA(); // not ok
    }

  Basically, B is allowed to call the function only if the object is
(known to be) of type B, but not if it's only known to be of type A
(by static typing, ie. even if the object behind the pointer is in
reality of type B).

  Even if you did this, you would still get an error:

void B::foo()
{
    A* ptr = this;
    ptr->protectedFunctionOfA(); // not ok
}

  (The compiler *could* deduce in this case that 'ptr' is really pointing
to an object of type B, but there are only so many cases where it could
prove it for certain, and this could change from compiler to compiler.)

  Needless to say, gcc (and probably most other C++ compilers) will give
an error for that, so it just cannot be done. If you need to call the
protected section of the object, take a pointer of the derived type,
because that's what it has to be.

-- 
                                                          - Warp


Post a reply to this message

From: Le Forgeron
Subject: Re: C++ inheritance puzzler
Date: 28 Nov 2010 09:57:09
Message: <4cf22775$1@news.povray.org>
Le 27/11/2010 21:27, Warp nous fit lire :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> (2) is not allowed because a() of A is protected, so can only be called
>> by the object itself (in a gross simplification).

I did write "in a gross simplification", didn't I ?

>   Needless to say, gcc (and probably most other C++ compilers) will give
> an error for that, so it just cannot be done. If you need to call the
> protected section of the object, take a pointer of the derived type,
> because that's what it has to be.
> 

Or "just" make B a friend of A. Or in fact, only the needed function of
B can be a friend of A.

Now, I would question the design any way for such function b
(as it is bypassing the objects' boundaries), but sometimes it's simpler
than redesign everything.

  class B;

  class A
  {
      protected:
          void a() {}
      friend void B::b(); // more restricted than "friend B;"
  };

  class B : public A
  {
      protected:
          void b(A* other)
          {
              this->a();  // (1)
              other->a(); // (2)
          }
  };


Post a reply to this message

From: clipka
Subject: Re: C++ inheritance puzzler
Date: 28 Nov 2010 17:29:17
Message: <4cf2916d$1@news.povray.org>
Am 27.11.2010 21:01, schrieb Le_Forgeron:
> (1) is ok because B is an A, so can access the protected function.
> (2) is not allowed because a() of A is protected, so can only be called
> by the object itself (in a gross simplification).
>
> Works as designed.

Is that so?

Why should (2) be prohibited when (1) is not? After all, the practical 
use of protected members is to hide implementation details from "alien" 
code; but the code in (2) is not alien - it must rely on that 
implementation detail called "a()" even if it just calls it on itself, 
so why prevent it from calling it on some other object of type A?

I can see how this /could/ be intended, but I'm not so sure whether it 
/is/ intended. At least it is unexpected for me, and makes life more 
cumbersome than necessary.


Post a reply to this message

From: Le Forgeron
Subject: Re: C++ inheritance puzzler
Date: 28 Nov 2010 18:27:39
Message: <4cf29f1b$1@news.povray.org>
Le 28/11/2010 18:28, clipka nous fit lire :
> Am 27.11.2010 21:01, schrieb Le_Forgeron:
>> (1) is ok because B is an A, so can access the protected function.
>> (2) is not allowed because a() of A is protected, so can only be called
>> by the object itself (in a gross simplification).
>>
>> Works as designed.
> 
> Is that so?
> 
> Why should (2) be prohibited when (1) is not? After all, the practical
> use of protected members is to hide implementation details from "alien"
> code; but the code in (2) is not alien - it must rely on that
> implementation detail called "a()" even if it just calls it on itself,
> so why prevent it from calling it on some other object of type A?
> 
> I can see how this /could/ be intended, but I'm not so sure whether it
> /is/ intended. At least it is unexpected for me, and makes life more
> cumbersome than necessary.

You should thinks "object oriented" as "public is what is available to
everyone, private is for myself only. Protected is a mixed path to allow
inheriting classes & friends to also have access to it.".

Whenever an instance X of an object has a reference to an instance Y
does not allow the methods of X to access the protected & private area
of Y, even if X & Y are from the same class.

Illustration with gun (protected method) & policeman (class):

Policeman X can use its gun (gun is protected, so other normal people do
not have access to it!)
Policeman X has to drive policeman Y (so X know about Y).
Nevertheless, Policeman X is not allowed to use the gun of Y directly.

X & Y are both Policemen, but each one keep his/her/its gun protected.

Or do you think the policeman from L.A. should be free to use the gun of
the policeman of N.Y. ? (free as: whenever, wherever, without even the
shadow of a control ?)


Post a reply to this message

Goto Latest 10 Messages Next 3 Messages >>>

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.