home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11832 < prev    next >
Encoding:
Text File  |  1992-07-30  |  2.7 KB  |  80 lines

  1. Path: sparky!uunet!usc!nic!netlabs!lwall
  2. From: lwall@netlabs.com (Larry Wall)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Determining object type at runtime ?
  5. Message-ID: <1992Jul31.043437.21113@netlabs.com>
  6. Date: 31 Jul 92 04:34:37 GMT
  7. References: <Bs43r6.C24@ibg1.ibg.sub.org>
  8. Sender: news@netlabs.com
  9. Organization: NetLabs, Inc.
  10. Lines: 67
  11. Nntp-Posting-Host: scalpel.netlabs.com
  12.  
  13. In article <Bs43r6.C24@ibg1.ibg.sub.org> ado@ibg1.ibg.sub.org (Christoph Adomeit) writes:
  14. : Hi C++ freaks,
  15. : I need an idea about how to solve the following problem:
  16. : I embedded some C++ classes into an interpreter (perl).
  17. : Perl only understands C-calls, so I wrapped some functions
  18. : like
  19. : extern "C"
  20. : {
  21. :   void *new_myobject(constructor vars)
  22. :   { return (void*)new myobject(constructor vars); }
  23. :     int myobject_print(void *myobj)
  24. :     { 
  25. :         myobject *object=(myobject*)myobj;
  26. :         return object->print;
  27. :     }
  28. : }
  29. :     ...
  30.  
  31. You shouldn't need to go to all that trouble.  If your init routine
  32. that's called from userinit() is called, say, init_foo(), then in your
  33. foo.cc (or foo.C) file, say
  34.  
  35. extern "C" {
  36.     int init_foo();
  37. }
  38.  
  39. Everything else can be in native C++, since the init_foo() routine will
  40. resolve anything that would look strange to C.
  41.  
  42. Of course, this may work better with my version of perl.h, which is
  43. already C++ clean...  :-)
  44.  
  45. : I can get a reference to myobject from perl by calling &new_myobject.
  46. : Afterwards I can work from perl with the class like this:
  47. : $object=&new_myobject(constructor vars);
  48. : $result=&myobject_print($object);
  49. : everything works fine !. The only Problem is, if the ptr passed to
  50. : myobject print is not a pointer to a class "myobject". The program
  51. : will of course dump core. How I can make sure that myobject->print
  52. : is only called with a valid ptr to an object of type myobject ?
  53. : One solution would be to implement a method "type" to all known objects
  54. : and compare object->type, but most of the time i call functions with
  55. : int's char's ... for which I can't implement such a method.
  56. : Another idea would be to keep a list of valid pointers for each known
  57. : object and look up the adress. I think it's the only way.
  58. : Any idea ?
  59.  
  60. Since the pointer that Perl is passing around is presumably opaque, why
  61. not pass a type around with that, and check it when you go to glue your
  62. thread of control back into C++?
  63.  
  64. I find this very interesting, because I've got C++ linked with Perl right
  65. now too.  Also, if you have any bright ideas for how you'd like to see
  66. more object support in Perl 5, now's the time to speak up.  (I certainly
  67. don't intend to turn Perl into C++, since C++ is already pretty good
  68. at that.  But if I can do something to make the mapping a little less
  69. painful, I'm all ears.)
  70.  
  71. Larry Wall
  72. lwall@netlabs.com
  73.