Path: utzoo!attcan!uunet!aplcen!samsung!brutus.cs.uiuc.edu!apple!vsi1!octopus!sjsumcs!horstman
From: horstman@sjsumcs.sjsu.edu (Cay Horstmann)
Newsgroups: comp.lang.c++
Subject: Re: Zortech 2.06 bug
Message-ID: <1990Feb8.181021.1929@sjsumcs.sjsu.edu>
Date: 8 Feb 90 18:10:21 GMT
Reply-To: horstman@sjsumcs.SJSU.EDU (Cay Horstmann)
Organization: San Jose State University
Lines: 44

I just received an unsolicited update disk for the Zortech compiler--ver. 2.06.
I am impressed, their customer support has really improved. 

So I tested it on some code, and unfortunately it bombed on the very first
module. Here is an extract of the situation:

A class has a private function f(int,int) and a public function f(). 

class A
{	int a;
	int f( int, int );
public:
	A();
	int f();
};

A::A()
{	a = 1;
}

int A::f( int x, int y )
{	return a = x*y;
}

int A::f()
{	return a;
}

int main()
{	A a;
	int n=a.f(); // ZORTECH ERROR: f is private
	return 0;
}
	

AT&T cfront 2.0 accepts this, as it should. Looks like Zortech first
checks for privacy before resolving the overloading. Please fix it, Walter!

Some might argue that this is a stupid practice in the first place, but
I rather like it. From the outside, there is a simple function f() and it
calls some more complicated (maybe recursive) helper function--why not call
that f(...) as well and let the overloader sort it out?

Cay