# Visual C++ and RUBY **URL:** \ **Category:** ruby-talk\ **Created:** [27 September 2002 18:03 UTC](https://rubytalk.org/t/visual-c-and-ruby/2028 "2002-09-27T18:03:27Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Bernhard\_Glueck](https://avatars.discourse-cdn.com/v4/letter/b/f0a364/32.png) [@Bernhard\_Glueck](https://rubytalk.org/u/Bernhard_Glueck)\ **Post date:** [27 September 2002 18:03 UTC](https://rubytalk.org/t/visual-c-and-ruby/2028/1 "2002-09-27T18:03:27Z")
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 ---
**Author:** ![Lyle\_Johnson6](https://avatars.discourse-cdn.com/v4/letter/l/bb73d2/32.png) [@Lyle\_Johnson6](https://rubytalk.org/u/Lyle_Johnson6)\ **Post date:** [27 September 2002 20:25 UTC](https://rubytalk.org/t/visual-c-and-ruby/2028/2 "2002-09-27T20:25:36Z")
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 ---
**Author:** ![Christoph1](https://avatars.discourse-cdn.com/v4/letter/c/85f322/32.png) [@Christoph1](https://rubytalk.org/u/Christoph1)\ **Post date:** [27 September 2002 20:25 UTC](https://rubytalk.org/t/visual-c-and-ruby/2028/3 "2002-09-27T20:25:38Z")
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 ---
**Author:** ![William\_Djaja\_Tjokr1](https://avatars.discourse-cdn.com/v4/letter/w/87869e/32.png) [@William\_Djaja\_Tjokr1](https://rubytalk.org/u/William_Djaja_Tjokr1)\ **Post date:** [27 September 2002 20:45 UTC](https://rubytalk.org/t/visual-c-and-ruby/2028/4 "2002-09-27T20:45:43Z")
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](mailto:lyle@users.sourceforge.net) wrote: > > > [http://www.rubyconf.org/speakers.php#brannp](http://www.rubyconf.org/speakers.php#brannp) ---
**Author:** ![Joel\_VanderWerf1](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Joel\_VanderWerf1](https://rubytalk.org/u/Joel_VanderWerf1)\ **Post date:** [27 September 2002 21:26 UTC](https://rubytalk.org/t/visual-c-and-ruby/2028/5 "2002-09-27T21:26:56Z")
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](http://www.ruby-talk.org/30366) ? ---
**Author:** ![Yukihiro\_Matsumoto2](https://avatars.discourse-cdn.com/v4/letter/y/b9e5f3/32.png) [@Yukihiro\_Matsumoto2](https://rubytalk.org/u/Yukihiro_Matsumoto2)\ **Post date:** [28 September 2002 03:45 UTC](https://rubytalk.org/t/visual-c-and-ruby/2028/6 "2002-09-28T03:45:15Z")
Hi, > **···** > > In message “inherited change?” on 02/09/28, “Christoph” [chr\_news@gmx.net](mailto: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. > > ``` ---
**Author:** ![Christoph1](https://avatars.discourse-cdn.com/v4/letter/c/85f322/32.png) [@Christoph1](https://rubytalk.org/u/Christoph1)\ **Post date:** [27 September 2002 22:05 UTC](https://rubytalk.org/t/visual-c-and-ruby/2028/7 "2002-09-27T22:05:56Z")
“Joel VanderWerf” wrote … > Does this perhaps fix the problem discussed in > [http://www.ruby-talk.org/30366](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 ---
**Author:** ![Bob\_X](https://avatars.discourse-cdn.com/v4/letter/b/4491bb/32.png) [@Bob\_X](https://rubytalk.org/u/Bob_X)\ **Post date:** [27 September 2002 22:06 UTC](https://rubytalk.org/t/visual-c-and-ruby/2028/8 "2002-09-27T22:06:00Z")
“William Djaja Tjokroaminata” [billtj@z.glue.umd.edu](mailto: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