|
It's a header file for a POSIX thread library. Where is your code from? POSIX threads have been implemented on Unix, Linux and Windows. Try to figure out what POSIX library yous code was using.
Best,
Jun
|
|
|
|
|
The following doesn't compile:
struct A
{
A* partner;
void doodah()
{ ++partner->value; } //this is legal
protected:
int value;
};
struct B: public A
{
void foobar()
{ partner->value += 2; } //but this isn’t
};
The complaint is that foobar() can't access A::value. But B is an A and A can access the value member of another A. So why can't B - which IS AN A - access the value member of another A?
--Dave Schumann
|
|
|
|
|
i really don't see anything wrong in the code (except the doodah() method is a little dirty, but anyway).
what does the compiler say exactly (code + message) ?
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
FILENAME.cpp(230) : error C2248: 'A::value' : cannot access protected member declared in class 'A'
FILENAME.cpp(224) : see declaration of 'A::value'
FILENAME.cpp(218) : see declaration of 'A'
line 230 is the "partner->value += 2" call in foobar(). It has no complaint about the "++partner->value" call in doodah().
I'm not a language lawyer but this seems like it should be legal.
|
|
|
|
|
It may be that you are trying to implement class like behaviour using structs.
Try this:
struct A
{
// Let the compiler know that B can access A's protected members.
friend struct B;
A* partner;
void doodah()
{ ++partner->value; } //this is legal
protected:
int value;
};
Dave Kerr
codechamber@hotmail.com
http://www.codechamber.com
|
|
|
|
|
But a class *is* a struct.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
