[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] KDE/kdebindings/ruby/qtruby
From:       Richard Dale <rdale () foton ! es>
Date:       2008-12-11 10:45:58
Message-ID: 200812111045.59103.rdale () foton ! es
[Download RAW message or body]

On Thursday 11 December 2008 00:56:10 David Palacio wrote:
> On Wednesday 10 December 2008 07:46:23 Richard Dale wrote:
> > SVN commit 895236 by rdale:
> >
> > 	* Special case the Qt::Image.bits() method. Use the const variant so
> > that Qt doesn't make a deep copy. Is that what Davor Ocelic and David
> > Palacio would like it to do?
> > 	* For other uses of 'uchar *' return types add a marshaller, hoping that
> > 	  will be null terminated.
>
> 1) I checked which functions returned an uchar* in the Qt includes. All of
> them are expected to be used to directly transform the data.
I think the problem with these is that to use them we would have set the 
internal pointer in an existing ruby string to the value. But then both Qt and 
Ruby would think they owned the 'char*' and try to free it later. 

I think my change to allow 'uchar*' return types by default expecting them to 
be null terminated is probably pointless, and it might be better to revert 
that commit so that we get a 'can't handle type' error for a method and we'll 
know it needs special casing.

>
> 2) If the returned String when changed also affects the QImage, it makes
> sense. That is the intention for the bits method. (Checks on IRB... it does
> not).
>
> 3) I was blindly translating a C++ application to Ruby and stumbled on
> bits(). Now I did it in another way, maybe not as efficient though.
I think if you can do it another way that is better as it seems difficult to 
do it without risking double memory frees as above. Certainly we need to 
special case this kind of thing, and the general purpose marshalling code in 
qtruby won't handle this kind of tricky stuff.

> If 1) is true and 2) does not change (which I think is unlikely to do),
> this might have little sense.

This is the code to Qt::Image.bits():

static VALUE
qimage_bits(VALUE self)
{
  smokeruby_object *o = value_obj_info(self);
  QImage * image = static_cast<QImage *>(o->ptr);
  const uchar * bytes = image->bits();
  return rb_str_new((const char *) bytes, image->numBytes());
}

I think the rb_str_new() call will make a copy of 'bytes' and so it doesn't 
make any difference whether we use the const or non-const version of bits(). 
But it does avoid copying bytes twice, once on the QImage::bits() call and 
again in rb_str_new().

-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic