Base class protected constructor and Derived class member
Srinivas Vobilisetti
Moderator, I put this question in this newgroup before but got no good
response. So, I rephrased the question and am posting it again.
Frist Argument:
In the book 'Advanced C++ Programming Idioms and Styles - James Coplien'
under section 5.4 'Pure virtual functions and Abstract base classes', he
compares between Abstract base classes and classes with protected
constructors. He says abstract base classes declare that their class can
not be instantiated or used as a formal parameter type or function
return type. The hidden constructor had these properties, too, with the
loophole that a base class object could be created from within a derived
class member function.
Second Argument:
The C++ Draft Standard, December 1996, topic protected member access
(from derived class to base class) [11.5] says, except when forming a
pointer to member, the access must be through a pointer to, reference
to, or object of the derived class itself or any class derived from that
class.
My Question:
The first argument says, we can access protected constructor of a base
class for creating a base class object from a derived class member
function. Which I interpret, accessing protected constructor of the base
class through a base class object from a derived class member function.
The second argument says, protected member access must be through a
pointer to, reference to, or object of the derived class itself or any
class derived from that class.
I could not understand how both the (contradicting?) arguments hold?
Also, my DEC compiler allows creating a base class object in a derived
class member function when the base constructor is protected. But it did
not allow accessing the protected member of base class through the base
class object I created from the same derived class member function.
Srinivas
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Patrick Doyle
In article <5q9e4s$e...@netlab.cs.rpi.edu>,
Srinivas Vobilisetti <Srinivas.V...@mci.com> wrote:
>
>My Question:
>
>The first argument says, we can access protected constructor of a base
>class for creating a base class object from a derived class member
>function. Which I interpret, accessing protected constructor of the base
>class through a base class object from a derived class member function.
>
>The second argument says, protected member access must be through a
>pointer to, reference to, or object of the derived class itself or any
>class derived from that class.
>
>I could not understand how both the (contradicting?) arguments hold?
Because constructors are different. You don't need a pointer to
an instance of that class to call its constructor. If you did, then
how would you ever construct anything new?
>Also, my DEC compiler allows creating a base class object in a derived
>class member function when the base constructor is protected. But it did
>not allow accessing the protected member of base class through the base
>class object I created from the same derived class member function.
This is standard behaviour. You can't access protected members of any
other class unless they have been inherited by your class. So:
void Derived::Function(Base &Base1){
//This is ok--protected member which has been inherited:
ProtectedFunction();
//This is illegal--protected member of a different class:
Base1.ProtectedFunction();
}
-PD
--
--
Patrick Doyle
doy...@ecf.utoronto.ca
Tom Platts-Mills
Srinivas Vobilisetti <Srinivas.V...@mci.com> wrote:
>Moderator, I put this question in this newgroup before but got no good
>response. So, I rephrased the question and am posting it again.
>
>Frist Argument:
>In the book 'Advanced C++ Programming Idioms and Styles - James Coplien'
>under section 5.4 'Pure virtual functions and Abstract base classes', he
>compares between Abstract base classes and classes with protected
>constructors. He says abstract base classes declare that their class can
>not be instantiated or used as a formal parameter type or function
>return type. The hidden constructor had these properties, too, with the
>loophole that a base class object could be created from within a derived
>class member function.
>
>Second Argument:
>The C++ Draft Standard, December 1996, topic protected member access
>(from derived class to base class) [11.5] says, except when forming a
>pointer to member, the access must be through a pointer to, reference
>to, or object of the derived class itself or any class derived from that
>class.
>
>My Question:
>
>The first argument says, we can access protected constructor of a base
>class for creating a base class object from a derived class member
>function. Which I interpret, accessing protected constructor of the base
>class through a base class object from a derived class member function.
>
No, protected members are inherited by the derived class/object and so
can be accessed through a pointer to derived.
>The second argument says, protected member access must be through a
>pointer to, reference to, or object of the derived class itself or any
>class derived from that class.
>
So there is no contradiction - you're accessing the protected members
of the base class, but through a pointer to derived (the 'this'
pointer).
>I could not understand how both the (contradicting?) arguments hold?
>
>Also, my DEC compiler allows creating a base class object in a derived
>class member function when the base constructor is protected. But it did
>not allow accessing the protected member of base class through the base
>class object I created from the same derived class member function.
>
In the first case you're implicitly using the 'this' pointer, which is
a pointer to derived. In the second case you're using a pointer to
base, which doesn't allow you access to the base protected members.
Tom Platts-Mills
--
10065...@compuserve.com
David Vandevoorde
Patrick Doyle wrote:
[ ... on the interpretation of [class.protected] with
constructors ]
> Because constructors are different. You don't need a pointer to
> an instance of that class to call its constructor. If you did, then
> how would you ever construct anything new?
That doesn't affect the wording of [class.protected]: a base
constructor is an non-static member, and therefore you cannot
access it from the derived class if it was declared protected
(because there is no syntax to conform to requirements of
the paragraph under discussion). In fact, I'm not sure what
is possible with a protected constructor that is not possible
with a private constructor.
Daveed
(C) Chichiang Wan
Srinivas Vobilisetti wrote:
>
> Moderator, I put this question in this newgroup before but got no good
> response. So, I rephrased the question and am posting it again.
>
> Frist Argument:
> In the book 'Advanced C++ Programming Idioms and Styles - James Coplien'
> under section 5.4 'Pure virtual functions and Abstract base classes', he
> compares between Abstract base classes and classes with protected
> constructors. He says abstract base classes declare that their class can
> not be instantiated or used as a formal parameter type or function
> return type. The hidden constructor had these properties, too, with the
> loophole that a base class object could be created from within a derived
> class member function.
>
The last sentence may be questionable. Besides 11.5 of CD2, there is
another example in
Chap 12 of CD2, para. 2:
[Example: declaring a constructor protected ensures that only derived
classes and friends can create objects using it. ]
Note the word "only in above example. You can not relax classes to
class member function, or friends (of base) to friends of derived class.
class Base {
protected:
Base() {}
void bar() {}
friend void f_b();
};
void f_b () {
Base b; //ok
b.bar(); //ok
}
class Derived : public Base {
public:
Derived();
int getValue();
friend void f_d ();
};
Derived::Derived () {
Base b; //Error
}
int Derived::getValue() {
Base b; //Error
bar(); //ok
}
void f_d () {
Base b; //Error
bar(); //Error
}
> Second Argument:
> The C++ Draft Standard, December 1996, topic protected member access
> (from derived class to base class) [11.5] says, except when forming a
> pointer to member, the access must be through a pointer to, reference
> to, or object of the derived class itself or any class derived from that
> class.
>
> My Question:
>
> The first argument says, we can access protected constructor of a base
> class for creating a base class object from a derived class member
> function. Which I interpret, accessing protected constructor of the base
> class through a base class object from a derived class member function.
>
Incorrect deduction/interpretation, even for ordinary protected member
function
void Derived::m_d() {
Base ob; //assume you could do this as if Base has public default
constructor
bar(); //ok, according to 11.5, since it is equivilent to this->bar();
ob.bar(); //still not ok, according to 11.5
//Base b; conceptually as this::Base() ???
}
> The second argument says, protected member access must be through a
> pointer to, reference to, or object of the derived class itself or any
> class derived from that class.
>
Constructors do not have names. Normal access rules are for names. But
you could conceptually think constructor as a static member function,
that might give you another interpretation of 11.5. See above example.
> I could not understand how both the (contradicting?) arguments hold?
>
> Also, my DEC compiler allows creating a base class object in a derived
> class member function when the base constructor is protected.
Sounds like a bug.
-- Chichiang
--
**********************************************************************
Name: Chichiang Wan
email: wa...@cup.hp.com
Phone: (408) 447-5762
**********************************************************************
Bradd W. Szonye
(C) Chichiang Wan <wa...@hpclear6.cup.hp.com> wrote in article
<5qgn81$4...@netlab.cs.rpi.edu>...
> Srinivas Vobilisetti wrote:
> >
> > The [protected] constructor had these properties, too, with the
> > loophole that a base class object could be created from within a
derived
> > class member function.
>
> The last sentence may be questionable. Besides 11.5 of CD2, there is
> [Example: declaring a constructor protected ensures that only derived
> classes and friends can create objects using it. ]
> Note the word "only in above example. You can not relax classes to
> class member function, or friends (of base) to friends of derived class.
Are you sure? Clause 15, para. 1:
1 A member of a class can be
--protected; that is, its name can be used only by member functions,
static data members, and friends of the class in which it is
declared and by member functions, static data members, and friends
of classes derived from this class (see _class.protected_).
This first mention sounds like both derived-class member functions and
derived-class friends can use base-class protected constructors. Let's see
what [class.protected] has to say...
11.5 Protected member access [class.protected]
1 When a friend or a member function of a derived class references a
protected nonstatic member of a base class, an access check applies in
addition to those described earlier in this clause.4)
4) This additional check does not apply to other members, e.g. static
data members or enumerator member constants.
... or constructors, since they are not ordinary nonstatic member
functions, and are "named" differently than other member functions. The
rationale behind 11.5 (access slicing) does not apply to constructors,
since no existing object exists to break encapsulation. Treating
constructors otherwise would be counterintuitive and break existing
implementations (like the DEC one you mention).
The Standard, however, is a thick document. Please correct me if I'm wrong,
but cite chapter and verse. It could be another case of Standardese that
isn't quite tight enough.
--
Bradd W. Szonye
bra...@concentric.net
http://www.concentric.net/~Bradds
Mu...@drn.zippo.com
In article <5qgndv$5...@netlab.cs.rpi.edu>, David says...
>
>Patrick Doyle wrote:
>[ ... on the interpretation of [class.protected] with
> constructors ]
>> Because constructors are different. You don't need a pointer to
>> an instance of that class to call its constructor. If you did, then
>> how would you ever construct anything new?
>
>That doesn't affect the wording of [class.protected]: a base
>constructor is an non-static member, and therefore you cannot
>access it from the derived class if it was declared protected
>(because there is no syntax to conform to requirements of
>the paragraph under discussion). In fact, I'm not sure what
>is possible with a protected constructor that is not possible
>with a private constructor.
>
> Daveed
True. You can still create objects of the class whose constructor is protected
if it provides a static member function which takes care of creation.
Mull.
(C) Chichiang Wan
Bradd W. Szonye wrote:
> ... or constructors, since they are not ordinary nonstatic member
> functions, and are "named" differently than other member functions. The
> rationale behind 11.5 (access slicing) does not apply to constructors,
> since no existing object exists to break encapsulation. Treating
> constructors otherwise would be counterintuitive and break existing
> implementations (like the DEC one you mention).
>
Normal access rules are for names. Standard (draft as CD2) 12.1 says
onstructors do not have names. Not '"named" differently'.
If you the DEC implementation has to keep, others implementations (EDG,
HP...) have to break, besides modify the standards.