Topic: C++ complexity example (was: Widespread C++ Competency Gap?)
Author: kyma@netcom.com (Matt Young)
Date: Thu, 29 Dec 1994 04:39:42 GMT Raw View
Satish Thatte (satish@gandalf.mcs.clarkson.edu) wrote:
: After trying to teach a class of (mostly) sophomores C++ for
: several years, I admit to having mixed feelings. Most of my
: competent students grasp the basics of both C++ and object
: systems in one term, contrary to the claims of those who
: denounce the idea of teaching OOP using C++. On the other hand
: I do have to spend most of my time teaching C++ rather than
: teaching interesting OOP issues.
: I also have to say that at the end of the term, and indeed after
: using C++ in several other courses and in nontrivial projects of
: their own, few if any would be able to predict which lines in the
: function g() below will cause compiler errors:
: class A {
: protected:
: int s;
: void f(A*);
: };
: class B : private A {
: private:
: int i;
: friend void g();
: };
: class C : public B {};
: A *a = new A; C *c = new C;
: void g() {
: c->f(a); (1)
: int temp1 = c->i; (2)
: int temp2 = a->s; (3)
: }
I cannot see any reward in subjecting students to
the arbitrary jibberish at that above. Very little
theory seems involved, and at best it is something
which could be relegated to the trade schools.
Matt Young
: In lines (1) and (2), c is treated as a B pointer and then the
: friendship of g() is used. In other words, the fact that i is
: not inherited from B as a member of C does not matter because
: automatic conversion kicks in. OK, so you justify that by saying
: that i is *really* B::i.
: There is an error only in line (3) due to an obscure rule about
: protected members. However this rule does not apply to f because
: in this case f is accessed via a B object after conversion, even
: though it is *really* A::f, and since g() is a friend of B it is
: *allowed* to automatically transform B* to A*. Why stop the
: transformation from C* at B*?
: I don't see any consistency in all this. Hopefully, some C++ Guru
: can enlighten me!
: Satish
Author: maxtal@physics.su.OZ.AU (John Max Skaller)
Date: Fri, 30 Dec 1994 00:45:57 GMT Raw View
In article <kymaD1K2A6.4tn@netcom.com> kyma@netcom.com (Matt Young) writes:
>Satish Thatte (satish@gandalf.mcs.clarkson.edu) wrote:
>
>: I also have to say that at the end of the term, and indeed after
>: using C++ in several other courses and in nontrivial projects of
>: their own, few if any would be able to predict which lines in the
>: function g() below will cause compiler errors:
[Example deleted]
Why bother? Thats what compilers are for!
--
JOHN (MAX) SKALLER, INTERNET:maxtal@suphys.physics.su.oz.au
Maxtal Pty Ltd,
81A Glebe Point Rd, GLEBE Mem: SA IT/9/22,SC22/WG21
NSW 2037, AUSTRALIA Phone: 61-2-566-2189
Author: willett@iostream.demon.co.uk (Rob Willett)
Date: Mon, 2 Jan 1995 07:44:41 +0000 Raw View
In article <3da9rb$gq0@gateway.wiltel.com>
igor_chudov@wiltel.com "Igor Chudov" writes:
> Satish Thatte (satish@gandalf.mcs.clarkson.edu) wrote in comp.lang.c++:
> : After trying to teach a class of (mostly) sophomores C++ for
> : several years, I admit to having mixed feelings. Most of my
> : competent students grasp the basics of both C++ and object
> : systems in one term, contrary to the claims of those who
> : denounce the idea of teaching OOP using C++. On the other hand
> : I do have to spend most of my time teaching C++ rather than
> : teaching interesting OOP issues.
>
> : I also have to say that at the end of the term, and indeed after
> : using C++ in several other courses and in nontrivial projects of
> : their own, few if any would be able to predict which lines in the
> : function g() below will cause compiler errors:
>
> : class A {
> : protected:
> : int s;
> : void f(A*);
> : };
>
> : class B : private A {
> : private:
> : int i;
> : friend void g();
> : };
>
> : class C : public B {};
>
> : A *a = new A; C *c = new C;
>
> : void g() {
> : c->f(a); (1)
> : int temp1 = c->i; (2)
> : int temp2 = a->s; (3)
> : }
>
> : In lines (1) and (2), c is treated as a B pointer and then the
> : friendship of g() is used. In other words, the fact that i is
> : not inherited from B as a member of C does not matter because
> : automatic conversion kicks in. OK, so you justify that by saying
> : that i is *really* B::i.
>
> : There is an error only in line (3) due to an obscure rule about
> : protected members. However this rule does not apply to f because
> : in this case f is accessed via a B object after conversion, even
> : though it is *really* A::f, and since g() is a friend of B it is
> : *allowed* to automatically transform B* to A*. Why stop the
> : transformation from C* at B*?
>
> : I don't see any consistency in all this. Hopefully, some C++ Guru
> : can enlighten me!
>
> I am not a guru, but by definition a friend function can do everything that
> a member function can do. I see no inconsistency in this rule. Note that
> from the legal (C++ lawyer's) point of view, you access not a member of A,
> but a member of an ancestor of B which happens to be protected in class A.
>
> On the other hand, it seems to be very wise to watch out for friend
> functions and avoid them as much as possible.
>
> Happy Holidays,
> ----------------------------------------------------------------------------
> IMHO. Igor Chudov, Resource Solutions Intl office (918)588-2309
> Systems Engineer, for WilTel. home (918)585-5862
> E-mail: igor_chudov@wiltel.com
> http://m-net.arbornet.org/~ichudov
> 1819 South Jackson #32-P Tulsa OK 74107
>
> f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.
>
Actually, line 1 is in error also. It is true that c is treated as a B pointer
because C is derived from B. BUT friendship is NOT inherited, therefore A::f(A*)
is not acessable from c. :-)
--
========================
Rob Willett IOSTREAM Ltd
========================
Author: ichudov@wiltel.com (Igor Chudov)
Date: 21 Dec 1994 22:22:35 GMT Raw View
Satish Thatte (satish@gandalf.mcs.clarkson.edu) wrote in comp.lang.c++:
: After trying to teach a class of (mostly) sophomores C++ for
: several years, I admit to having mixed feelings. Most of my
: competent students grasp the basics of both C++ and object
: systems in one term, contrary to the claims of those who
: denounce the idea of teaching OOP using C++. On the other hand
: I do have to spend most of my time teaching C++ rather than
: teaching interesting OOP issues.
: I also have to say that at the end of the term, and indeed after
: using C++ in several other courses and in nontrivial projects of
: their own, few if any would be able to predict which lines in the
: function g() below will cause compiler errors:
: class A {
: protected:
: int s;
: void f(A*);
: };
: class B : private A {
: private:
: int i;
: friend void g();
: };
: class C : public B {};
: A *a = new A; C *c = new C;
: void g() {
: c->f(a); (1)
: int temp1 = c->i; (2)
: int temp2 = a->s; (3)
: }
: In lines (1) and (2), c is treated as a B pointer and then the
: friendship of g() is used. In other words, the fact that i is
: not inherited from B as a member of C does not matter because
: automatic conversion kicks in. OK, so you justify that by saying
: that i is *really* B::i.
: There is an error only in line (3) due to an obscure rule about
: protected members. However this rule does not apply to f because
: in this case f is accessed via a B object after conversion, even
: though it is *really* A::f, and since g() is a friend of B it is
: *allowed* to automatically transform B* to A*. Why stop the
: transformation from C* at B*?
: I don't see any consistency in all this. Hopefully, some C++ Guru
: can enlighten me!
I am not a guru, but by definition a friend function can do everything that
a member function can do. I see no inconsistency in this rule. Note that
from the legal (C++ lawyer's) point of view, you access not a member of A,
but a member of an ancestor of B which happens to be protected in class A.
On the other hand, it seems to be very wise to watch out for friend
functions and avoid them as much as possible.
Happy Holidays,
----------------------------------------------------------------------------
IMHO. Igor Chudov, Resource Solutions Intl office (918)588-2309
Systems Engineer, for WilTel. home (918)585-5862
E-mail: igor_chudov@wiltel.com
http://m-net.arbornet.org/~ichudov
1819 South Jackson #32-P Tulsa OK 74107
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.
Author: rob@brewster.demon.co.uk (Rob Heyes)
Date: Fri, 23 Dec 1994 06:05:26 +0000 Raw View
In article <1994Dec21.160807.24935@merlin.hgc.edu>
> We have the same problem with graduate students. We teach a course
> in OO Programming and Design, alternately in Eiffel and C++. When
> using Eiffel, most student discussions and questions center around
> the OO design of the project. When using C++, too much discussion
> and questions are in regard to the syntax and semantics of C++.
>
> We are in the process of revising the curriculum so that students
> will learn the basics of OO using Eiffel, then use C++ in systems
> programming courses.
I'm curious, why do you have to teach them C++? Is this purely for
pragmatic reasons?
Rob
--
Q: What happens when the human body is completely submerged in water?
A: The telephone rings
Rob Heyes rob@brewster.demon.co.uk
Author: jcm@hgc.edu (James McKim)
Date: Wed, 21 Dec 1994 16:08:07 GMT Raw View
In article <3cs6fs$dds@library.erc.clarkson.edu> satish@gandalf.mcs.clarkson.edu (Satish Thatte) writes:
>After trying to teach a class of (mostly) sophomores C++ for
>several years, I admit to having mixed feelings. Most of my
>competent students grasp the basics of both C++ and object
>systems in one term, contrary to the claims of those who
>denounce the idea of teaching OOP using C++. On the other hand
>I do have to spend most of my time teaching C++ rather than
>teaching interesting OOP issues.
>
We have the same problem with graduate students. We teach a course
in OO Programming and Design, alternately in Eiffel and C++. When
using Eiffel, most student discussions and questions center around
the OO design of the project. When using C++, too much discussion
and questions are in regard to the syntax and semantics of C++.
We are in the process of revising the curriculum so that students
will learn the basics of OO using Eiffel, then use C++ in systems
programming courses.
[...]
>
>Satish
Hope this helps,
-- Jim
--
*------------------------------------------------------------------------------*
Jim McKim (203)-548-2458 In exactly 3.2 seconds it will be a few
Internet: jcm@hgc.edu minutes to 5:00.
Author: Andrew Gilbert <a-gilbe@uiuc.edu>
Date: 17 Dec 1994 20:00:09 GMT Raw View
> After trying to teach a class of (mostly) sophomores C++ for
> several years, I admit to having mixed feelings. Most of my
> competent students grasp the basics of both C++ and object
> systems in one term, contrary to the claims of those who
> denounce the idea of teaching OOP using C++. On the other hand
> I do have to spend most of my time teaching C++ rather than
> teaching interesting OOP issues.
>
> I also have to say that at the end of the term, and indeed after
> using C++ in several other courses and in nontrivial projects of
> their own, few if any would be able to predict which lines in the
> function g() below will cause compiler errors:
>
> class A {
> protected:
> int s;
> void f(A*);
> };
>
> class B : private A {
> private:
> int i;
> friend void g();
> };
>
> class C : public B {};
>
> A *a = new A; C *c = new C;
>
> void g() {
> c->f(a); (1)
> int temp1 = c->i; (2)
> int temp2 = a->s; (3)
> }
>
Wouldn't case one really be an example of protected members
being accessible by classes inherited from the base, not
of friendship?
> In lines (1) and (2), c is treated as a B pointer and then the
> friendship of g() is used. In other words, the fact that i is
> not inherited from B as a member of C does not matter because
> automatic conversion kicks in. OK, so you justify that by saying
> that i is *really* B::i.
>
> There is an error only in line (3) due to an obscure rule about
> protected members. However this rule does not apply to f because
> in this case f is accessed via a B object after conversion, even
> though it is *really* A::f, and since g() is a friend of B it is
> *allowed* to automatically transform B* to A*. Why stop the
> transformation from C* at B*?
I believe friendship is not inheritable. I would find it most
disturbing that an inherited class B could grant friendship to a
function g() which A (the base) knows nothing about and which
could then violate A's protection.
>
> I don't see any consistency in all this. Hopefully, some C++ Guru
> can enlighten me!
>
> Satish
Author: satish@gandalf.mcs.clarkson.edu (Satish Thatte)
Date: 16 Dec 1994 13:59:24 GMT Raw View
After trying to teach a class of (mostly) sophomores C++ for
several years, I admit to having mixed feelings. Most of my
competent students grasp the basics of both C++ and object
systems in one term, contrary to the claims of those who
denounce the idea of teaching OOP using C++. On the other hand
I do have to spend most of my time teaching C++ rather than
teaching interesting OOP issues.
I also have to say that at the end of the term, and indeed after
using C++ in several other courses and in nontrivial projects of
their own, few if any would be able to predict which lines in the
function g() below will cause compiler errors:
class A {
protected:
int s;
void f(A*);
};
class B : private A {
private:
int i;
friend void g();
};
class C : public B {};
A *a = new A; C *c = new C;
void g() {
c->f(a); (1)
int temp1 = c->i; (2)
int temp2 = a->s; (3)
}
In lines (1) and (2), c is treated as a B pointer and then the
friendship of g() is used. In other words, the fact that i is
not inherited from B as a member of C does not matter because
automatic conversion kicks in. OK, so you justify that by saying
that i is *really* B::i.
There is an error only in line (3) due to an obscure rule about
protected members. However this rule does not apply to f because
in this case f is accessed via a B object after conversion, even
though it is *really* A::f, and since g() is a friend of B it is
*allowed* to automatically transform B* to A*. Why stop the
transformation from C* at B*?
I don't see any consistency in all this. Hopefully, some C++ Guru
can enlighten me!
Satish