rchen@m.cs.uiuc.edu (08/08/89)
Does anyone has problems with fgl.lib in Zortech C++ (1.06 and 1.07)? To be more specific, has anyone seen the error message: "FATAL ERROR: x coordinate out of range. TABELS.ASM line 107." ? As my code grows bigger (several thousand lines total), everything becomes shaky, i.e. the program becomes code sensitive (scary, isn't it?). Calling a subroutine (not necessarily a specific one) once would be different from calling it twice (one crashes the system and the other don't). What in the subroutine are just a few dummy assignment statements, no arguments, no pointers, or references involved. I wonder if somebody out there has similar experience with Zortech C++ as Zortech people claims nobody had complained about this before. We have two programmers, one with 10 years experience of programming and the other about 5 or 6 years -- both have about one year in C++, debug the project for two weeks (mainly rewrite and clean up the code in several ways). The error message keeps coming back at seemly random places. Any pointer would be greatly appreciated. By the way, I wish Zortech could be more helpfull than "just say no" ;-( -Ron
bright@Data-IO.COM (Walter Bright) (08/10/89)
In article <4800069@m.cs.uiuc.edu> rchen@m.cs.uiuc.edu writes:
<Does anyone has problems with fgl.lib in Zortech C++ (1.06 and 1.07)?
<To be more specific, has anyone seen the error message:
< "FATAL ERROR: x coordinate out of range. TABELS.ASM line 107." ?
This is caused by calling one of the graphics subroutines with a
coordinate that is off the edge of the screen, for instance trying to
draw a dot at (1000,100) on a 640*300 screen! The 'x coordinate' is
the column coordinate.Roy.Browning@f506.n106.z1.fidonet.org (Roy Browning) (08/10/89)
> From: rchen@m.cs.uiuc.edu > Date: 8 Aug 89 06:01:00 GMT > Message-ID: <4800069@m.cs.uiuc.edu> > Newsgroups: comp.lang.c++ > Does anyone has problems with fgl.lib in Zortech C++ (1.06 and 1.07)? > To be more specific, has anyone seen the error message: > "FATAL ERROR: x coordinate out of range. TABELS.ASM line 107." ? > shaky, i.e. the program becomes code sensitive (scary, isn't it?). > Calling a subroutine (not necessarily a specific one) once would be > different from calling it twice (one crashes the system and the other Ron: I only have about 5 years 'C' experience but hopefully I can make a suggestion that hasn't already been covered. Recently I caught myself trying to delete a character array that was stored on the stack. Every time the "String" destructor was being called It was generating allocation errors. I've since added a "stack flag" to avoid this problem. In the past EVERYTIME a program of mine worked intermittantly or generated random errors I traced the problem back to a coding error introduced by myself. Compiler bugs are usually consistant. If you can reduce the program to the essential functions that produce the error I will try to locate the trouble. Sometimes it requires unfamiliar eyes to spot a mistake. And if my eyes can't spot it then we'll try Bob Stout's, an avid Zortechie. BBSystem at (713)350-6284 in case my origin line gets truncated. However Joe Huffman (graphics library) frequents Walter's Board at (206)821-2123. He might be able to help you islotate the problem's source. Roy Browning
rchen@m.cs.uiuc.edu (08/10/89)
/* Written 2:01 pm Aug 9, 1989 by bright@Data-IO.COM in comp.lang.c++ */ > In article <4800069@m.cs.uiuc.edu> rchen@m.cs.uiuc.edu writes: > <Does anyone has problems with fgl.lib in Zortech C++ (1.06 and 1.07)? > <To be more specific, has anyone seen the error message: > < "FATAL ERROR: x coordinate out of range. TABELS.ASM line 107." ? > > This is caused by calling one of the graphics subroutines with a > coordinate that is off the edge of the screen, for instance trying to > draw a dot at (1000,100) on a 640*300 screen! The 'x coordinate' is > the column coordinate. I can see that from the error message. Both x and y were in the range of 10 to 100, hard coded in the fg subroutines for testing purposes.
rchen@m.cs.uiuc.edu (08/14/89)
/*
Try to run the following program and explain why point b is trashed,
whereas c is not. If you take the comments out, everything works
just fine. However, if I take the comments out in my program, I'll get
"ZTC bug: nnnn" at compile time. Still, it doesn't quite explain why
my program worked SOMETIMES depending on certain magic code combinations.
I used "ztc -a -b -s -r -cpp -mL -S prog.c" to compile this file.
By the way, this program gives correct results by using AT&T C++ 1.2
*/
#include <stream.hpp>
class Point {
int xc, yc;
Point(int x, int y) { xc = x; yc = y; }
// Point(Point& p) { xc = p.xc; yc = p.yc; }
Point() { xc = 0; yc = 0; }
~Point() { }
public:
int x() { return xc; }
int y() { return yc; }
// Point& operator=(Point&);
Point operator+(Point&);
};
// Point& Point::operator=(Point& p) { xc = p.xc; yc = p.yc; return *this; }
Point Point::operator+(Point& p) { Point q(xc + p.xc, yc + p.yc); return q; }
main()
{
Point a = Point(10, 0) + Point(0, 30);
Point c, b;
b = Point(10, 0) + Point(0, 30);
c = Point(10, 30);
cout << "a = (" << a.x() << ", " << a.y() << ")\n";
cout << "b = (" << b.x() << ", " << b.y() << ")\n";
cout << "c = (" << c.x() << ", " << c.y() << ")\n";
}nagle@well.UUCP (John Nagle) (08/15/89)
It seems to work fine with Zortech 1.07, with the commented-out
code restored. The result of execution is
a = (10, 30)
b = (10, 30)
c = (10, 30)
Compiled with small model, no optimization, no debug info.
Please, when complaining about bugs, give the software version.
John Naglebright@Data-IO.COM (Walter Bright) (08/17/89)
In article <4800072@m.cs.uiuc.edu> rchen@m.cs.uiuc.edu writes: >Point Point::operator+(Point& p) { Point q(xc + p.xc, yc + p.yc); return q; } > b = Point(10, 0) + Point(0, 30); ZTC 1.07 has a problem in that functions that return a struct by value return it in a static memory location, instead of in a temporary on the stack. This will be fixed in the next version.
chouc@mist.CS.ORST.EDU (Chou Chung-Di) (08/19/89)
In article <2100@dataio.Data-IO.COM> Walter wrote: >ZTC 1.07 has a problem in that functions return a struct by >value return it in a static memory location, instead of in a >temporary on the stack. This will be fixed in the next >version. Appreciate if some one can answer my question (examples are great help) Do I have to initialize all the global objects inside the main program? I got this impression from Zortech's "C++ TOOLS" book (second paragraph, page 21) and the reason for asking this is that my (globally declared) objects are trashed whenever the constructors for those objects are called outside the main program. Thanks in advance for your time. ************************************************************ Tony Chou Department of Industrial & Manufacturing Engineering Oregon State University Corvallis, OR 97331 (503) 752-3421 ************************************************************