Subclassing SWIG generated c++ class

ruby-talk
1

hi all,

I’ve created simle c++ class

— class.cxx —
#if SWIG
%module myext
#endif

class Foo {
Foo () {};
hello_world () {};
};

and then generated ruby extension module ‘Myext’ using SWIG for it…
no problem so far, I’m able to require the extension,
create instances of Foo, invoke methods, etc.

but when I try to subclass such class in ruby, the original class gets
always created, am I missing something, e.g.

— test.rb —
require ‘./myext.so’

module Myext
class Bar < Foo
end
end

k = Myext::Foo.new
puts k
k1 = Myext::Bar.new
puts k1

both .new statements create instance of Myext::Foo…

ruby 1.6.7 (2002-03-19) [i386-linux]
swig 1.3.11

I’m now trying the cvs versions of SWIG and ruby, but if anyone knows what’s
happening…

greets,
martin

···

–
Dennis: Help! Help! I’m being repressed! Come see the violence
inherent in the system! Violence inherent in the system!
– Monty Python and the Holy Grail

2

maybe, the generated code lacks the call ‘rb_obj_call_init’ in the code
of the C functions that implement the ‘new’ Ruby method.

Pierre Brengard

Martin Man wrote:

···

hi all,

I’ve created simle c++ class

— class.cxx —
#if SWIG
%module myext
#endif

class Foo {
Foo () {};
hello_world () {};
};

and then generated ruby extension module ‘Myext’ using SWIG for it…
no problem so far, I’m able to require the extension,
create instances of Foo, invoke methods, etc.

but when I try to subclass such class in ruby, the original class gets
always created, am I missing something, e.g.

— test.rb —
require ‘./myext.so’

module Myext
class Bar < Foo
end
end

k = Myext::Foo.new
puts k
k1 = Myext::Bar.new
puts k1

both .new statements create instance of Myext::Foo…

ruby 1.6.7 (2002-03-19) [i386-linux]
swig 1.3.11

I’m now trying the cvs versions of SWIG and ruby, but if anyone knows what’s
happening…

greets,
martin

3

Martin Man wrote:

k = Myext::Foo.new
puts k
k1 = Myext::Bar.new
puts k1

both .new statements create instance of Myext::Foo…

… and this is completely correct and intended. The object in
the subclass contains data for all base classes. What’s the
problem?

4

Martin,

I will take your word for it that this was broken in SWIG-1.3.11 (i.e. I’m
not going to go back and check ;). But I can tell you that we fixed a lot of
bugs for the Ruby module in version 1.3.12 (released a few days back) and
that I cannot reproduce this problem under SWIG-1.3.12.

HTH,

Lyle

5

maybe, the generated code lacks the call ‘rb_obj_call_init’ in the code
of the C functions that implement the ‘new’ Ruby method.

well that could be, I can see by walking thru ObjectSpace that my class has
actually been registered within ObjectSpace, but instantiation yields the
original c++ class, btw: any chance I can get this call included automatically
by swig instead of hacking the generated wrapper sources ???

Pierre Brengard

thanx,
martin

···

On Fri, Jun 07, 2002 at 05:13:59PM +0900, Pierre Brengard wrote:

Peasant 1: Who’s that there?
Peasant 2: I don’t know… Must be a king…
Peasant 1: Why?
Peasant 2: He hasn’t got shit all over him.
– Monty Python and the Holy Grail

6

well the problem is that you’d expect my program to output something like

#Myext::Foo:0x401ae050
#Myext::Bar:0x401ae430

but it’s outputting

#Myext::Foo:0x401ae050
#Myext::Foo:0x401ae430

the problem was exactly what Pierre Brengard pbrengard@bct.de suggested,
missing call to rb_obj_call_init inside of wrapped new Ruby method, I’ve now
tried cvs version of SWIG which splits c++ constructors into two methods,

  • singleton method ‘alloc’
  • and instance method ‘initialize’

and now I can happily wrap c++ classes inside ruby…

thanx,
martin

···

On Fri, Jun 07, 2002 at 05:34:22PM +0900, Christian Szegedy wrote:

Martin Man wrote:

k = Myext::Foo.new
puts k
k1 = Myext::Bar.new
puts k1

both .new statements create instance of Myext::Foo…

… and this is completely correct and intended. The object in
the subclass contains data for all base classes. What’s the
problem?

–
God: What are you doing now?
Arthur: Averting our eyes, oh Lord.
God: Well, don’t. It’s just like those miserable psalms, always so depressing.
– Monty Python and the Holy Grail

7

… I’ve now tried cvs version of SWIG which splits c++ constructors into two methods,

  • singleton method ‘alloc’
  • and instance method ‘initialize’

Just to be clear for anyone else following this thread; the Ruby method
names are still Foo.new and Foo#initialize. I am aware of the changes
for the Ruby allocation framework in 1.7 and am trying to decide exactly
what impact (if any) it should have on SWIG’s code generation. It does
seem to be the case that Matz has made the new allocation framework
back-compatible, i.e. SWIG-generated code that provides Foo.new instead
of Foo.allocate seems to do the right thing.