cwang@tut.cis.ohio-state.edu (Chang-Jia Wang) (07/11/90)
Hi, Zortech experts: I have just received my Zortech C++ 2.1. I made a test run on it and found several problems: 1. How can I print a file from ZWB? The Update Guide said that there is a "Print" option in the "File" menu. But I couldn't find any! How strange! Does anybody know what happen? 2. After some mouse operation on the main menu, ZWB sometimes inserted an "O" into my text. It happened three times. Was it a bug of ZWB? 3. I like the Alt-U in ZED v2.0, which flushes comments to the right. Can ZWB do the same thing? 4. I have a monochron monitor, so I cannot see iconized window unless I use "iconView" menu. Is there any way I can change the "color" of icons? 5. The Update Guide said that I can use DOS wildcard for filename. However, I found ZWB doesn't recognize wildcard when I "Open New Window" and "Visit." 6. I have a line in my autoexec.bat: set include=c:\zortech\include;d:\include and I have some .hpp files in d:\include. It worked fine in v2.0. However, v2.1 couldn't find those .hpp files, and prompted messages like: cannot open "foo.hpp" I suspect it is a bug. (I think v2.1 won't recognize the second directory of LIB environment either.) How can I work around with it? Thanks in advance. C.J.
Rick_R_Kitts@cup.portal.com (07/15/90)
This is a story of me vs. Zortech 2.06. I recently started a new job, and my first task was to move a bunch of C code into C++. This move was being done at my urging so it was important everything go reasonably smoothly (you know what I mean). Anyway, I do my designing and everyone is happy. Time to code. As it turns out we have Zortech 2.06 as the C++ compiler we will be using. I code away and in a little while I have the thing compiling (Yay!). I start testing and discover that I can't do a cast from an unsigned short to double without an error. (e.g. short has value 32769, after assignment (with cast) double has a value of 32770). I also discover this is range dependant (e.g. 1401 casts just fine, but the bigger the number the worse the error). I had remembered that there was some mention of floating point in the READ.ME file. This file says that the floating point emulator does not use IEEE format floats yet (luckily I don't have a co-processor or I may never have seen this). Well wonderful. We do analysis of financial data, and people generally get peeved when dollars randomly appear and disappear. 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. Now, I let this pass for the moment and remove the overload. I'm then fiddling with something else, a member function which returns a pointer to a dynamically allocated object. For one reason or another I change this to returning a pointer to a static object. Zortech gets through pass 1, and then pass 2, and finally says "ZTC bug: 9513". Hmm again says I. At this point I was becoming a bit concerned. Had I made some crucial, but hard to detect errors in my code? Was the ambiguous function error related to the problem I was now seeing? I'm far from and expert C++ programmer and of course suspected pilot as opposed to plane errors. Anyway I mucked about with this for a day. By the end of the day I had pretty much decided that I wasn't the problem. My boss however was concerned that perhaps the C++ move wasn't a good idea and that we all needed a bit more exerience with the language (he was quite diplomatic about the whole thing, even though I was feeling a little stupid). Luckily 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. Armed with this information I convince my boss that we should by Turbo C++. At this point he was still quite skeptical, and I, although confident in my determination, was sweating bullets. So he gives me 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. Happiness lives once again at work. I have thrown out Zortech altogether. 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. 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. ---Rick Rick_R_Kitts@portal.cup.com rkitts@slc.slac.stanford.edu
db@tc.fluke.COM (Dan Banay) (07/16/90)
In article <31714@cup.portal.com>, Rick_R_Kitts@cup.portal.com writes: > This is a story of me vs. Zortech 2.06. The subject line says v2.1. Which is it? > I may never have seen this). Well wonderful. We do analysis of financial ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > data, and people generally get peeved when dollars randomly appear and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Seems to me that you would want to avoid doubles when dealing with financial data. This is a very dangerous thing to do, and you should consider using longs (i.e 150.25 is represented as 15025) instead. > Happiness lives once again at work. I have thrown out Zortech altogether. Too bad for you. My experiences with Zortech C++ have been very good. ZTC++ generates *very* good code (up there with Watcom C, and other highly optimizing compilers). Version 2.1 fixes a lot of bugs and adds AT&T C++ 2.0 features that were missing in 2.06 (e.g. pointers to members). BTW, I just received C++/Views in the mail last week. From what I've seen thus far, C++/Views combined with ZTC++ can reduce the "4 month learning curve" to 4 days (no fooling). In addition, it comes with a superb browser/environment for developing Windows (and non-windows) code. I plan to post a review once I play with it some more. Dan -- +------------------------------------------------------------------------+ | Dan Banay | | db@tc.fluke.COM {microsoft,sun,uw-beaver}!fluke!db +1 206 356 6285 | +------------------------------------------------------------------------+ | John Fluke Mfg. Co., MS 223B, PO Box 9090, Everett, WA 98206-9090 USA | +------------------------------------------------------------------------+
dan@dyndata.UUCP (Dan Everhart) (07/16/90)
In article <31714@cup.portal.com> Rick_R_Kitts@cup.portal.com writes:
[...]
Ok, I recompile and Zortech yells about an ambiguous function definition
and throws up.
Compilers are supposed to give error messages when they detect errors.
Was the error message, in this case, correct?
So he gives me a check and I run down and buy Turbo C++.
I'll be interested in hearing about your experiences with Turbo C++,
and Borland's tech support as well.
Happiness lives once again at work. I have thrown out Zortech
altogether.
You might want to hang on to it to provide a second opinion when you
suspect Turbo C++ to be in error.
Zortech gets through
pass 1, and then pass 2, and finally says "ZTC bug: 9513".
[...]
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.
As has been discussed on the Zortech BBS, the number is an encoding of
the compiler source file and line where an internal error was
detected. It is not random. Is that really, literally what you were
told?
By the way, why did your Subject line say "v2.1" while your message
says you were using version 2.06?joe@proto.COM (Joe Huffman) (07/16/90)
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
bright@Data-IO.COM (Walter Bright) (07/17/90)
In article <31714@cup.portal.com> Rick_R_Kitts@cup.portal.com writes:
<I can't do a cast from an unsigned short to double without an error.
<(e.g. short has value 32769, after assignment (with cast) double has a
<value of 32770).
Oops. My mistake. If you have float.asm, this can be fixed by changing
the line:
CWD
to:
XOR DX,DX
that appears after the label A10:. If you don't have float.asm, I can
email it to you.Rick_R_Kitts@cup.portal.com (07/17/90)
In article <something> <someone> asks: (Portal is not the place for news :-) > [...were you literally told that ZTC bug: 9513 was a randome number?] Yes. Literally. ---Rick
Rick_R_Kitts@cup.portal.com (07/17/90)
In article <something> <someone> says: > [Your subject line says 2.1 but you say 2.06 in the article. Which is > it?] Sorry, it is 2.06. > [Too bad for you. ZTC generates good code from what I've seen]. I am very happy for you. The fact remains, however, that I gave source to 3 compilers (Zortech, a CFRONT, and Turbo C). 2 of those compilers ate the source happily. Zortech was not one of those. Please feel free to draw yor own conclusions. ---Rick
dan@dyndata.UUCP (Dan Everhart) (07/18/90)
In article <31804@cup.portal.com> Rick_R_Kitts@cup.portal.com writes:
I am very happy for you. The fact remains, however, that I gave source
to 3 compilers (Zortech, a CFRONT, and Turbo C). 2 of those compilers ate
the source happily. Zortech was not one of those. Please feel free to
draw yor own conclusions.
I conclude that Zortech is unlucky. From bugs I've seen discussed
here and my own experiences with Turbo and Ztc it seems to me that
each of the three compilers has bugs which the other two handle
correctly. You just hit one of the Zortech bugs. Unlucky for them
since it motivated bad press from you.
However, their giving you misinformation on a tech support call
(telling you that a compiler internal error message was a random
number and probably your fault) is abysmally poor performance. I hope
you got the name of the support person, and can stay mad long enough
to document the call in writing to Zortech. It would be doing their
customers (me) a favor.sidney@saturn.ucsc.edu (Sidney Markowitz ) (07/18/90)
In article <1331@proto.COM> joe@proto.COM (Joe Huffman) writes: >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. Just to set the record straight, TC++ does correctly detect the ambiguity when you overload a function on types double and unsigned short, then call it with an integer constant. So your assumption that that is what his code looked like when he ported seems to be incorrect, and there must be some explanation other than a bug in TC++ as well as in Cfront to explain why those compilers handled his program ok while Zortech 2.06 produced error messages or internal diagnostics about a compiler bug. I would tend to believe Walter Bright's message containing the one line correction to one of the compiler's asm files. -- sidney markowitz <sidney@saturn.ucsc.edu>
sidney@saturn.ucsc.edu (Sidney Markowitz ) (07/20/90)
In article <1331@proto.COM> joe@proto.COM (Joe Huffman) writes: >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." Reading the previous lines in that paragraph on page 34 reveals that "it follows" from the minimum magnitude values defined in sections 3.2.1 and 3.2.2 which allow an implementation to support integral values with more digits than the precision of some floating type values. So you can have a 10 digit long but only 6 digits of precision in a float and still have a conforming implementation. The very next sentence on page 34 specifies that the implementation dependence is when the integral value is in the range that can be represented as the floating type, but not represented exactly. That means that if you have an integral value that has no more digits than the precision of the floating type, the conversion is absolutely safe. -- sidney markowitz <sidney@saturn.ucsc.edu> Disclaimer: I guess I should let on when there's any hint of competitor-bashing, that I work for Borland, but I am not officially speaking for Borland.