Path: utzoo!attcan!uunet!isc-br!tau-ceti!cims2!proto!joe
From: joe@proto.COM (Joe Huffman)
Newsgroups: comp.lang.c++
Subject: Re: Problems of Zortech C++ v2.1
Summary: NOT a Zortech bug, read E & S.
Message-ID: <1331@proto.COM>
Date: 16 Jul 90 16:58:05 GMT
References: <82035@tut.cis.ohio-state.edu> <31714@cup.portal.com>
Distribution: na
Organization: Prototronics; Sandpoint, Idaho
Lines: 105

In article <31714@cup.portal.com>, Rick_R_Kitts@cup.portal.com writes:
> This is a story of me vs. Zortech 2.06.
> 
> . . .					 I start testing and discover
> that I can't do a cast from an unsigned short to double without an error.
.
.
.
> 	Thinking that I would provide a work around of some sort I
> decide to overload the member function of the class which I am working
> on. I now had to member functions with the following prototypes:
> 
> 	SetFieldVal(int, double)
> 	SetFieldVal(int, unsigned short)
> 
> Ok, I recompile and Zortech yells about an ambiguous function definition
> and throws up. Hmm says I. 

Okay, first off from page 34 of E & S: "It follows, contrary to popular
misconception, that the safety of any conversion from an integral type
to a floating type is implementation dependent."  

Now, I don't know why it was implemented this way (I would call Walter and
ask him, but he doesn't get up this early) but unsigned integral types are
converted as if they are signed when converting to floating type.  I'm
fairly sure that he will either email or post the reason soon.  Although
this is certainly undesirable in your case it is quite within the 
specification of the language.

As to the overloading of the functions Zortech is correct.  See page 324
of E & S.  I presume you had something like:

SetFieldVal(2, 17);
or
int i = 2, j = 17;
SetFieldVal(i, j);

If you had 

SetFieldVal(2, (unsigned short) 17);
or
int i = 2;
unsigned short j = 17;
SetFieldVal(i, j);

It would have worked.


The reason is that both the conversion from int to unsigned short and
int to double are "equally distant" (my term) according to E & S.

> pass 1, and then pass 2, and finally says "ZTC bug: 9513". Hmm again says I.

Definitely a bug in ZTC, this is an encoded assertion failure in the compiler.
The number refers to a file and line number in the source code of the
compiler.  Usually this is the result of some error condition in the code
that was not caught earlier (like during the parseing) and the later pass
should never have seen that case.  Not always of course.  But if you 
isolate the bug by compiling with -v and using #if 0 ... #endif pairs you
will usually find an error in your code, in any case send it to Zortech
via the BBS (206-822-6907), snail mail, or even email it to me.  Please
make the bug report as small as possible (1 page or less if possible) without
include files other than compiler supplied.

> I happen to have a CFRONT at home. Its based on 1.1 of the language, but
> I hadn't used any 2isms in my code yet. So I took the code home to run
> through my CFRONT. Well, well, well. Everything works just fine. No
> ambiguous function errors, no problems with static objects, nothing. 

The ambiguous function should have been reported by CFRONT, that it didn't
is a bug in that version of CFRONT (relative to 2.0, perhaps 1.1 intentional
did things differently).  It is difficult to comment on the static object
problem without your source code... 

> a check and I run down and buy Turbo C++. Run back to the office, 
> install, set a few things up, cross my fingers, rub my rabbits foot, etc.
> and start the compile. Voila! An executable file! And it works. Same
> exact code as that given to Zortech. 

Turbo C++ has a bug in it that worked in your favor.

> BTW, I did call Zortech about the ZTC bug message. I was told that it
> was usually a user problem and in any case the number didn't mean anything
> since it was a random number.

Not exactly a random number.  See above.

> For me at least, the moral of the story is that Zortech is a nice toy.
> It does fast compiles, and the debugger is useful. I can't see using
> it as something to make money with. And I absolutely will never, ever,
> ever, risk my reputation on any Zortech product again.

A rather drastic statement don't you think?  What if you want to port your
C++ code to OS/2 or Windows?  Also, relying on a bug in Turbo C++ and
unportable assumptions about conversion from integral to float types seems
a bit risky to me.  You should be grateful that the Zortech compiler 
pointed them out to you.  

---
Zortech is my major source of income.  Statements about them or their 
competitors cannot be totally without bias.
-- 
joe@proto.com
uunet!proto!joe
FAX: 208-263-8772