zoo@aps1.spa.umn.edu (david d [zoo] zuhn) (12/16/90)
I have gotten the XView header files to be compatible with g++ 1.37.2,
and now have a problem with a small program that I have written.
My intention is to be able to keep a Frame inside of a class object,
and all of the callbacks for this object's controls will be methods of
the object. My problem is that my quit callback (this is a hello
world type program to start with) will crash my program, with a bus
error deep in the notifier. I don't have a -g XView, and don't have
the disk space to build one if I wanted to.
This is probably a bug in my understanding of how and where C++
objects have their memory allocated and deallocated, but I can't
figure this out.
If someoneout there has an idea of how to do this, please let me know.
FWIW: SunOS 4.1, XView 2.0 (with modified headers to allow ANSI C and
C++ compilation), g++ 1.37.2a, libg++-1.37.2
david d [zoo] zuhn Univ. of Minnesota Dept. of Astronomy
zoo@aps1.spa.umn.edu Automated Plate Scanner Project
------------------ The sample code --------------
#include <stddef.h>
#include <stream.h>
#include <xview/xview.h>
#include <xview/frame.h>
#include <xview/panel.h>
#include <xview/xv_xrect.h>
class Test
{
public:
Test(int width, int height);
~Test();
int quit (Panel_item item, Event *event);
Frame frame;
Panel panel;
};
Test::Test(int width, int height)
{
frame = (Frame) xv_create (NULL, FRAME,
XV_WIDTH, width,
XV_HEIGHT, height,
NULL);
panel = (Panel) xv_create (frame, PANEL,
PANEL_LAYOUT, PANEL_HORIZONTAL,
NULL);
(void) xv_create (panel, PANEL_BUTTON,
PANEL_LABEL_STRING, "Quit",
PANEL_NOTIFY_PROC, quit,
NULL);
}
Test::~Test()
{
if (frame)
cout << "frame\n";
else
cout << "no frame\n";
}
int Test::quit (Panel_item item, Event *event)
{
xv_destroy_safe (frame);
return XV_OK;
}
int main (int argc, char *argv[])
{
Test *test;
xv_init (XV_INIT_ARGC_PTR_ARGV, &argc, argv, NULL);
test = new Test (800, 400);
xv_main_loop (test->frame);
delete test;
return 0;
}
---------------- The post mortem ------------------
#0 0x2fbc in xv_destroy_status ()
#1 0x5c58 in notify_destroy ()
#2 0x163f4 in ndis_default_prioritizer ()
#3 0x5954 in notify_client ()
#4 0x6078 in ndis_default_scheduler ()
#5 0x1bb88 in xv_scheduler_internal ()
#6 0x53bc in ndis_dispatch ()
#7 0x14538 in notify_start ()
#8 0xbd98 in xv_main_loop ()
#9 0x24d0 in main (argc=1, argv=0xf7fffc84) (xv.cc line 64)salc@aristotle.shearson.com (Sal Cataudella) (12/19/90)
In article <ZOO.90Dec16021713@grumpy.spa.umn.edu> zoo@aps1.spa.umn.edu (david d [zoo] zuhn) writes:
Xref: shearson.com comp.windows.open-look:259 alt.toolkits.xview:68
Path: shearson.com!uunet!know!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!mcnc!shelby!msi.umn.edu!s16.msi.umn.edu!zoo
From: zoo@aps1.spa.umn.edu (david d [zoo] zuhn)
Newsgroups: comp.windows.open-look,alt.toolkits.xview
Date: 16 Dec 90 07:17:13 GMT
Sender: news@s1.msi.umn.edu
Distribution: all
Organization: Minnesota Automated Plate Scanner Lab
Lines: 103
I have gotten the XView header files to be compatible with g++ 1.37.2,
and now have a problem with a small program that I have written.
My intention is to be able to keep a Frame inside of a class object,
and all of the callbacks for this object's controls will be methods of
the object. My problem is that my quit callback (this is a hello
world type program to start with) will crash my program, with a bus
error deep in the notifier. I don't have a -g XView, and don't have
the disk space to build one if I wanted to.
This is probably a bug in my understanding of how and where C++
objects have their memory allocated and deallocated, but I can't
figure this out.
If someoneout there has an idea of how to do this, please let me know.
FWIW: SunOS 4.1, XView 2.0 (with modified headers to allow ANSI C and
C++ compilation), g++ 1.37.2a, libg++-1.37.2
david d [zoo] zuhn Univ. of Minnesota Dept. of Astronomy
zoo@aps1.spa.umn.edu Automated Plate Scanner Project
david the problem is very simple, your quit method is being invoked with a
garbage 'this' pointer. As a result when your test::quit() method tries to
access data members it is offsetting from *garbage*. Taking the address of
the method you want to call back is *not* enough;To callback the method you
need to associate it with an object pointer.
Suggestion: create a generic callback function that can take as parameters
the pointer to the method and the pointer to the object, then execute the
method in the context of the specific object.
Current C based toolkits are not setup to handle calling back C++ methods.
You have to provide the interface which does this.
--
Sal Cataudella
Internet: salc@sisyphus.shearson.com
UUCP: ...!uunet!slcpi!sisyphus!salc
(212) 464-8728salc@aristotle.shearson.com (Sal Cataudella) (12/19/90)
In article <SALC.90Dec18115012@aristotle.shearson.com> salc@aristotle.shearson.com (Sal Cataudella) writes: Xref: shearson.com comp.windows.open-look:260 alt.toolkits.xview:69 Newsgroups: comp.windows.open-look,alt.toolkits.xview Path: shearson.com!newshost!salc From: salc@aristotle.shearson.com (Sal Cataudella) Sender: news@shearson.com (News) Organization: Lehman Brothers References: <ZOO.90Dec16021713@grumpy.spa.umn.edu> Distribution: all Date: 18 Dec 90 11:50:12 In article <ZOO.90Dec16021713@grumpy.spa.umn.edu> zoo@aps1.spa.umn.edu (david d [zoo] zuhn) writes: Xref: shearson.com comp.windows.open-look:259 alt.toolkits.xview:68 Path: shearson.com!uunet!know!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!mcnc!shelby!msi.umn.edu!s16.msi.umn.edu!zoo From: zoo@aps1.spa.umn.edu (david d [zoo] zuhn) Newsgroups: comp.windows.open-look,alt.toolkits.xview Date: 16 Dec 90 07:17:13 GMT Sender: news@s1.msi.umn.edu Distribution: all Organization: Minnesota Automated Plate Scanner Lab Lines: 103 [ Description of problem and source code follows...] david d [zoo] zuhn Univ. of Minnesota Dept. of Astronomy zoo@aps1.spa.umn.edu Automated Plate Scanner Project > david the problem is very simple, your quit method is being invoked with a > garbage 'this' pointer. As a result when your test::quit() method tries to > access data members it is offsetting from *garbage*. Actually the reason for the core dump is because a method pointer is not just a plain function pointer, it is actually a structure which contains various other information as well. You cannot cast a method pointer to a plain function pointer and expect it to work... The rest of the suggestion is valid Taking the address of the method you want to call back is *not* enough;To callback the method you need to associate it with an object pointer. Suggestion: create a generic callback function that can take as parameters the pointer to the method and the pointer to the object, then execute the method in the context of the specific object. Current C based toolkits are not setup to handle calling back C++ methods. You have to provide the interface which does this. -- Sal Cataudella Internet: salc@sisyphus.shearson.com UUCP: ...!uunet!slcpi!sisyphus!salc (212) 464-8728 -- Sal Cataudella Internet: salc@sisyphus.shearson.com UUCP: ...!uunet!slcpi!sisyphus!salc (212) 464-8728