views:

80

answers:

2
struct A {
protected:
  int y;
public:
  int z;
};

struct F : A {
public:
  using A::y;
private:
  using A::z;
};

int main() {
  F obj_F;
  obj_F.y = 9;
  obj_F.z = 10;
}

Source: http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=/com.ibm.vacpp7a.doc/language/ref/clrc14cplr135.htm

In the above code obj_F.z = 10; - is allowed. Explanation: The access of member z is still public. The private using declaration using A::z has no effect on the access of z.

Can someone tell me, if z, which is declared as private, is accessible outside, then what is the meaning of that private? What does it do?

Thanks

-Saiyasodharan

A: 

F inherits A privately. So you cannot access any of A's public members if you use an F outside F's definition. Because F defines no members, F is basically useless.

If F inherits A publicly (ie :)

struct F : public A {};

Then you can now use A's public member. so you can write obj_F.z

If you have a variable z that is public in a and private in F, ie :

struct A { public: int z; };
struct F : public A { private: int z; };

then the two z are actually two different variables. That's not what you want.

also, like Andre Holzner said, your using statement are useless here.

Generally, you cannot in any object programming language, restrict the scope of a member in a public-inherited subclass. Either the class definition won't compile, won't obey, or will create another member with the same name. This because your F is not compatible with code that deals with a A or a subclass of it.

BatchyX
`F inherits A privately`. -1 for this. `F` and `A` are structures(not classes).
Prasoon Saurav
+3  A: 

The code is valid according to the Standard - see this Standard rule, which I did not have in mind when I answered before

A member m is accessible when named in class N if

  • [...], or
  • there exists a base class B of N that is accessible at the point of reference, and m is accessible when named in class B.

This entirely applies to your code, and thus the access is valid... It appears the main purpose of this rule is for allowing friend declarations of the base to apply to inherited members, but it also applies to this case.


(Disregard the parts of this that say the code is invalid - It's valid as explained above. This part is an old version of my answer, kept here to serve as background information)

No, this code is invalid. That's why the equivalent "access-declarations" are called that way (these are deprecated though)

struct F : A {
public:
  A::y;
private:
  A::z;
};

These are called "access-declarations" precisely because they can change the access... In your example the naming class is F and z as a member of F is private because the using-declaration did change the access level of the name z.

Johannes Schaub - litb
my doubt cleard.. thx :-)
saiy2k
I don't know why Charles deleted his answer (although the first and last paragraph of his answer were correct).`The code is valid according to the Standard`. What makes the code valid? It is still ill-formed. Is that different from the code's validity?
Prasoon Saurav
@Prasoon the code is valid - see the text I quoted from the Standard. I just tested various compilers to see how they conform to that weirdness, and for me only comeau accepts it. I sent a PR to clang: http://llvm.org/bugs/show_bug.cgi?id=8178 . @Charles also made a good point about circumventing it by saying `obj_F.A::z`.
Johannes Schaub - litb
@Johannes : I saw the text quoted, made perfect sense. Does that mean this is a bug in compilers like gcc/clang/MSVC++ ?
Prasoon Saurav
@Prasoon well that depends on what we consider a bug. If we would implement everything strictly by the Standards letter, we can't set up a working/useful compiler because the Standard is [too defective](http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html). If we say they have a bug if they are against the intention of the committee (which is what is actually done), we will first have to wait for statements of the committee about it :)
Johannes Schaub - litb
Yeah, thanks for reporting that bug. Actually from your post `The code is valid according to the Standard` and `No, this code is invalid` said two different things.
Prasoon Saurav
@Prasoon thanks, I made it clearer now :)
Johannes Schaub - litb
Oh, +1 for the answer BTW :)
Prasoon Saurav
@Prasoon: I deleted my answer because it was wrong, it's as simple as that. Even if I had wanted to fix it, by that stage litb's answer was better so there wasn't really any point.
Charles Bailey
@Charles : Yes, I understood that after reading the text quoted from the Standard. But as per my opinion you should have focussed on correcting the answer instead of deleting it. Anyways, no problems. :-)
Prasoon Saurav