Visual C++ and RUBY

ruby-talk
1

Hi there!

I am again evaluating RUBY as an embedded scripting language for a large
C++ application which is developed using Microsoft VIsual C++ .NET 2003
Beta 1 ( aka “Everet” ) its the successor to Visual Studio .NET or VC7.0
and has VC7.1 as its version tag as well as the MSVC compiler version 1310…

Ok back to my question. I am using RUBY 1.6.7 and everything works ok…
however someone pointed out to me that whenever an exception occurs in
RUBY code RUBy executes a long jump …and thus the stack gets not
cleaned up … in particular consider this example:

class SomeClass { … }

void MyFunction()
{
SomeClass localInstanceOnStack;
CallSomeRubyMethod( “MyRubyMethod” );
}

Now when the call to the ruby method “MyRubyMethod” results in an
exception, the “LocalInstanceOnStack” class var will never be
deleted/the destructor not called…

Is this true ? Or are the problems different with the longjmp “feature” ?

I need to clarify this, since i am embedding Ruby into a high available
server application so it needs to be stable…

If this is true, is there any way around this, or any future changes
that will solve this ?

Thanks in advance
Bernahrd GLueck

2

Bernhard Glueck wrote:

Now when the call to the ruby method “MyRubyMethod” results in an
exception, the “LocalInstanceOnStack” class var will never be
deleted/the destructor not called…

Is this true? Or are the problems different with the longjmp “feature”?

Yes, you are correct. The stack is not going to be “unwound” and so your
local variable’s destructors are not going to be called. Along the same
lines, if you had dynamically allocated memory at the top of the
function, e.g.

 void MyFunction()
 {
   SomeClass localInstanceOnStack;
   char *str = new char[50];
   CallSomeRubyMethod( "MyRubyMethod", str );
   delete [] str;
 }

then your code will leak memory when “MyRubyMethod” raises an exception.

If this is true, is there any way around this, or any future changes
that will solve this?

Paul Brannan has done a lot of research into this problem and has posted
some good information in the past. If you have a time machine handy,
travel ahead to Saturday, November 2, when Paul Brannan will be giving a
talk on exception handling:

http://www.rubyconf.org/speakers.php#brannp

If time travel is out of the question, try doing a Google search for
“ruby c++ exception” (or similar keyword combinations). It should turn
up some posts that give suggestions about what to do; e.g. instead of
calling a Ruby method directly via rb_funcall(), wrap it with a call to
rb_protect() or rb_rescue();

Hope this helps,

Lyle

3

Hi Matz,

why did you change the semantics of Class.inherited? I am
kind of wondering if this really was a change for the
better? For me once I pass the line

class SubClass < SuperClass

the basic inheritance process is finished.

···

class A
def self.inherited(sub_klass)
begin
sub_klass.later_alligator
rescue
p "no alligator yet"
end
end
end

class B < A
def self.later_alligator
p "later alligator"
end
end

As of today this results in

“later alligator”

/Christoph

4

Is it a good advertisement for Ruby conference that the web page itself is
coded in PHP and not in Ruby? (No offense).

Regards,

Bill

···

============================================================================
Lyle Johnson lyle@users.sourceforge.net wrote:

http://www.rubyconf.org/speakers.php#brannp

5

Christoph wrote:

Hi Matz,

why did you change the semantics of Class.inherited? I am
kind of wondering if this really was a change for the
better? For me once I pass the line

class SubClass < SuperClass

the basic inheritance process is finished.

Does this perhaps fix the problem discussed in
http://www.ruby-talk.org/30366 ?

6

Hi,

···

In message “inherited change?” on 02/09/28, “Christoph” chr_news@gmx.net writes:

why did you change the semantics of Class.inherited? I am
kind of wondering if this really was a change for the
better? For me once I pass the line

class SubClass < SuperClass

the basic inheritance process is finished.

Consistency with Class#new{}, which calls “inherited” after the body
execution. Raising exception within “inherited” just leaves
half-baked class, so I felt it’s better to call it after the
initialization.

						matz.
7

“Joel VanderWerf” wrote
…

Does this perhaps fix the problem discussed in
http://www.ruby-talk.org/30366 ?

Well it runs squarely against Guy’s argument
(pretty deep down in the associated thread ) that
one should not create the associated class constant
if inherited failed with an exception …

···

class A
def self.inherited(sub_klass)
p sub_klass
raise
end
end

begin
class B < A
end
rescue
end

p B

–

output before this change

B
T:\rbAE.tmp:14: uninitialized constant B (NameError)

output today

B
B

/Christoph

8

“William Djaja Tjokroaminata” billtj@z.glue.umd.edu wrote in message
news:an2ffb$i6a$2@grapevine.wam.umd.edu…

Is it a good advertisement for Ruby conference that the web page itself is
coded in PHP and not in Ruby? (No offense).

Regards,

Bill

I don’t think it speaks one way or the other…my 2 pennies. That would go
in my “rententive” drawer. (no offense either)

Bob