home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / apollo / 3090 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  2.4 KB
  1. Xref: sparky comp.sys.apollo:3090 comp.windows.interviews:2302
  2. Newsgroups: comp.sys.apollo,comp.windows.interviews
  3. Path: sparky!uunet!haven.umd.edu!wam.umd.edu!dododge
  4. From: dododge@wam.umd.edu (David O. Dodge)
  5. Subject: Interviews vs. Apollo C++
  6. Message-ID: <1992Jul23.100220.12904@wam.umd.edu>
  7. Summary: major problems
  8. Originator: dododge@rac2.wam.umd.edu
  9. Sender: usenet@wam.umd.edu (USENET News system)
  10. Nntp-Posting-Host: rac2.wam.umd.edu
  11. Organization: University of Maryland at College Park
  12. Date: Thu, 23 Jul 1992 10:02:20 GMT
  13. Lines: 39
  14.  
  15. Note that this is crossposted to both comp.sys.apollo and
  16. comp.windows.interviews.
  17.  
  18. At my workplace we're trying to get InterViews running on our Apollo
  19. Domain/OS machines. I believe we're using IV 3.0.1 beta and the latest
  20. version of Apollo CC, but the binaries are segmentation faulting all over
  21. the place.
  22.  
  23. Here's an example of one spot where things are going wrong:
  24.  
  25.   For one of our own programs we have a class we wrote called OurViewer,
  26.   which inherits most of its stuff from Viewer. We don't define a Draw()
  27.   member function for OurViewer, and when we call Draw() within one of
  28.   OurViewer's member functions, the program dies. If I replace the Draw()
  29.   invocation with an explicit call to Viewer::Draw() it suddenly starts
  30.   working.
  31.  
  32.   A process traceback shows the problem to be with the invocation itself,
  33.   i.e. the program never actually enters Draw(), but gives a "reference
  34.   to illegal address" or some such when it attempts to make the call.
  35.  
  36. This behavior is only consistent in that the program always crashes at
  37. the same places. However other calls of this type (a member calling a
  38. virtual function that was inherited from another class) work just fine --
  39. it's only a few specific spots that have the problem.
  40.  
  41. Anyway this is a MAJOR annoyance, and from the looks of it it's most likely
  42. the compiler's fault. This code runs just fine on a Sun Sparc.
  43.  
  44. Note that I'm coming into this a bit late -- someone else already did
  45. most of the work in getting InterViews to compile at all (I believe cpp
  46. was crashing originally or something like that). The person who originally
  47. did the work changed only a few things in the code, and in any case those
  48. changes shouldn't be causing this type of problem.
  49.  
  50. So has anyone actually managed to get InterViews built on an Apollo? Any
  51. suggestions?
  52.  
  53.                                          -Dave Dodge/dododge@wam.umd.edu
  54.