 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
