[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

C or C++?

Joe Cheng

10/2/2003 4:38:00 AM

I'd like to start writing Ruby extensions. Does it make a difference
whether you use C or C++? I took a C++ in college but haven't done any of
it since, so I'm more or less starting from scratch.

Thanks for any input!
8 Answers

Seth Kurtzberg

10/2/2003 5:19:00 AM

0

Write using the same language and libraries that Ruby itself is written in.

Joe Cheng wrote:

>I'd like to start writing Ruby extensions. Does it make a difference
>whether you use C or C++? I took a C++ in college but haven't done any of
>it since, so I'm more or less starting from scratch.
>
>Thanks for any input!
>
>
>
>
>.
>
>
>

Sean O'Dell

10/2/2003 6:50:00 AM

0

Joe Cheng wrote:
> I'd like to start writing Ruby extensions. Does it make a difference
> whether you use C or C++? I took a C++ in college but haven't done any of
> it since, so I'm more or less starting from scratch.

Ruby is really C-oriented. It longjmps on errors, so the stack doesn't
"unwind" the way C++ objects really wants it to. There are work-arounds
for that, but I found that without a good foundation of libraries to
work with, C++ was a real pain, so I stick with C. Plain C is also a
bit more portable than C++.

Sean O'Dell

Thomas Sondergaard

10/2/2003 9:27:00 AM

0

> Ruby is really C-oriented. It longjmps on errors, so the stack doesn't
> "unwind" the way C++ objects really wants it to.

I think I understand what you mean. Is it that destructors may not be called
as expected? Please elaborate!

> There are work-arounds
> for that, but I found that without a good foundation of libraries to
> work with, C++ was a real pain, so I stick with C.

What kind of work arounds? If you rb_protect everything the longjmp's should
only happen in ruby-land, and you should be safe in C++, right?

Cheers,

Thomas

Robert Klemme

10/2/2003 9:46:00 AM

0


"Thomas Sondergaard" <thomas@FirstNameGoesHereSondergaard.com> schrieb im
Newsbeitrag news:3f7bef63$0$48887$edfadb0f@dtext02.news.tele.dk...
> > Ruby is really C-oriented. It longjmps on errors, so the stack
doesn't
> > "unwind" the way C++ objects really wants it to.
>
> I think I understand what you mean. Is it that destructors may not be
called
> as expected? Please elaborate!
>
> > There are work-arounds
> > for that, but I found that without a good foundation of libraries to
> > work with, C++ was a real pain, so I stick with C.
>
> What kind of work arounds? If you rb_protect everything the longjmp's
should
> only happen in ruby-land, and you should be safe in C++, right?

You can only be safe in C++ land if your C++ never invokes Ruby C
functions which might longjump. So, if you just do C++ processing and
return values it's ok, but if part of your C++ processing is to invoke
methods defined in Ruby (likely for callbacks such as blocks) you can
easily shoot yourself in the foot...

Regards

robert

maillist@bestworldweb.homelinux.com

10/2/2003 11:00:00 AM

0

On Thu, 2003-10-02 at 16:45, Joe Cheng wrote:
> I'd like to start writing Ruby extensions. Does it make a difference

Why do you want to write extensions? Why cant you write ruby code? If
you want to write and bindings for a library and the library is C++ then
you had better write the binding in C++ otherwise I recommend using C.

or...

I think I saw some benchmarking that said C is faster than C++ so if you
are writing a calculation heavy program then C may be a better option,
IMHO.

Good luck

Paul

Aleksei Guzev

10/2/2003 11:43:00 AM

0


"Paul William" <maillist@bestworldweb.homelinux.com> wrote in message
news:1065092409.545.11.camel@debian...
> On Thu, 2003-10-02 at 16:45, Joe Cheng wrote:
> > I'd like to start writing Ruby extensions. Does it make a difference
>
> Why do you want to write extensions? Why cant you write ruby code? If
> you want to write and bindings for a library and the library is C++ then
> you had better write the binding in C++ otherwise I recommend using C.
>

I think C is useful for acessing some system resources.
Massive computations should be made with assembler or at least fortran ;)

Aleksei Guzev

Sean O'Dell

10/2/2003 4:08:00 PM

0

Thomas Sondergaard wrote:

>>Ruby is really C-oriented. It longjmps on errors, so the stack doesn't
>>"unwind" the way C++ objects really wants it to.
>
>
> I think I understand what you mean. Is it that destructors may not be called
> as expected? Please elaborate!

Destructors don't get called, correct.

>> There are work-arounds
>>for that, but I found that without a good foundation of libraries to
>>work with, C++ was a real pain, so I stick with C.
>
> What kind of work arounds? If you rb_protect everything the longjmp's should
> only happen in ruby-land, and you should be safe in C++, right?

I believe, at least under Windows, that rb_protect didn't protect me
quite as well as I needed (I still got longjmp'd past), so I abandonded
C++ entirely. I'm a devoted C++ user, so I didn't give it up easily,
believe me. It was just FAR more trouble trying to be Mr. C++ around
the Ruby engine than it was using C. C isn't so bad if you got your
head on for it.

Sean O'Dell

ts

10/2/2003 4:22:00 PM

0

>>>>> "S" == Sean O'Dell <sean@celsoft.com> writes:

S> I believe, at least under Windows, that rb_protect didn't protect me
S> quite as well as I needed (I still got longjmp'd past), so I abandonded
S> C++ entirely.

With C++, never try to mix 'try {} catch {}' with rb_protect() even with C
be carefull. For example, look at plruby to see how it made the call to
rb_protect() with a setjmp()/longjmp() need by postgres

static VALUE
pl_protect(plth)
struct pl_thread_st *plth;
{
Datum retval;
VALUE result;

if (sigsetjmp(Warn_restart, 1) != 0) {
return pl_eCatch;
}
/* ... */
}


static VALUE
pl_real_handler(struct pl_thread_st *plth)
{
VALUE result;
int state;
/* ... */
state = 0;
pl_call_level++;
result = rb_protect(pl_protect, (VALUE)plth, &state);
pl_call_level--;
/* ... */
}


the order is really important : after this I can safely use rb_raise() in
plruby and I can catch the error given by postgres (when it use longjmp())



Guy Decoux