Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!uw-entropy!dataio!bright From: bright@Data-IO.COM (Walter Bright) Newsgroups: comp.lang.c++ Subject: Re: Zorteck C++ blue... Message-ID: <1855@dataio.Data-IO.COM> Date: 30 Jan 89 19:52:48 GMT References: <410c930c.129dc@blue.engin.umich.edu> Reply-To: bright@dataio.Data-IO.COM (Walter Bright) Distribution: comp.lang.c++ Organization: Data I/O Corporation; Redmond, WA Lines: 35 To: yhe@caen.engin.umich.edu Subject: Re: Zorteck C++ blue... Newsgroups: comp.lang.c++ In-Reply-To: <410c930c.129dc@blue.engin.umich.edu> Organization: Data I/O Corporation; Redmond, WA Cc: Bcc: In article <410c930c.129dc@blue.engin.umich.edu> you write: <(1) It will not properly return for derived class: < System operator*(System& b); // not work. I can help you better if you provide a complete program that fails, rather than a fragment. <(2) Blink can't find stuff in library. This happens in some odd cases. I have this fixed for the next version. <(3) Overload cast name based on the sequence functions appear in the .cpp < file not in the sequence of definition in header file. that will cause < same name casting in different file, unless you pull all the functions < has same name in one file, ... This will go away when typesafe linkage is implemented. This is a problem with all current implementations. <(4) optimizer give wrong result Please email me the code that causes this. I've gotten only 1 bug report on the optimizer in the last 6 months. I'm very interested in fixing any problems with it. Simply saying that you get the wrong result is useless to anyone. For example, I've had people complain bitterly to me about compiler bugs, when their code had uninitialized pointers in it which caused their grief. < Also (Inverting (50x50) matrix compiled by msc 5.1 take 8.7 sec, ZTC 12.8 < sec, both use maximum optimization large model, use 10Mhz 1 wait AT with < 80287), therefore the optimization not doing much any way. Try using the -f flag to generate inline 8087 code. Anyway, I think you'll find that floating point code in general is so slow that a few cycles saved by an optimizer is lost in the overhead of floating point calculations.