home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / windows / intervie / 3452 < prev    next >
Encoding:
Text File  |  1992-12-22  |  1.9 KB  |  49 lines
  1. Newsgroups: comp.windows.interviews
  2. Path: sparky!uunet!mcsun!sunic!ugle.unit.no!ugle.unit.no!steinarb
  3. From: steinarb@idt.unit.no (Steinar Bang)
  4. Subject: Re: HELP: 3.1 Doc core dump
  5. In-Reply-To: Thomas Wuensche's message of Mon, 21 Dec 1992 18:15:02 GMT
  6. Message-ID: <STEINARB.92Dec22101423@tindved.idt.unit.no>
  7. Sender: news@ugle.unit.no (NetNews Administrator)
  8. Organization: Norwegian Inst. of Tech./University of Trondheim, Trondheim,
  9.     Norway
  10. References: <1992Dec21.081629.26509@ccds3.ntu.edu.tw> <tw.724961702@fgb1>
  11. Date: 22 Dec 92 10:14:23
  12. Lines: 35
  13.  
  14. > f80204@cad.ee.ntu.edu.tw (Hung-Chi Chu) writes:
  15.  
  16. >>  I tried to compile iv-3.1 under Sun SPARCstation SUNOS-4.1.2 with
  17. >> X11R5 and gcc-2.3.2 and everything seemed to be ok, but when I run
  18. >> doc it core dump.  Can anyone tell me what's wrong?
  19.  
  20. To which in article <tw.724961702@fgb1>, Thomas Wuensche <tw@fgb1.fgb.mw.tu-muenchen.de> replies:
  21.  
  22. > The solution for me was to make resource a virtual base class for
  23. > glyph and handler.
  24.  
  25. There is a patch from Johan Garpendahl <garp@isy.liu.se> available at
  26. ugle.unit.no:/pub/X11/contrib/InterViews/3.1-beta3-patch (I am sure it
  27. can be found at Johan's "native" ftp server as well, isy.liu.se, but I
  28. haven't checked). This fixes two things:
  29.  o the Doc coredump 
  30.  o the pattern menu of idraw (gives you the full number of built-in
  31.    patterns. 
  32. Read the instructions at the start of the file.
  33.  
  34. > Mark Linton dislikes this for performance reasons,
  35.  
  36. Well, I would have thought that virtual inheritance should give you
  37. more efficient code memoryusage-wise. Obviously experience did show
  38. that it wasn't so. I wonder why.
  39.  
  40. > but I don't know a better way to get it working with gcc.
  41. > Of course I'd also like to omit any performance drawbacks :-).
  42.  
  43. I have been told by a trustworthy source that the virtual function
  44. pointer table bug in g++ is being worked on. 
  45.  
  46. BTW, Merry X-mas everybody!
  47.  
  48. - Steinar
  49.