|
Christian Graus wrote: But a class *is* a struct.
hum, yes, but i would have said here that a struct *is* a class 
only a matter of point of view 
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
Internally yes a class is a struct with a vftbl.
Regardless, this does solve the problem. Changing the structs to classes does not, neither does explicitly declaring partner as public.
More explicit casting :
void foobar()
{ ((::A*)this)->partner->value += 2; }
or
void foobar()
{ ((A*)this)->partner->value += 2; }
as mentioned in the notes for Compiler Error C2248 on MSDN doesn't work either. It's rather an odd one.
Dave Kerr
codechamber@hotmail.com
http://www.codechamber.com
|
|
|
|
|
Oh - casting this to an A*. That seems like a really good idea. Pity it doesn't work but it would have made sense if it did  .
Yeah I'm confused too. I hope a language lawyer blunders onto this post...I'm wondering whether this is a standards violation or not.
|
|
|
|
|
A "struct" is a class with default public protection. You can change it to a class, put a "public:" at the beginning, and have the same result.
And although in this toy example I could get it to compile with a "friend struct B" declaration, that's stupid. B is a CHILD CLASS. Why should I have to declare it a friend? Why should I even have to know about it? My child classes are supposed to be able to access my protected members.
|
|
|
|
|
my first thought was that A* partner; in A is in the private section of the class, so it is not accessible to B, but you're dealing with struct, and all members in structs should be public; so I'm a little bit confused.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Dave Schumann wrote: So why can't B - which IS AN A - access the value member of another A?
It's a difference in the way structs differ from classes. If you remove A::value from the protected section, it'll compile.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Maximilien wrote: all members in structs should be public
no. this is true only is you don't redefine the visibility (which is actually done here with protected: )
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
>>>It's a difference in the way structs differ from classes
No it's not. Changing these to "classes" with public: at the beginning has no effect (I've tried it)
|
|
|
|
|
Dave Schumann wrote: No it's not.
Sure it is.
Dave Schumann wrote: Changing these to "classes" with public: at the beginning has no effect (I've tried it)
It won't have an effect until you put A::value into a public section. This is the default with a struct. So, you'll either need:
struct A
{
A* partner;
void doodah()
{ ++partner->value; }
int value;
};or
class A
{
public:
A* partner;
void doodah()
{ ++partner->value; }
int value;
};
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
>>>Sure it is.
No - it's not. You said it has something to do with struct vs. class - it doesn't. Change them to clases with public scope at the beginning and everything will be the same. What you did was remove the "protected:" which has nothing to do with it being a struct or not.
I declared "protected:" for a reason, not because I like having things not compile. This is a toy version of a much larger problem. I can't stand posters who post 20 pages of code so I figured I'd boil the issue down. In fact in my case the issue is accessing a *function*...and there's virtual stuff and blah blah blah. Now you're getting bored, appropriately. None of that is relevant to the compiler error which I can't understand.
|
|
|
|
|
Dave Schumann wrote: I declared "protected:" for a reason, not because I like having things not compile. This is a toy version of a much larger problem. I can't stand posters who post 20 pages of code so I figured I'd boil the issue down. In fact in my case the issue is accessing a *function*...and there's virtual stuff and blah blah blah. Now you're getting bored, appropriately. None of that is relevant to the compiler error which I can't understand.
Since you aren't giving the details of your larger problem (understandably), I will only mention that almost always, protected should be replaced by private. See Effective C++ by Scott Meyers for details.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: I will only mention that almost always, protected should be replaced by private.
maybe, but here, the protected member is accessed by a children... so, putting it private will cause a new problem in his code.
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
toxcct wrote: maybe, but here, the protected member is accessed by a children... so, putting it private will cause a new problem in his code.
That hits to the design issue I was referring to.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
So would it be permissible to just add a "getter" method to A?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Yes, me too. It's not complaining about accessing "partner" - it's complaining about accessing "partner::value" even though B is a child of A and "value" is a protected member.
This is a toy version of a real problem I'm having (I trusted that the "A", "B", "foobar", and "doodah" names would make that relatively obvious  ). My real problem involves much larger *classes* (not structs...again this is a toy problem) and the real-life version of "A" is not easy to modify. I was honestly shocked I was able to write this toy version that doesn't compile (it really doesn't - just cut'n'paste and see for yourself). I assumed that the problem was some complicated thing about my larger classes and their relationships or whatever...but no, it's really not letting me do this.
|
|
|
|
|
Dave Schumann wrote: It's not complaining about accessing "partner"
And it won't. partner has public access. If it complained about that, I would be really shocked.
This link may help you as well: C++ Protection
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Yeah - I found the relevant portion of the standard. It actually specifies an EXTRA CHECK for cases like this. Why?? See "solution" below for section and quote.
|
|
|
|
|
I believe the reason why is that you could completely circumvent protection by using inheritence if they did not do this check.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
well you can basically "completely circumvent" protection anyway. For example:
LIBRARY:
class A
{
protected:
int value;
};
MY CODE:
//now let's say I want to access value in an 'A' object I have. I just write this:
class A_breaker: public A
{
public:
int* accessValue()
{ return &value; }
};
void my_function (A& my_a)
{
int* value_ptr = ((A_breaker&)my_a).accessValue();
//now I can do anything
}
...so if they were trying to make "protected" bulletproof, they didn't succeed at all. (I've actually compiled the above and it's perfectly legal...and, incidentally, the cast to A_breaker is perfectly safe since A_breaker adds no data)
-- modified at 13:01 Wednesday 12th July, 2006
|
|
|
|
|
I doubt they were trying to make it bulletproof. Chances are they were trying to provide as strict a mechanism for it as possible while still allowing for old C-Style code to compile.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Easy and more correct fix:
class A
{
public:
A* partner;
void doodah() { ++partner->value; }
int getValue() const { return value; }
void setValue(int newValue) { value = newValue; }
protected:
int value;
};
class B: public A
{
public:
void foobar() { partner->setValue(partner->getValue() + 2); }
};
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
You've provided public accessors to "value". If I wanted value to be accessible publicly, I'd just make it public.
I'm not putting "protected" in just to make life hard. I actually don't want any outside classes modifying "value". If you make "setValue" protected above - which is the whole point - then you've violated the restrictions I want on "value".
|
|
|
|
|
Dave Schumann wrote: You've provided public accessors to "value". If I wanted value to be accessible publicly, I'd just make it public.
Which would be even worse.
Dave Schumann wrote: I'm not putting "protected" in just to make life hard. I actually don't want any outside classes modifying "value". If you make "setValue" protected above - which is the whole point - then you've violated the restrictions I want on "value".
While I'll let you read Meyer's argument for not using protected for yourself, I will point out another glaring point:
Why do you have a pointer to A as a member of class A? From experience, every single time I've seen that type of code, it has been due to poor design. What is it that your larger problem is trying to accomplish?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Why do you have a pointer to A as a member of class A? From experience, every single time I've seen that type of code, it has been due to poor design
Really? Do you really mean that? I'll let you re-read it for a second...
...
would this just be too obvious?
class Node
{
Node* next;
void* data;
};
i.e., the basic definition of a linked list?
|
|
|
|
|
Sorry, there was suppose to be an "almost" before the "every single".
Reinventing something that already exists (linked lists) is rarely ever necessary.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
